Esecuele Sin Fronteras

SQL Server, Reporting Services y Biztalk Server
  • Esecuele Sin Fronteras

    ¿Qué son los Ficheros de Tipo "sparse" y Qué Importancia Tienen para un DBA?

    • 0 Comments

    Durante la pasada semana trabajé junto con uno de mis compañeros del grupo de soporte a la Plataforma Windows en un problema acerca de la copia de seguridad en ficheros de datos de SQL Server. Mi compañero y yo aprendimos varias cosas en este caso y creo que merece la pena compartir esta información con vosotros.

    Nuestro cliente estaba utilizando Microsoft Data Protection Manager (DPM) para realizar copias de seguridad de los servidores Windows y las bases de datos de SQL Server y estaba encontrando errores precisamente al copiar los ficheros de base de datos. Durante nuestro trabajo en el caso el cliente encontró el siguiente artículo en un blog de MSDN que explicaba en detalle la causa del problema: "Did your backup program/utility leave your SQL Server running in a squirrely scenario?". Si nunca has oído hablar de los cheros de tipo sparse (traducido como "fichero disperso") y cómo estos afectan a SQL Server, te recomiendo que eches un vistazo a este post del blog del grupo de soporte para SQL Server.

    ¿Qué son los ficheros sparse?

    Los ficheros sparse son creados por SQL Server durante operacones como la creación de un snapshot o instantánea de una base de datos o durante la ejecución de un sentencia DBCC CHECKDB. En el caso de un snapshot el fichero sparse es borrado cuando el snapshot es borrado, mientras que en el caso de una operación de comprobación de consistencia de una base de datos con DBCC CHECKDB el fichero sparse es borrado automáticamente por SQL Server justo después de la ejecución. Puedes encontrar información completa sobre el papel de los ficheros "sparse" en los siguientes enlaces:

    Instantánea de base de datos interna

    DBCC CHECKDB utiliza una instantánea interna de la base de datos para la coherencia transaccional necesaria para realizar estas comprobaciones. Así se evitan problemas de bloqueo y simultaneidad cuando se ejecutan estos comandos. Para obtener más información, vea Descripción del tamaño de los archivos dispersos en instantáneas de bases de datos y la sección sobre el uso de la instantánea de base de datos interna DBCC en DBCC (Transact-SQL).

    Descripcion del tamaño de los archivos dispersos en instantáneas de bases de datos

    Los archivos dispersos son una característica del sistema de archivos NTFS. Inicialmente, un archivo disperso no incluye datos de usuario y no se le asigna espacio en disco para éstos. Para obtener información general sobre el uso de los archivos dispersos en instantáneas de bases de datos y el crecimiento de éstas, vea Funcionamiento de las instantáneas de la base de datos.

    Cuando se crea por primera vez, un archivo disperso ocupa poco espacio en disco. A medida que se escriben datos en él, NTFS le asigna espacio en disco de forma gradual. El tamaño de un archivo disperso puede aumentar en gran medida. Si una instantánea de base de datos se queda sin espacio, se marcará como sospechosa y se deberá quitar. Sin embargo, la base de datos de origen no se verá afectada y las acciones en ella continuarán normalmente.

    ¿Qué es lo que sucede?

    Los ficheros de tipo sparse son una funcionalidad ofrecida por el sistema de ficheros NTFS. Con determinadas versiones de NTFS.SYS la propiedad sparse de un fichero es incorrectamente transferida al fichero original, también llamado fichero "padre", del que el fichero de tipo sparse procede. Este sería un ejemplo de esta situación:

    1. Ejecutamos una sentencia DBCC CHECKDB on una base de datos SQL Server como parte de un proceso de mantenimiento. Esta acción se completa sin errores
    2. Realizamos una copia de seguriad de la base de datos con utilidades como DPM o alguna otra utilidad de backup
    3. En esta situación los ficheros originales de base de datos son marcados como de tipo sparse

    ¿Cuál es el problema?

    SQL Server no soporta operaciones de copia de seguridad o restauración en ficheros de tipo "sparse de forma que podemos ponernos en una situación de no-soporte sin ni siquiera ser conscientes de ello

    ¿Cómo puedo saber si estoy en esta situación?

    Ejecuta la siguiente consulta y comprueba si en la columna 'is_sparse' aparecen valores distintos de 0 (cero):

    use <DatabaseName>; SELECT is_sparse, * from sys.database_files

    El siguiente ejemplo muestra una base de datos con varios ficheros de este tipo:

     

    La herramienta de configuración de mejores prácticas para SQL Server SQL Server 2008 R2 Best Practices Analyzer incluye unan nueva relga para detectar cuándo una base de datos incluye ficheros de tipo "sparse". Se pueden encontrar más detalles en el artículo de la Knowledge Base KB2028447.

    ¿Qué puedo hacer para evitar este problema?

    Como primera medida debemos actualizar la versión de NTFS.SYS en los servidores Windows que alojan ficheros de base de datos. La última versión de NTFS.SYS evita que este problema ocurra. Lo siguiente es una lista de los hotfixs para NTFS.SYS que debemos tener en cuenta (estos enlaces hacen referencia a artículos de traducción automática):

    Para Windows Server 2003:

    No puede restaurar archivos de gran tamaño en el sistema de archivos NTFS cuando se eliminan todas las secuencias de datos que tienen atributos dispersos en la versión de 64 bits de Windows XP SP2 o en Windows Server 2003 Service Pack 2, http://support.microsoft.com/kb/973886/es-es

    Mensaje de error al ejecutar el comando "chkdsk" junto con el "/ v" cambiar en un equipo basado en Windows Server 2003: "Corregir archivo disperso segmento de registro, http://support.microsoft.com/default.aspx?scid=kb;es-es;932021

    Para Windows Server 2008:

    Informes del Administrador de disco incorrectas un tiempo después de que el sistema operativo se inicia en Windows Server 2008 o en Windows Vista de uso de disco, http://support.microsoft.com/kb/981891/es-es

    Para SQL Server 2005 y 2008:

    Ademas de las actualizaciones indicadas para Windows, debemos aseguarnos de que tenemos instalada la úlitma versión del Paquete de Servicio (Service Pack, SP) y Paquete Acumulativo (Cumulative Update, CU) tanto en SQL Server 2008 como 2005 para prevenir que este problema vuelva a suceder.

    ¿Cómo puedo solucionar el problema?

    Actualizar los servidores Windows y SQL Server con los últimos Paquetes de Servicio y hotfixes evitará que el problema vuelve a suceder pero no solucionará el problema si este ya existe. El post del grupo de producto mencionado inicialmente incluye el procedimiento para solucionar este problema tanto ten SQL Server 2005 como en SQL Server 2008.

    Otra opción para poser solucionar este problem es vaciar (en Inglés, empty) el contenido del fichero de base de datos a otro fichero dentro del mismo filegroup. Podemos realizar esta acción utilizando la opción EMPTYFILE del commando Transact-SQL SHRINKFILE, aquí se muestra un ejemplo:

    Este método no puede ser utilizado cuando el fichero con la propiedad sparse es el primer fichero del filegroup primario (PRIMARY) ya que este fichero contiene varios objetos del sistema que no puedes ser movidos.

    ¡Después de seguir estos pasos SQL Server todavía muestra los ficheros como "sparse"!

    Después de seguir estas indicaciones es posible que SQL Server siga mostrando los fichero como de tipo sparse a pesar de que la utilidad de Windows fsutil muestre los ficheros como no-sparse. Si este es el caso, debemos de asegurarnos de hacer un detach y a continuación un attach de estos ficheros; esto es necesario para que la información de la vista sys.database_files sea actualizada.

    Jorge Pérez Campo - Microsoft Customer Support Services

  • Esecuele Sin Fronteras

    Error "no se puede abrir el archivo de datos <ruta_del_archivo>" accediendo a un fichero de texto en SSIS

    • 0 Comments

    La pasada semana me encontré con este error trabajando en un caso con uno de nuestros clientes. El error se producía en una instalación de SQL Server 2008 sobre Windows Server 2008, pero como podremos ver no es un error asociado a una versión concreta de Windows o SQL Server.

    En este caso el cliente estaba intentando ejecutar una tarea de Agente de SQL Server compuesta por 17 pasos distinto. Estos pasos eran de diferentes tipos: Ejecución de código Transact-SQL, scripts de ActiveX, ejecuciones de CmdExec, etc. El cliente estaba tratando de ejecutar estos pasos con una cuenta de Proxy, que es un medio para limitar el contexto de seguridad en el que un trabajo es ejecutado en SQL Server; aquí podemos encontar más información sobre en qué consiste una cuenta de Proxy en SQL Server:

    El Agente SQL Server permite al administrador de la base de datos ejecutar cada paso de trabajo en un contexto seguro que sólo tiene los permisos necesarios para realizar ese paso de trabajo, que está determinado por un servidor proxy del Agente SQL Server. Para establecer los permisos para un paso de trabajo concreto, cree un proxy que disponga de los permisos necesarios y, a continuación, asigne ese proxy al paso de trabajo. Se puede especificar un servidor proxy en más de un paso de trabajo. Para los pasos de trabajo que necesitan los mismos permisos se utiliza el mismo proxy.

    Ejecutando la tarea con la cuenta de Proxy se comprobaba que dos de los pasos fallaban con el siguiente mensaje de error:

    10.0.2531.0 for 64-bit  Copyright (C) Microsoft Corp 1984-2005. Todos los derechos reservados. Iniciado: 15:27:31 Error: 2010-10-16 15:27:32.38 Código: 0xC020200E Fuente: Copiar Datos de AgentSource a AgentDestination: no se puede abrir el archivo de datos "V:\MySharedFolder\MyTextFile.txt". Error de error final: 2010-10-16 15:27:32.38 Código: 0xC004701A Fuente: Copiar Datos de AgentSource a AgentDestination.Pipeline de tarea flujo de datos: componente "FlatFileConnection" (46) falló la fase de pre-execute y devolvió el código de error 0xC020200E. Error de final DTExec: la ejecución del paquete devuelto DTSER_FAILURE (1). Iniciado: 15:27:31 finalizado de PM: 15:27:32 PM Elapsed: 0.687 segundos. Error en la ejecución del paquete. Error en el paso

    Si nuestra instalación de SQL Server es en idioma Inglés el mensaje mostrado será el siguiente:

    10.0.2531.0 for 64-bit  Copyright (C) Microsoft Corp 1984-2005. All rights reserved.    Started:  15:27:31  Error: 2010-10-16 15:27:32.38     Code: 0xC020200E     Source: Copy Data from AgentSource to AgentDestination Task Flat File Source [1]     Description: Cannot open the datafile "V:\MySharedFolder\MyTextFile.txt".  End Error  Error: 2010-10-16 15:27:32.38     Code: 0xC004701A     Source: Copy Data from AgentSource to AgentDestination Task SSIS.Pipeline     Description: component "Flat File Source" (1) failed the pre-execute phase and returned error code 0xC020200E.  End Error  DTExec: The package execution returned DTSER_FAILURE (1).  Started:  15:27:31  Finished: 15:27:32  Elapsed:  0.687 seconds.  The package execution failed.  The step failed.

    En este caso el propietario de la tarea era la cuenta 'sa' de SQL Server de forma que nuestra primera prueba fue cambiar el propietario de la tarea a la cuenta de Proxy, pero esto no dió ningún resultado. Durante la resolución del problema trabajaba con el cliente a través de una conexión remota y observé que el disco V: al que hacía referencia el mensaje de error no existía en el servidor. El cliente me explicó que este disco era creado a través de una asignación de red ("mapeo") durante el primer paso de la tarea.

    La asignación de este disco V: tenía lugar en el contexto de seguridad de la cuenta de Proxy así que nuestra primera tarea era comprobar que esta cuenta tenía los permisos correctos para el procedimiento extendido del sistema xp_cmdshell, tal y como se describe in la siguiente página de MSDN:

    Cuando es llamada por un usuario que no pertenece a la función fija de servidor sysadmin, xp_cmdshell se conecta a Windows con el nombre de cuenta y la contraseña almacenados en la credencial con el nombre ##xp_cmdshell_proxy_account##. Si no existe esta credencial de proxy, xp_cmdshell registrará errores.

    Para crear la credencial de cuenta de proxy, debe ejecutar sp_xp_cmdshell_proxy_account. Como argumentos, este procedimiento almacenado utiliza un nombre de usuario y una contraseña de Windows. Por ejemplo, el siguiente comando crea una credencial de proxy para el usuario de dominio de Windows SHIPPING\KobeR que tiene la contraseña de Windows sdfh%dkc93vcMt0:

    EXEC sp_xp_cmdshell_proxy_account 'SHIPPING\KobeR','sdfh%dkc93vcMt0'

    En nuestro caso los permisos requeridos por la cuenta de Proxy estaban correctamente configurados así que intentamos realizar la asignación del disco de red fuera de la propia ejecución de la tarea, utilizando nuestar propia sesión en lugar de la de la sesión de la cuenta de Proxy, pero esto resultó en el mismo error. Tanto el cliente como yo seguíamos pensando que era precisamente esta asignación de red la que estaba causando el problema de modo que creamos una nueva tarea de Agente de SQL Server pero esta vez con un único paso para intentar aislar el problema; en nuestro caso el contenido del paso era un código similar al siguiente:

    Este prueba funcionó correctamente. La diferencia aquí era que la asignación de la unidad de red V: y la ejecución de la tarea de SSIS estaban teniendo lugar en un mismo paso mientras que en la tarea original la asignación se producía en el primer paso y la ejecución del paquete en un paso posterior. Como se explica en el artículo de KB180362, este era precisamente el problema en nuestro caso:

    Cuando el sistema establece una unidad redirigida, se almacena en cada usuario. Sólo el usuario sí puede manipular la unidad redirigida. El sistema realiza un seguimiento de unidades redirigidas basadas en identificador de seguridad de inicio de sesión del usuario (SID). El SID de inicio de sesión es un identificador único de sesión de inicio de sesión del usuario. Un único usuario puede tener varias sesiones de inicio de sesión simultáneos en el sistema

    Si un servicio está configurado para ejecutarse bajo una cuenta de usuario, el sistema se crear siempre una nueva sesión de inicio de sesión para el usuario y, a continuación, iniciar el servicio en ese nuevo inicio de sesión. Por lo tanto, el servicio no puede manipular las asignaciones de unidad que se establecen dentro del usuario de otras sesiones.

    Justo en el primer párrafo de este mismo artículo de KB se puede leer:

    Un servicio (o cualquier proceso que se ejecuta en un contexto de seguridad diferente) que el debe tener acceso a un recurso remoto debe utilizar el nombre UNC (convención de nomenclatura universal) para tener acceso al recurso. Los nombres UNC no sufren las limitaciones descritas en este artículo.

    En nuestro caso la solución fue tan sencilla como modifciar la asignación a la unidad V: por la ruta UNC (es decir, \\nombreservidor\nombrerecurso). Otra opción en este caso hubiese sido ejecutar la asignación de la unidad de red V: en el mismo paso de la tarea en la que se realizar la ejecución del paquete de SSIS.

    Jorge Pérez Campo - Microsoft Customer Support Services

     

     

Page 1 of 1 (2 items)