Mes: diciembre 2009

(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:

BIR7.part01.exe

BIR7.part02.rar

BIR7.part03.rar

BIR7.part04.rar

BIR7.part05.rar

BIR7.part06.rar

BIR7.part07.rar

BIR7.part08.rar

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:

• Database Services: Incluye el motor de bases de datos y los componentes de búsqueda. El motor de base de datos es el núcleo de SQL Server. La replicación aumenta la disponibilidad de los datos distribuyéndolos entre varias bases de datos, permitiendo escalar la carga de trabajo de cada servidor. La búsqueda permite realizar consultas en lenguaje plano dentro de los datos almacenados en una base de datos.
• Analysis Services: Provee las funcionalidades para OLAP y Data Mining orientadas a aplicaciones de Inteligencia de Negocios. Analysis Services le permite agregar datos desde varias fuentes, como bases de datos relacionales y trabajar estos datos de variadas formas.
• Data Integration Services: Entrega transformación de datos y soluciones de integración para extraer y transformar datos desde múltiples fuentes y direccionarlas a uno o mas destinos. Esto permite unir datos desde múltiples fuentes y cargar estos datos en Data Warehouses.
• Notification Services: Incluye un motor de notificación y los componentes de clientes para generar y enviar mensajes personalizados cada vez que un evento ocurra. Las notificaciones pueden enviarse a dispositivos inalámbricos, como celulares o PDA’s, cuentas de Messenger o Correo.
• Reporting Services: Incluye Report Manager y Report Server para proveer una plataforma completa para crear, administrar y distribuir reportes. Report Server esta construido sobre el standard de IIS y la tecnología .NET Framework, permitiendo combinar los beneficios de SQL Server e IIS para alojar y procesar reportes.
• Service Broker: Permite creación de colas y mensajería como parte del núcleo de la base de datos. Las colas se pueden usar para apilar trabajos, como consultas y otras solicitudes, y ejecutarlas a medida que los recursos estén disponibles. La mensajería permite a las aplicaciones que usan las bases de datos comunicarse entre ellas.

(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:

1. Respaldar el Log de Transacciones de la Base de Datos Primaria
2. Copiar el respaldo realizado en el servidor secundario.
3. Restaurar el respaldo en la Base de Datos Secundaria.

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.

(Este articulo fue publicado originalmente en mi antiguo blog).

En mi último post les conté sobre la posibilidad de quemar ISOS sin necesidad de un software de terceros.

Ahora les voy a comentar sobre una característica que, personalmente, me gustó aún mas: Montar Discos virtuales directamente.

¿Como se hace?

1. Abrimos el Menú Inicio
2. Click derecho en Equipo y seleccionamos Administrar
3. Expandimos Almacenamiento y seleccionamos Administrador de discos
4. Hacemos click en Acciones y seleccionamos Montar VHD
5. Ingresamos la ubicación y el nombre del archivo VHD
6. OK

LISTO

¿Y cuando quiera desmontar el VHD?

Aún mas simple: Botón derecho en el disco virtual y seleccionamos Desmontar VHD

Voy a tratar de poner capturas apenas pueda.

A propósito, también funciona en Windows Server 2008 R2.

Saludos,

(Este articulo fue publicado originalmente en mi antiguo blog).

Estimados,

Me confieso… No he posteado la instalación de Windows Server 2008 R2 porque he estado todo el fin de semana “jugando” con Windows 7.

Hoy curioseando entre mis discos externos, encontré una imagen ISO que necesitaba grabar; una de las aplicaciones que no he instalado aun en Windows 7 es PowerISO, pero para mi sorpresa Windows 7 trae integrada la posibilidad de quemar archivos ISO.

Creo que desde Windows XP yo quería que esta capacidad viniera integrada en el SO.

Les dejo capturas del proceso y lo fácil que es:

 

Saludos,

(Este articulo fue publicado originalmente en mi antiguo blog).

Cuando alguien dice que se especializa en Bases de Datos es normal que te pidan saber de todo. Pero entre los que usamos SQL Server hay varios tipos distintos de usuarios y cada tipo tiene un enfoque distinto (que muchas veces tienen cosas en común).

La idea de este post es tratar de ayudar a quienes están recién empezando con SQL Server y aun no saben muy bien a que «área» dedicarse.

• Arquitecto

Define el diseño de la infraestructura y tecnología que utilizará el sistema o solución. También define la visión, alcance e interoperabilidad del proyecto y la implementación de cada parte del sistema o solución.

• Administrador

Ejecuta las operaciones diarias del sistema en áreas como disponibilidad, monitoreo, optimización, actualización, implementación, resolución de problemas y configuración.

•  Analista

Crea reportes y modelos de datos para uso personal y del resto de la organización. Los analistas pueden ser profesionales del área de procesamiento de datos, pero generalmente son los responsables de analizar los datos de la empresa mientras realizan otras funciones paralelas.

• Desarrollador

Diseña, implementa y prueba Sitios Web, Reportes o Aplicaciones que utilizan partes específicas del sistema diseñado por el Arquitecto. En lo particular, los Desarrolladores de Bases de Datos diseñan, implementan y prueban los schemas y objetos, como tablas y procedimientos almacenados, en una Base de Datos.

• Information Worker

Traduce la información disponible en un sistema a información de la empresa.

(Este articulo fue publicado anteriormente en mi antiguo blog).

Estimados,

Una de las mejoras que trae Windows 7 es la barra de tareas. Nos permite agrupar los iconos automáticamente, tiene mejores vistas previas, etc. Pero yo le encontraba un solo problema: Al ejecutar Live Messenger, este quedaba en la barra de tareas y no en la System Tray al lado del reloj como era hasta Vista. Si bien no parece ser tan molesto, personalmente me gusta el escritorio lo mas limpio posible y eso incluye la barra de tareas.

Bueno, investigando por ahí descubrí como mandar el icono del Live Messenger a la System Tray como antes.

1º Sin ejecutar el Live Messenger, vamos a las propiedades del acceso directo.

2º Cambiamos el modo de compatibilidad a Windows XP o Windows Vista

3º LISTO!

Acá las capturas de rigor: