Quizás el aspecto más importante, por el control que nos permite tener sobre nuestros servidores SQL Server, es el nuevo marco de trabajo de gestión declarativo, que nos permite definir políticas que deben de cumplirse en instancias, bases de datos u objetos, pero esta novedad se analiza en el artículo SQL Server 2008 Declarative Management Framework, por lo que no entraremos a fondo en su estudio, pero que debemos de mencionar al menos.
Otra de las novedades interesantes es la posibilidad de cifrar, de forma transparente a usuarios y aplicaciones, nuestras bases de datos. En SQL Server 2005, se introdujo una arquitectura de cifrado, que nos permitía utilizar funciones para cifrar, utilizando certificados o claves, los datos almacenados en las bases de datos SQL Server 2005. Sin embargo, eso nos exigía establecer procesos que realizasen las operaciones de cifrado y descifrado de datos, y además, con algunas restricciones que fundamentalmente afectaban al rendimiento. En SQL Server 2008, a través de la característica denominada Transparent Data Encryption(TDE), que solventa esas limitaciones, del modo más rápido y eficiente posible: se cifra la base de datos completa. El cifrado de datos con TDE se realiza a nivel de Entrada / Salida, a través del Buffer Pool. Esto quiere decir, que cuando se habilita una base de datos para TDE, se cifran todos los ficheros de dicha base de datos, tanto de datos como de log de transacciones, y el cifrado y descifrado se realizará durante las operaciones de lectura y escritura en disco. La gran ventaja de esta aproximación, como hemos comentado, es que lo hace cien por cien transparente a las aplicaciones, sin embargo, el problema es que los datos en memoria no se encuentran cifrados, y determinadas operaciones, como paginación de Sistema Operativo, o un Dump de memoria, pueden llevar disco los datos sin cifrar. Sin embargo, lo que si se tiene en cuenta, es que cuando habilitamos TDE en una base de datos, automáticamente se configura tempdb con TDE también, para que todos los objetos temporales que sea necesario crear, sean también cifrados. Del mismo modo, tanto las instantáneas, como las copias de seguridad, pueden sacar provecho de esta característica y también se cifrarán. Especial mención, requiere la copia de seguridad. Como ocurre siempre en estos casos, deberemos de disponer de copias de seguridad de los objetos (certificados o claves) que utilicemos con TDE, para que en caso de que necesitemos realizar una restauración, seamos capaces de poder leer los datos. Si no disponemos de esos objetos, no seremos capaces de restaurar una copia de seguridad cifrada con TDE.
Existen algunos cambios, que aunque no son excesivamente relevantes, si merecen mencionarse, en los roles de la base de datos msdb. En primer lugar los roles para la gestión de seguridad de SQL Server Integration Services cambian de nombre y pasan de llamarse db_dtsadmin, db_dtsltduser y db_dtsoperator se han renombrado respectivamente a db_ssisadmin, db_ssisltduser y db_ssisoperator. En el caso de que estemos realizando una actualización desde SQL Server 2005, los roles antigüos se mantendrán y se añadirán como miembros de estos nuevos roles para mantener la compatibilidad.
Además de estos cambios de nomenclatura, aparecen nuevos roles de base de datos, para dar soporte a algunas de las nuevas funcionalidades, especialmente para las nuevas características de gestión. Dispondremos en la base de datos msdb, de los siguientes nuevos roles:
· ServerGroupAdministratorRole y ServerGroupReaderRole, que nos permiten gestionar los grupos de servidores para administración centralizada.
· PolicyAdministratorRole, que nos permite definir los usuarios administradores de la gestión basada en políticas
· dc_admin, dc_operator y dc_proxy, que utilizaremos con el componente data collector
Microsoft entra de lleno en el mundo de la Búsqueda Empresarial, después de un pequeño escarceo con Office SharePoint for Search. Ahora aparecen dos nuevos productos, Microsoft Search Server y Microsoft Search Server Express, esta última gratuita y que se puede descargar, en versión RC desde aquí http://www.microsoft.com/enterprisesearch/serverproducts/searchserverexpress/download.aspx.
Esta versión gratuita solo nos permite instalar los servicios en un servidor sin posibilidad de escalar, es una de las grandes diferencias con respecto a la versión Search Server. Sin embargo, no tenemos limitaciones en el volumen de los documentos a indexar, y podemos gestionar aspectos fundamentales de la búsqueda como relevancia, ámbitos de búsqueda, palabras claves o mejores coincidencias. La verdad es que tiene muy buena pinta, y además gratuito. Prometo volver para contaros más cosas.
Según las investigaciones de Microsoft, la consola de NTBackup y su utilidad de línea de comandos eran consideradas como complejas de manajar para muchos usuarios de pequeñas y medianas empresas. Es por ello que en Windows Server Backup, el interfaz gráfico de administración ( un complemento de la MMC) permite hacer menos cosas de lo que permitía hacer NTBackup para intentar simplificarlo. Al mismo tiempo, se ha agregado la herramienta por consola Wbadmin.exe que nos permite complementar dichas operaciones. Un ejemplo claro es la copia de seguridad del estado del sistema de un Servidor Windows 2008, indispensable, entre otras cosas, para disponer de una copia de seguridad del directorio activo en caso de que el servidor sea un controlador de dominio. Este tipo de copia de seguridad, tan solo puede realizarse desde consola a través de Wbadmin.exe. El comando sería algo como:
Wbadmin start systemstatebackup –backuptarget:E: -quiet
Con esta sentencia le estamos indicando a Windows Server Backup que haga copia de seguridad del estado del sistema, lo almacene en el volumen E: y no solicite confirmación al usuario.
Windows Vista lo dejaba entrever, pero Windows Server 2008 lo confirma, NTBackup ha pasado a mejor vida. La verdad es que por un lado, uno siente un poco de nostalgia después de tantos años creando scripts y peleándose con esa herramienta, pero la verdad es que ya era hora de que Microsoft le diese una vuelta de tuerca y evolucionase su herramienta de copia de seguridad en servidores. El impulso que Microsoft ha hecho con Data Protection Manager 2007 hace que probablemente este sustituya en muchos casos a la nueva herramienta de Windows, aunque las mejoras introducidas, hacen que siga siendo una buena opción en muchos escenarios.
De entre las características más importantes de Windows Server Backup podemos destacar:
Obviamente, soporte de PowerShell para poder generar nuestros scripts.
Sorpresas te da la vida. El service pack 2 de SQL Server 2005 es mucho más que una simple colección de parches, y se agregan muchas nuevas funcionalidades, algunas de ellas no anunciadas, que iremos descubriendo poco a poco. Una de las que más me ha llamado la atención, por ser un problema bastante común y que ya he tratado en otras entradas de este blog, hace referencia a los usuarios huérfanos. Ahora, la sentencia ALTER USER, dispone de una clausula WITH LOGIN que nos permite modificar la asociación entre Usuarios y login, y es válido para logins de SQL y logins de Windows, al contrario que el procedimiento sp_change_users_login, que solo lo hace para los logins de SQL.
Seguiremos informando
Estos días me he encotrado con el mismo problema varias veces, por eso me he decidido a escribir sobre él. Cuando nosotros creábamos una vista en SQL Server 2000, el Order By solo estaba soportado si lo utilizábamos con la cláusula TOP para obtener solo un número determiando de filas. A pesar de no estar soportado, muchos desarrolladores utilizaron el truco de poner TOP 100 PERCENT, y al bueno de SQL Server 2000 le colaba, a pesar de no estar soportado. Claro, los lamentos vienen ahora cuando intentamos migrar esas vistas a SQL Server 2005, en donde el truquito ya no funciona. La solución es bien sencilla, y es lo que debería de haberse hecho en SQL Server 2000, si siguiésemos las buenas prácticas: EL ORDER BY EN LA LLAMADA A LA VISTA, NO DENTRO DE ELLA. Un poco de código para ilustrarlo:
USE
GO
CREATE
INSERT
SELECT
FROM
GROUP
En SQL Server 2005, podemos tener más de una instancia de Analysis Services en el mismo servidor físico. Para que una configuración de este tipo funcione adecuadamente debemos de tener en cuenta algunas consideraciones:
· Especificar el puerto que utilizará cada instancia. De forma predeterminada Analysis Services utiliza el puerto 2383. Si cuando la instancia se inicia, este puerto está ya ocupado, entonces utilizaré el primero de los puertos disponibles de un rango dinámico. Debido a posibles problemas que nos podemos encontrar, sobre todo si necesitamos atravesar firewalls, no es conveniente dejar esta configuración. Para ello, podemos especificar los puertos que queremos que utilice cada una de las instancias de Analysis Services. Para ello no tenemos más que especificar un valor diferente a 0 en la Propiedad Port de la instancia.
· Iniciar SQL Browser. Cuando la instancia de Analysis Services se inicia, registra su nombre de instancia y el puerto en el servicio SQL Browser. Concretamente en un módulo denominado Analysis Services redirector service, que escucha en el puerto 2382.
· Cómo se conectan los clientes. De forma predeterminada el cliente se conecta al puerto 2383. Si especificamos una instancia con nombre, entonces se redirige la petición al Analysis Services redirector, que se encargará de redireccionar al puerto determinado.
· Cómo me conecto a través de un Firewall. Muy fácil, o abrimos el puerto 2382 del redirector, o abrimos el puerto por el que la instancia que está escuchando.
· Si queremos hacer una instancia invisible. Tan solo tenemos que configurar la propiedad InstanceVisible a 0, de modo que la instancia no será visible por los clientes a no ser que especifiquen el puerto.
