SQL Server, ideas y experiencias

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

por Jose Mariano Alvarez 27. agosto 2009

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

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

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

<<  agosto 2017  >>
lumamijuvido
31123456
78910111213
14151617181920
21222324252627
28293031123
45678910

View posts in large calendar

Locations of visitors to this page

Widget Twitter not found.

Root element is missing.X


Valid XHTML 1.0 Transitional

Valid CSS!