Estimados,
Como ya deben saber, hoy fue el lanzamiento de SQL Server 2008 R2.
Para quienes quieran probarlo, acá hay un link para descargar una versión de evaluación de 180 días.
http://www.microsoft.com/sqlserver/2008/en/us/R2Downloads.aspx
Saludos,
Estimados,
Luego de un par de meses sin actualizar este blog, vuelvo para contarles que hoy Microsoft informó que SQL Server 2008 R2 ya esta en RTM (Release To Manufacturing). Eso significa que la versión final que saldrá a público ya está lista.
Les comparto algunas mejoras de esta nueva versión de SQL:
Si quieren mas información sobre SQL Server 2008 R”, les dejo los siguientes links:
Saludos y como siempre sus comentarios y sugerencias son bienvenidos,
Estimados,
Microsoft publicó hoy en el blog oficial de SQL Server que en mayo de 2010 estará disponible SQL Server 2008 R2.
A medida que vaya saliendo información mas detallada, la voy a ir publicando. Mientras, sus consultas o comentarios sobre SQL Server son mas que bienvenidas.
Saludos,
Hoy me encontré con una petición bastante inusual (inusual, porque nunca me lo habían pedido antes…). ¿Como obtengo una lista de TODAS las tablas y TODAS las columnas de una Base de Datos?
No fue menor la solicitud. Obtener el listado de todas las columnas de una tabla no es difícil, pero esta Base de Datos tenia cerca de 60 tablas y algunas de estas tablas tienen casi 20 columnas, la tarea se hacía un poco tediosa.
Hasta que se me ocurrió ponerme a cachurear por ahí y encontré las siguientes consultas:
Para Bases de Datos SQL Server 2000
SELECT SO.NAME, SC.NAME
FROM sysobjects SO INNER JOIN syscolumns SC
ON SO.ID = SC.ID
WHERE SO.XTYPE = ‘U’
ORDER BY SO.NAME, SC.NAME
Para Bases de Datos SQL Server 2005
SELECT SO.NAME, SC.NAME
FROM sys.objects SO INNER JOIN sys.columns SC
ON SO.OBJECT_ID = SC.OBJECT_ID
WHERE SO.TYPE = ‘U’
ORDER BY SO.NAME, SC.NAME
Como siempre, sus dudas y comentarios son bienvenidos.
(Este articulo fue publicado originalmente en mi antiguo blog).
Hace unas semanas hice una charla sobre SQL Server Integration Services 2008 en una Universidad en el norte de Chile y me sorprendió gratamente la cantidad de alumnos interesados en certificase en alguna tecnología.
A todos ellos que me preguntaron sobre certificaciones les tengo una MUY BUENA noticia. Hasta el 31 de Julio de 2010, Microsoft tendrá precios especiales para estudiantes en sus exámenes de certificación. En el caso de Chile, el descuento es de un 50%.
El listado de los exámenes esta en: http://www.prometric.com/microsoft/student
El único requisito para hacer efectivo este descuento es presentar una identificación que acredite tu condición de estudiante al momento de rendir el examen.
Durante el fin de semana iré publicando links donde encontrar material de preparación para algunos exámenes.
Como siempre si tienen dudas o comentarios, son bienvenidas.
Saludos,
(Este articulo fue publicado originalmente en mi antiguo blog).
Este articulo hace referencia a algo un poco antiguo, pero que por algún descuido no había puesto acá.
Microsoft tiene disponible una Maquina Virtual con TODO lo que necesitamos para hacer pruebas de una plataforma de Business Intelligence.
Ojo con los requerimientos de ejecución de esta maquina virtual. Al tener todo en uno, no es muy “liviana” que digamos. Necesitamos 1.5 ó 2 GB de RAM (lo optimo serian mas de 2GB), además esta creada para usarse en Virtual Server o Virtual PC así que deben recordar modificarla para usarla en Windows Virtual PC o Hyper-V. Finalmente, se recomienda almacenar el Disco Virtual en una unidad de disco distinta a la que almacena el SO de la maquina Host.
Un par de datos útiles: La contraseña para ingresar a la MV es: pass@word1 y La MV expira el 15 de Abril de 2010.
LOS LINKS:
Saludos,
(Este articulo fue publicado originalmente en mi antiguo blog).
La pregunta lógica que uno hace al saber que hay una versión nueva de algún producto es: ¿Cuáles son las nuevas características que trae incluidas? Y lógicamente, el tema de seguridad es uno de los más consultados.
En SQL Server 2008 una de las nuevas características es TRANSPARENT DATA ENCRYPTION (TDE). En este post vamos a tratar de explicar en qué consiste y cuáles son los usos y ventajas de usar esta modalidad de encriptación de datos.
¿QUE ES TDE?
SQL Server 2005 ya traía incorporadas ciertas capacidades de encriptación en forma de librerías; estas capacidades permitían encriptación basadas en roles de usuarios. TDE permite realizar encriptación de todos los datos en la Base de Datos, datos físicos y logs de transacciones. Esto se realiza al encriptar los datos a medida que se escriben al disco y desencriptando al realizar la lectura.
¿POR QUE USAR TDE?
Uno de los usos posibles de esta característica es si necesitamos darle acceso a nuestras Bases de Datos a personal externo a nuestra empresa (ej.: Desarrolladores Externos). Si la Base de Datos es demasiado grande para enviarla vía Correo Electrónico o FTP; o si nuestras políticas de seguridad no permiten dar acceso a nuestra red a personal externo, la única opción que nos quedaría es entregarle a ese Desarrollador una copia de la Base de Datos en un Disco Externo. Lógicamente el Desarrollador firmara una serie de documentos legales en los cuales se compromete a no divulgar la información contenida en la Base de Datos, pero ¿y si le roban el disco externo? O ¿Si la empresa que tenía que transportarlo lo extravía en el camino?
¿CUANDO USAR TDE?
TDE es una manera eficiente y muy fácil de implementar de asegurar nuestras bases de datos (incluyendo los respaldos). Esto la convierte en una herramienta muy potente cuando necesitamos enviar copias de nuestras Bases de Datos a personal externo, sucursales o los respaldos que, tal como dicen las buenas prácticas, almacenamos en un lugar físico distinto a nuestras oficinas.
Una de las principales ventajas de TDE es que no importa si alguien se roba el Disco Externo donde enviamos la Base de Datos al desarrollador externo, no podrá acceder la información a menos que tenga un certificado que da acceso a los datos. Además de ese certificado, necesitamos una llave privada y las credenciales para acceder a esa llave. Lógicamente, cada uno de estos elementos debe ser almacenado de manera independiente y en caso de tener que enviarlos a alguien se debieran enviar de manera separada.
¿COMO FUNCIONA TDE?
Si bien existen otros métodos de encriptación, estos usualmente encriptan los datos antes de que se escriban o actualicen los datos. Generalmente, la encriptación ocurre a nivel de aplicación; en un nivel intermedio del código o en el servidor de Base de Datos con las características que trae SQL Server 2005. La clave acá es que los datos se encriptan antes de escribirse en la cache (y por lo tanto en el disco) y se mantienen encriptados en la cache y en el disco. La desencriptación ocurre cuando los datos se recuperan desde la cache y esto puede ocurrir a nivel de código medio o aplicación.
En el caso de TDE no se encripta parte de los datos, se encriptan TODOS los datos en bloques de 8K a medida que los datos se escriben en el disco y la desencriptación ocurre al leerse desde el disco. Esta encriptación ocurre a bajo nivel y aunque ocurre para todas las páginas de datos, solo ocurre al escribir y leer datos desde el disco. Por lo tanto, si la Base de Datos tiene un bajo nivel de transacciones y un alto nivel de consultas (las cuales se generan principalmente en cache), no se notara un cambio significativo en el rendimiento. En cambio, si la Base de Datos es altamente transaccional (por lo tanto, con un alto nivel de operaciones de I/O) se notara un impacto en el rendimiento.
Un aspecto importante sobre TDE es que al encriptar cualquier numero de bases de datos en una instancia, se encripta automáticamente la base TEMPDB. Esto puede resultar en una disminución del rendimiento en otras bases de datos que no estén encriptadas y que tengan un alto nivel de uso de la base Tempdb. Si este es el caso, es conveniente considerar la opción de instalar una instancia de SQL Server especifica para las bases encriptadas o buscar otra alternativa de encriptación.
Por ahora es suficiente, como siempre sus comentarios y sugerencias son mas que bienvenidos.
Saludos,
(Este articulo fue publicado originalmente en mi antiguo blog).
Una de las tareas más importantes de un DBA es la creación e implementación de un plan de respaldo y recuperación de nuestras Bases de Datos. La creación de este plan puede tomar bastante tiempo y trabajo, hay que pensar en las Bases de Datos que se respaldaran, cada cuanto se harán los respaldos, etc.
Vamos a ver algunos de los puntos en los cuales fijarnos al preparar el plan de respaldo.
· ¿Qué Bases de Datos me conviene respaldar? La Base de Datos Master es vital para el funcionamiento de SQL Server. Si falla o se corrompe, el servidor completo se vuelve inútil. Lo bueno es que esta Base de Datos solo sufre cambios si creamos Bases de datos nuevas, creamos nuevos logins o cambiamos la configuración del servidor. Lógicamente en estos casos es conveniente hacer un respaldo de la Master. Sin embargo, si una Base de Datos contiene datos vitales de nuestros clientes y sufre cambios repetidamente, necesita ser respaldada más seguido.
· ¿Qué tan importante son los datos almacenados? Una base de datos de desarrollo o testeo no es tan importante como una que se encuentra en producción, por lo tanto la primera basta con respaldarla una vez a la semana, en cambio la segunda se recomienda respaldarla todos los días. Esto también va a influir en el tipo de Backup que realizaremos, un backup completo toma demasiado tiempo en el caso de una Base de Datos en producción como para realizarlo todos los días. Si la Base de Datos es demasiado crítica, se puede realizar un Backup completo 2 veces a la semana y el resto de los días un Backup Diferencial y cada una hora un Backup de los logs de transacciones.
· ¿Cada cuanto tiempo hay cambios en los datos? Una Base de Datos de solo lectura no tiene muchos cambios y por lo tanto puede pasar más tiempo entre respaldos. Por el contrario, una Base de Datos que se actualiza varias veces al día debe ser respaldada al menos una vez al día.
· ¿Qué tan rápido necesito tener la información disponible? En caso de un fallo, es importante el tiempo que nos demoraremos en tener disponible los datos nuevamente. Si tenemos nuestros respaldos en cinta, la recuperación tomará más tiempo que si lo tenemos en un disco o en varios dispositivos de respaldo.
· ¿Tengo el equipamiento para realizar los respaldos? Si no tenemos donde almacenar los respaldos, difícilmente podremos hacer un plan de respaldo apropiado. Es bueno considerar más de un tipo de dispositivo de respaldo (cintas, medios ópticos, discos duros, etc.)
· ¿Cuál es la mejor hora para realizar respaldos? La idea es hacer los respaldos durante el tiempo en que las Bases de Datos tienen un menor uso. Esto va a disminuir el tiempo que demora el respaldo en hacerse, pero a veces es importante considerar que hay Bases de Datos que están en uso durante el tiempo en que otras no lo están.
· ¿Es necesario almacenar mis respaldos en otro lugar físico? Mantener copia de nuestros respaldos en otra oficina o lugar físico es una manera de proteger los datos si nuestras instalaciones se ven afectadas por un desastre mayor (incendio, terremoto, etc.). Pero es importante considerar que también es importante mantener una copia de nuestro sistema de respaldo para poder recuperar rápidamente los datos.
(Este articulo fue publicado originalmente en mi antiguo blog).
Dentro de SQL Server 2005 se pueden encontrar las siguientes herramientas:
(Este articulo fue publicado originalmente en mi antiguo blog).
A pedido de un amigo vamos a dedicarle un tiempo a ver un poco de Log Shipping en SQL 2005, voy a tratar de hacer esto lo mas simple posible para quienes lo lean.
Vamos por parte: Log Shipping es el proceso mediante el cual Respaldamos, Copiamos y Restauramos el log de transacciones de una Base de Datos ubicada en un servidor a otro(s) servidor(es). ¿Para Que?: Por que en caso de un fallo en uno de nuestros servidores, tener estos respaldos nos permiten recuperar rápidamente nuestras Bases de Datos en servidores de contingencia. (Créanme, es útil…)
¿Como Funciona? No tiene mucha ciencia en realidad. Básicamente creamos un respaldo de nuestro(s) log de transacciones, lo(s) copiamos a un servidor secundario y en caso de fallo levantamos este respaldo. Pero ojo, el proceso de levantar el servidor secundario no se hace en forma automática, debemos hacerlo nosotros.
Las operaciones que se realizan durante el proceso de Log Shipping los automatiza SQL Server Agent. La información de las operaciones efectuadas se almacenan en la Base de Datos MSDB.
¿Que necesitamos? La configuración recomendada es de 5 componentes: 1 Base de Datos Primaria, 1 Servidor Primario, 1 Base de Datos Secundaria, 1 Servidor Secundario y 1 Servidor de Monitoreo. El ultimo es opcional, pero permite administrar mas efectivamente los procesos que se realizan.
El proceso de Log Shipping consiste en 3 operaciones:
INFRAESTRUCTURA NECESARIA
Debemos tener al menos 2 servidores o 2 instancias. Para configurar un servidor de monitoreo aparte, necesitamos un tercer servidor o instancia.
Todos los servidores deben tener SQL Server 2005 Standard, Enterprise, Workgroup o Developer Edition. Por lo tanto, SQL Server Express no admite Log Shipping.
Los servicios del SQL Server Agent deben estar corriendo y configurados con credenciales de red. Se puede configurar Log Shipping con los servicios detenidos, pero el proceso no se ejecutara en forma automática.
La Base de Datos primaria debe estar configurada en modo de recuperación FULL o BULK-LOGGED.
Debe existir una carpeta compartida donde copiar los respaldos realizados. La cuenta de servicio de SQL Agent en el servidor primario debe tener permisos de Lectura/Escritura en la carpeta. La cuenta de servicio de SQL Agent en el servidor secundario debe tener permisos de Lectura en esta carpeta.
El usuario que configura el procedimiento debe tener acceso de SYSADMIN en TODOS los servidores.