Blog de Jose Mariano Alvarez
SQL Server, ideas y experiencias

Materiales-Índices y rendimiento (Performance) en el SQL Server

por Jose Mariano Alvarez 3. noviembre 2009 09:09

El objetivo fue aprender como el SQL Server almacena los datos y como utiliza los índices para poder diseñarlos y usarlos eficientemente. El objetivo final fue que los asistentes puedan tener el conocimiento necesario para optimizar mediante índices el uso que hace una aplicación de los recursos disponibles en el SQL Server.

Los siguientes enlaces tienen el contenido de los materiales mostrados en el curso dictado en el MUG y que no están incluidos en el CD con materiales que han recibido.

Índices y rendimiento (Performance) en el SQL Server.pdf (1,76 mb)

DemosIndicesOct2009.zip (25,81 kb)

Tags: , , , , ,

Eventos y conferencias

Actualización de Seguridad para el SQL Server 2005 Service Pack 3 (KB970894)

por Jose Mariano Alvarez 15. octubre 2009 14:04

Se ha identificado un problema de seguridad en el SQL Server 2005 Service Pack 3 que podría permitir a un atacante comprometer su sistema y obtener el control sobre ella. Entre los problemas conocidos que resuelve esta el del Boletín de seguridad Microsoft MS09-062

Security Update for SQL Server 2005 Service Pack 3 (KB970894)

http://www.microsoft.com/downloads/details.aspx?familyid=e6f307c1-8b21-406e-9c6f-b1a3a1e9a98f&displaylang=en

IMPORTANTE: Se recomienda aplicar la actualización lo antes posible, previa verificación de las cuestiones relacionadas (compatibilidad, etc)

 

Tags: ,

Actualizaciones

Boletín de seguridad Microsoft MS09-062

por Jose Mariano Alvarez 15. octubre 2009 13:56

El boletín de seguridad Microsoft MS09-062 del 13 de Octubre del 2009, es en realidad una actualización donde se modifica la información correspondiente a esta vulnerabilidad. Esta vulnerabilidad podría permitir la ejecución remota de código si un usuario, por ejemplo visualiza, utilizando el software afectado por esta vulnerabilidad, una imagen desde un archivo especialmente diseñado para aprovecharla.

Entre los sistemas que podrían estar afectados se encuentra el SQL Server 2005 Service Pack 3 o actualizaciones anteriores, algunas herramientas de desarrollo y otros productos. Como siempre ocurre, podrían ser menos afectados los usuarios que tengan pocos derechos en el sistema respecto de los usuarios que cuenten con derechos de administrador del equipo.

La actualización de seguridad relacionada resuelve varias vulnerabilidades reportadas del Microsoft Windows GDI +.

El detalle se encuentra en el siguiente enlace:

Microsoft Security Bulletin MS09-062

Critical - Vulnerabilities in GDI+ Could Allow Remote Code Execution (957488)

http://www.microsoft.com/technet/security/bulletin/ms09-062.mspx

IMPORTANTE: Se recomienda aplicar la actualización lo antes posible, previa verificación de las cuestiones relacionadas (compatibilidad, etc)

Tags: ,

Actualizaciones

Migración a SQL Server 2008 cuando los nombres de los Data Source compartidos de Reporting Services contienen espacios

por Jose Mariano Alvarez 3. septiembre 2009 00:04

Si se realiza una migración o actualización de un reporte que hace referencia a un origen de datos compartido de Reporting Services 2005 a Reporting Services 2008, el informe dejará de funcionar después de la migración, ya que este proceso actualiza el nombre del data source compartido.

Quienes diseñaron reportes en el Business Intelligence Development Studio de SQL Server Reporting Services 2005 pueden utilizar nombres de data source compartidos con espacios en blanco. Sin embargo en la versión del 2008 ya no se pueden utilizar más. Por lo tanto no es posible crear nuevos data source con espacios en blanco.

En el IDE de Visual Studio 2005 si se puede utilizar fuentes de datos (data source) con espacios en blanco en el nombre.

Como puede verse en la siguiente imagen, en el IDE de Visual Studio 2008 no se puede usar fuentes de datos compartidas con nombres que contengan espacios en blanco en el nombre.

NombreDelDatasource

El problema es que si le cambiamos desde el sitio del Report Manager de Reporting Services el data source al que hace referencia el reporte que se encuentra en el servidor este cambio no tiene efecto a pesar que desde la interface el cambio queda impactado.

Existe una solución alternativa y consiste en editar el nombre del data source compartido del reporte para eliminar los espacios en blanco. Esto se realiza editando el contenido dentro del TAG <DataSourceReference> que se encuantra dentro del tag <DataSources>  en el archvo RDL del reporte como puede verse en la siguiente Imagen.

DatasourdeEnRDL

Tags: ,

Artículos

La alineación de particiones de disco y el SQL Server – Documento de SQLCAT

por Jose Mariano Alvarez 27. agosto 2009 18:51

La alineación de particiones de disco es una técnica esencial pero a menudo se la pasa por alto. Es una de las herramientas posibles que podemos usar para mejorar el rendimiento o performance del SQL Server 2008. Configurar el rendimiento óptimo del disco muchas veces es visto como un arte en lugar de como una ciencia. Una de las buenas prácticas para configurar un rendimiento óptimo es la alineación de particiones de disco que más que arte tiene ciertas reglas básicas a seguir.

Windows Server 2008 intenta ajustar automáticamente las nuevas particiones, sin embargo como no corrige la configuración de las particiones ya existentes, en las particiones creadas en versiones anteriores de Windows la alineación de particiones de disco sigue siendo una tecnología relevante a tener en cuenta aun en Windows Server 2008.

Este paper que recientemente ha publicado el grupo SQLCAT, trata de explicar y comparar el desempeño de los almacenamientos alineados y no alineados y de explicar por qué las particiones no alineadas puede afectar negativamente rendimiento I/O.

Algunas de las mediciones que se encuentran en el documento muestran por ejemplo, casos de mejoras del 30% en la latencia y duración en los discos o como seis discos alineados pueden tener mejor rendimiento que ocho discos no alineados.

También describe cómo Windows Server 2008 intenta solucionar los problemas relacionados con la alineación de particiones para las particiones nuevas y explica cómo es la alineación de particiones de disco para los almacenamientos en Windows Server 2003, incluyendo el análisis, el diagnóstico y los planes de remediación.

Los siguientes temas también se explican:

  • Información de contexto relacionada
  • Implementación
  • Consideraciones a tener en cuenta de los proveedores de almacenamiento
  • Desplazamientos de particiones de arranque validos
  • El protocolo (simple) de alineación de particiones
  • Como definir el tamaño de unidad de asignación de archivos
  • Links a más información

Para aquellos que quieran leerlo les dejo el Link:

http://msdn.microsoft.com/en-us/library/dd758814.aspx

Tags: , ,

Documentos

Como cambiar la instancia del SQL Server usada por el “Development Storage” del SDK de AZURE

por Jose Mariano Alvarez 23. agosto 2009 18:57

El almacenamiento en el entorno de desarrollo

El entorno de desarrollo SDK de Windows Azure incluye el “Development Storage”, que es una herramienta que simula los servicios Blob, Queue y Table disponibles en la nube. Además ofrece una interfaz de usuario para ver el estado y para iniciar o detener estos servicios de almacenamiento local.

El servicio “Development Storage” se basa en una instancia de SQL Server para simular los servidores de almacenamiento de la nube. De forma predeterminada, el almacenamiento de desarrollo está configurado para utilizar una versión “Express“ del SQL Server 2005 o 2008 como base de datos.

Cambiando la instancia

Cuando ya tenemos un entorno de desarrollo con el SQL Server instalado y este no es la edición “Express” generalmente ocurre que la instancia es una instancia DEFAULT o es una instancia con nombre pero no se llama “express”. Por ejemplo es muy común tener la edición SQL Server 2008 Developer edition en el entorno de desarrollo. Si queremos utilizar esta instancia SQL Server previamente instalada y que no se llama “express” tenemos que reconfigurar nuestro entorno de desarrollo.

Para poder configurar el “development storage”, se debe tener privilegios de administrador del equipo. El programa de línea de comandos DSInit.exe inicializa el “development storage” en el entorno de desarrollo local. Esta herramienta se ejecuta automáticamente la primera vez que se inicia el “development storage” mediante la ejecución del programa DevelopmentStorage.exe y no es necesario ejecutarla a menos que queramos reinicializarlo o cambiarlo como es en nuestro caso. La herramienta DSInit.exe se instala en el directorio C: \ Archivos de programa \ Windows Azure SDK \ v1.0 \ bin \.

Para que el servicio “development storage” utilice otra instancia local del SQL Server tenemos que ejecutar el DSInit con el parámetro /SQLInstance, pasándole el nombre de la instancia del SQL Server de destino. Se puede llamar a DsInit.exe /SQLInstance en cualquier momento para configurar el “development storage” para que apunte a una instancia diferente de SQL Server.

Hay que utilizar el nombre de la instancia de SQL Server sin el calificativo de servidor o “.” para indicar la instancia “Default”

Si disponemos de una instancia local con nombre, por ejemplo la instancia es SQLTotalJMA\SQL2008 como es en mi caso, debemos ejecutar “DSInit.exe /sqlinstance:SQL2008” como muestra la imagen.

DEvelopment Storage DsInit

Esto nos configura el entorno de desarrollo como muestra la siguiente imagen

DsInitResultados

Tags:

Artículos

Cómo ejecutar xp_cmdshell con mínimos permisos

por Jose Mariano Alvarez 3. agosto 2009 01:49

El procedimiento almacenado xp_cmdshell es esencialmente un mecanismo para ejecutar llamadas en el sistema operativo utilizando el contexto de SQL Server (es decir, la cuenta de Windows utilizada para iniciar el servicio del SQL Server) o una cuenta proxy que puede ser configurada para ejecutar xp_cmdshell con diferentes credenciales. Si bien habilitar y utilizar este procedimiento almacenado no es una buena práctica, ciertas aplicaciones usan esta técnica y a veces puede ser necesario acceder a la línea de comandos del sistema operativo para ejecutar algún programa fuera del SQL Server. En estos casos tenemos que tener mucho cuidado en como habilitamos y damos permisos para que el usuario pueda acceder a los recursos del sistema operativo con mínimos permisos. En este artículo analizaremos algunos detalles y de cómo habilitarlo con menos permisos que los indicado en la ayuda.

El procedimiento almacenado xp_cmdshell

Para ejecutar un programa fuera del contexto del SQL Server se utiliza el procedimiento almacenado extendido xp_cmdshell, Con este procedimiento almacenado extendido podemos ejecutar cualquier proceso de línea de comandos, por lo que no solo se pueden ejecutar programas EXE sino que se puede ejecutar un archivo de lotes (BAT o CMD).

Debemos tener sumo cuidado en cómo se utiliza este procedimiento almacenado ya que si el contexto de ejecución tiene permisos de administrador local del equipo por ejemplo el programa o un código inyectado pueden agregar un usuario administrador del equipo (del WIndows) utilizando NET USER y NET GROUP.

En SQL Server 2000, por los riesgos de seguridad que implica y para limitar el acceso al xp_cmdshell , su uso está restringido por defecto o en forma predeterminada solo a los miembros de la función de servidor o rol sysadmin. Para extender los derechos a otros usuarios se puede utilizar el comando GRANT.

En SQL Server 2005 el uso de xp_cmdshell está desactivado por defecto como mecanismo de protección para minimizar los riesgos de seguridad de código no deseado en ejecución dentro o fuera de SQL Server de SQL Server. Por ello, si no se habilita la ejecución del xp_cmdshell ni siquiera los administradores del SQL Server (grupo de servidor sysadmin) podrán ejecutarlo.

Por ejemplo si ejecutamos como administradores:

exec xp_cmdshell 'dir c:\*.*'

El resultado es:

Msg 15281, Level 16, State 1, Procedure xp_cmdshell, Line 1

SQL Server blocked access to procedure 'sys.xp_cmdshell' of component 'xp_cmdshell' because this component is turned off as part of the security configuration for this server. A system administrator can enable the use of 'xp_cmdshell' by using sp_configure. For more information about enabling 'xp_cmdshell', see "Surface Area Configuration" in SQL Server Books Online.

 

Para poder ejecutar el procedimiento almacenado extendido xp_cmdshell debemos habilitarlo haciendo:

--Habilito la ejecucion del xp_cmdshell

EXEC sp_configure 'show advanced options', 1
GO

RECONFIGURE
GO

EXEC sp_configure 'xp_cmdshell', 1
GO

RECONFIGURE
GO

Ahora vemos que si volvemos a ejecutar el scrip T-SQL anterior como administrador del SQL Server vemos que nos responde cuando estamos autenticados como administradores. El proceso de Windows creado por xp_cmdshell dispone de los mismos derechos de seguridad que la cuenta de servicio de SQL Server la cual tenía los permisos adecuados en la raíz del disco.

 

Cuenta proxy para el xp_cmdshell

Cuando es llamada por un usuario que no pertenece al rol (función de servidor) sysadmin, el xp_cmdshell se conecta a Windows con el nombre de la cuenta y la contraseña almacenados en la credencial con el nombre ##xp_cmdshell_proxy_account## en lugar de usar la cuenta de servicio por lo que habrá que indicarla previamente o sino dará error.

Vamos a probar ahora con un login que solo tiene permisos mínimos

--Creamos el login 
CREATE LOGIN [Prueba]
WITH PASSWORD=N'<la contraseña del usuario>',
DEFAULT_DATABASE=[master],
CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO

Para crear la credencial de la cuenta de proxy hay que ejecutar sp_xp_cmdshell_proxy_account y como parámetros el nombre del usuario y la contraseña de Windows.

-- Asigno la proxy account
EXEC sp_xp_cmdshell_proxy_account
N'sqltotal\mariano',
N'<la contraseña del usuario>'

El resultado es:

Msg 15137, Level 16, State 1, Procedure sp_xp_cmdshell_proxy_account, Line 1

An error occurred during the execution of sp_xp_cmdshell_proxy_account. Possible reasons: the provided account was invalid or the '##xp_cmdshell_proxy_account##' credential could not be created. Error code: '5'.

Aquí nos encontramos con un nuevo problema si estamos usando Windows Vista como es mi caso. No podemos asignar esta contraseña por más que el usuario usado sea administrador del SQL Server debido al UAC. Por lo tanto debemos ejecutar este comando en una nueva instancia del SQL Server Management Studio como administrador usando la opción “RUN AS ADMINISTRATOR” (ejecutar como administrador).

Luego de asignar la cuanta proxy como administrador local y del SQL Server abrimos una nueva ventana con el usuario prueba y verificamos que pasa:

exec xp_cmdshell 'dir c:\*.*'

Y el resultado es:

Msg 229, Level 14, State 5, Procedure xp_cmdshell, Line 1

The EXECUTE permission was denied on the object 'xp_cmdshell', database 'mssqlsystemresource', schema 'sys'.

En este punto si revisamos la ayuda en el link siguiente podemos verificar que nos dice que se requiere el permiso CONTROL SERVER, para poder ejecutar xp_cmdshell el cual no es adecuado ya que posibilita tomar el control total del SQL Server.

xp_cmdshell en la ayuda del SQL Server

Por lo tanto vamos a crear el usuario dentro de la base de datos master relacionado con el login y asignar solo el permiso de ejecución del procedimiento almacenado:

-- Creo el usuario en la base de datos
-- master para el login anterior
USE [master]
GO

CREATE USER [Prueba] FOR LOGIN [Prueba]
GO

-- Asigno el permiso de ejecucion al usuario
use [master]
GO

GRANT EXECUTE ON [sys].[xp_cmdshell]
TO [Prueba]
GO

Si ahora probamos veremos que es posible ejecutar el procedimiento almacenado xp_cmdshell sin ser administrador sin asignar permisos de CONTROL SERVER.

Veamos qué pasa si tenemos asignado solo el permiso de ejecución del procedimiento almacenado pero no existe la credencial.

Como administradores eliminamos la cuenta proxy:

EXEC sp_xp_cmdshell_proxy_account null

Probamos la ejecucion del procediemiento almacenado nuevamente con el usuario prueba

exec xp_cmdshell 'dir c:\*.*'

El resultado es:

Msg 15153, Level 16, State 1, Procedure xp_cmdshell, Line 1

The xp_cmdshell proxy account information cannot be retrieved or is invalid. Verify that the '##xp_cmdshell_proxy_account##' credential exists and contains valid information. 

Conclusiones

  • No es recomendable utilizar el procedimiento almacenado xp_cmdshell.
  • Para poder ejecutarlo se requiere habilitar su ejecución en la configuración del SQL Server utilizando el procedimiento almacenado sp_configure.
  • Si somos administradores podemos ejecutar el procedimiento xp_cmdshell el cual utiliza la cuenta de servicio del SQL Server
  • Si no somos administradores utiliza la cuenta proxy que debe estar definida.
  • Si no somos administradores solo debemos tener permiso de ejecución en el procedimiento almacenado xp_cmdshell y no hace falta asignar el permiso CONTROL SERVER como dice la ayuda.

Tags: , ,

Artículos

Powered by SQL Total Consulting


View Jose Mariano Alvarez's profile on LinkedIn

 Add to Technorati Favorites 

Calendar

<<  marzo 2010  >>
lumamijuvido
22232425262728
1234567
891011121314
15161718192021
22232425262728
2930311234

View posts in large calendar

Locations of visitors to this page

Valid XHTML 1.0 Transitional

Valid CSS!