Supongamos que estamos monitorizando el estado de un servidor y nos encontramos habitualmente con tipos de espera por bloqueos.
Una opción que tenemos sería empezar a revisar vistas dinámicas. Sin embargo, si el problema aparece a menudo pero de forma aleatoria, es complicado estar revisando el servidor en el momento en el que aparecen.
CREATE EVENT SESSION [nombre] ON SERVER
ADD EVENT evento
ADD TARGET archivo
Ahora bien, ¿Cómo podemos saber qué eventos podemos capturar y cuales nos pueden interesar?
Para una lista de eventos completa, podemos ejecutar:
select * from sys.dm_xe_objects where object_type='event'
En nuestro caso , nos interesa la información de esperas: wait_info.
Para confirmar qué información nos dará wait_info, y si es la necesaria, podemos ejecutar:
SELECT * FROM sys.dm_xe_object_columns WHERE object_name = 'wait_info'
A continuación, la siguiente información que necesitamos es el paquete al que pertenece este evento, para ello, podemos tomar el object_package_guid de cualquiera de las querys anteriores, y ejecutamos:
select * from sys.dm_xe_packages where guid='BD97CC63-3F38-4922-AA93-607BD12E78B2'
Con estos dos datos, podemos crear la siguiente sesión:
ADD EVENT sqlos.wait_info
En este caso, capturaríamos toda la información de esperas. Sin embargo, sólo queremos capturar la esperas por bloqueos y que duren más de tres segundos.
Para identificar el tipo de espera con su código asociado, podemos ejecutar:
select * from sys.dm_xe_map_values where name='wait_types'
Como nos interesan todos los tipos de bloqueos, incluiremos el siguiente filtro:
ADD EVENT sqlos.wait_info (Where duration>2000 and wait_type>1 and wait_type<22)
Finalmente, si queremos incluir la información de la query en espera, podemos añadir:
ADD EVENT sqlos.wait_info (ACTION(sqlserver.sql_text),
Where duration>2000 and wait_type>1 and wait_type<22)
Raquel Vicente de la Rosa
Ingeniero de Soporte de SQL Server
…en particular cuando mezclamos replicación transaccional y de mezcla. Veamos el siguiente entorno:
Servidor 1: Publicación transaccional.
Servidor 2: Subscrito a la publicación transaccional y con una publicación de mezcla sobre estas mismas tablas.
Servidor 3 (o máquina cliente): subscrito a la publicación de mezcla.
El primer aspecto a tener en cuenta, es la gestión de cambios en el servidor 3: Hay que tener en cuenta que por defecto, la replicación de mezcla va a sincronizar los cambios en las dos direcciones y la replicación transaccional sólo en una de ellas.
Por lo tanto la primera decisión a tomar es la posibilidad o no de realizar cambios en el servidor 3:
-Si optamos por permitir estos cambios, deberemos modificar la replicación transaccional para que permita cambios en el subscriptor (Subscripciones actualizables para replicación transaccional)
-Si optamos por no permitir estos cambios, lo mejor es modificar la publicación de mezcla para que sean artículos sólo de descarga
En la primera opción, conviene replantearse la topología, ya que si los cambios van a ser muy frecuentes, probablemente sea más eficiente una publicación de mezcla entre el Servidor 1 y el 2.
En el caso contrario (modificaciones sólo en la dirección 1->2->3), sin embargo, puede convenirnos mantener la topología ¿Por qué mantener la publicación del servidor 2 como publicación de mezcla? Es posible que el servidor (o servidores) 3 sea un cliente con conectividad limitada (por ejemplo, sólo podría sincronizar una vez al día). En situaciones en las que no tenemos sincronización frecuente la replicación de mezcla es más eficiente.
El siguiente aspecto a tener en cuenta, es incluir el parámetro “@published_in_tran_pub=’true’” en los artículos de la publicación de mezcla. Si este parámetro no se incluye, los cambios que provengan del distribuidor de la publicación transaccional no se detectarán (serán interpretados con origen en el subscriptor de mezcla) y por lo tanto no se replicarán.
La causa de que no se repliquen los datos la encontramos en la lógica de los triggers. Sin ningún parámetro adicional en el artículo, el trigger incluye la siguiente sintaxis:
Que evita que se detecten como cambios a replicar los que provienen del subscriptor. Como vemos, esta lógica marca como pertenecientes a la topología merge cualquier agente de réplica.
Una vez modificado el artículo con la propiedad, observamos que esta línea ha cambiado por:
En este caso, aparece una lógica más compleja que no identificará como perteneciente a la topología de mezcla los cambios que provienen de otros agentes de replicación, y por lo tanto se incluirán estos cambios en la siguiente sincronización.
Es relativamente frecuente encontrarnos con servicios de SQL en clúster que se reinician debido a la lentitud de los discos. Veamos como se produce esto.
En el log de clúster solemos encontrar errores del tipo:
ERR [RES] SQL Server <SQL Server (Instancia)>: [sqsrvres] CheckQueryProcessorAlive: sqlexecdirect failed
ERR [RES] SQL Server <SQL Server (Instancia)>: [sqsrvres] printODBCError: sqlstate = 08S01; native error = 0; message = [Microsoft][SQL Server Native Client 10.0]Communication link failure
Este tipo de errores lo primero que nos hacen pensar es en errores de comunicación, y revisamos la red, drivers, etc. Sin embargo, es un tipo de error genérico que puede ser causado por otras causas. En este post nos vamos a centrar en la lentitud de discos.
A veces, el primer paso que nos puede indicar que el error no está relacionado con la red, está en el mismo cluster.log, si encontramos este tipo de mensajes:
ERR [RES] SQL Server <SQL Server (Instancia)>: [sqsrvres] checkODBCConnectError: sqlstate = 08001; native error = 1a; message = [Microsoft][SQL Server Native Client 10.0]Client unable to establish connection because an error was encountered during handshakes before login. Common causes include client attempting to connect to an unsupported version of SQL Server, server too busy to accept new connections or a resource limitation (memory or maximum allowed connections) on the server.
Este mensaje nos avisa de que la conexión no se puede crear debido a una limitación de recursos en el propio servidor, que le impide aceptar nuevas conexiones.
Otra pista importante nos la puede dar el errorlog, si encontramos mensajes del tipo:
spid6s SQL Server has encountered 2 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [R:\Logs\DBlog.LDF] in database [DB] (5). The OS file handle is 0x0000000000000A64. The offset of the latest long I/O is: 0x0000002eb3a600
Este mensaje puede no aparecer aunque tengamos un tiempo de respuesta lento en los discos; la razón es que este mensaje sólo aparece cuando la operación de I/O dura más de 15 segundos. Es decir, si una operación dura catorce segundos y medio, no tendremos este mensaje, pero no podemos decir que estemos ante unos discos rápidos. Si no vemos este mensaje, tendremos que revisar los contadores de rendimiento, en particular Avg. Disk Sec/Read y Avg. Disk Sec/Write
Ahora bien: ¿Qué le impide al servidor SQL crear una nueva conexión? Es lógico pensar que las consultas irán lentas en un servidor con lentitud de discos, pero no es inmediato entender por qué no se puede crear una nueva conexión.
Tenemos más datos en el mensaje del errorlog:
-El spid que está sufriendo la lentitud de los discos tiene un número menor de 50; por lo tanto es un proceso de sistema
-El archivo en el que está realizando la operación es de tipo log de transacciones
En este caso, lo más probable es que este proceso de sistema sea el checkpoint o el log writer (los procesos que utilizan el log de transacciones). Si en dicho momento hubiésemos estado delante del servidor, podríamos comprobarlo por ejemplo usando sys.sysprocesses.
La lentitud en cualquiera de estos dos procesos de sistema provocará que el resto de transacciones en esta base de datos tenga que esperar, no dejando threads libres en el servidor. Por lo tanto, a la hora de crear una nueva conexión, no habrá recursos para la misma. Como resultado, fallará la comprobación de isAlive del clúster y reiniciará el servicio.
Supongamos que hemos desarrollado un objeto personalizado de SSIS, por ejemplo siguiendo la información en: http://msdn.microsoft.com/en-us/library/ms403361.aspx, ¿cómo podemos añadirlo a un paquete de Integration Services en el que ya estamos trabajando?
En este ejemplo vamos a usar el componente “SSIS Delimited File Source” descargado de http://ssisdfs.codeplex.com/.
El primer paso es copiar la dll que hemos generado en la ruta C:\Program Files\Microsoft SQL Server\110\DTS\Binn (en el caso de una instalación por defecto). Sin embargo, si abrimos el editor, veremos que aún no nos lo muestra:
Para añadirlo en el visor, abrimos el menú “Tools”, “Choose toolbox items”. Vemos que nuestro componente aparece, pero no está seleccionado:
Una vez seleccionado, vemos que ahora sí nos aparece el objeto para ser añadido:
Recurrentemente, encontramos problemas causados por tener habilitado “priority boost” en una instancia de SQL.
Este parámetro no está recomendado, como se puede leer en: http://support.microsoft.com/kb/319942/es-es
Al habilitar el priority boost, el servicio de SQL se ejecuta con prioridad alta, esto implica que compite con otros servicios o ejecutables en la misma máquina. Los problemas causados al habilitar esta opción son muy variados, y no suelen mostrar síntomas claros. Entre ellos hemos encontrado:
-Reinicios inesperados del servicio de SQL
-Pérdida de conectividad de las aplicaciones
-Failover, cuando el servicio de SQL se encuentra en clúster
-100% CPU
-Distintos fallos de los agentes de replicación
-Planes de mantenimiento que no se ejecutan correctamente
Por lo tanto, si en un servidor encontramos comportamientos anómalos teniendo esta opción activada, una primera prueba es deshabilitarla. Así mismo, recomendamos deshabilitarla incluso en sistemas que aún no han mostrado problemas, de forma preventiva.
Primero, que significa hekaton, hekaton es una palabra griega (ἑκατόμ) que significa cien. Para Microsoft Hekaton es el codename de una nueva característica que se introducirá en la siguiente versión de SQL Server, Hekaton es un motor relacional en memoria (http://en.wikipedia.org/wiki/In-memory_database) siguiendo la filosofía de SAP HANA (http://en.wikipedia.org/wiki/SAP_HANA) o Oracle TimesTen (http://en.wikipedia.org/wiki/TimesTen) pero con una gran diferencia, mientras que HANA o TimesTen son productos separados de la base de datos relacional Hekaton se va a integrar dentro de SQL Server.
Hekaton empieza como un proyecto de colaboración entre Microsoft Research y el grupo de SQL Server en 2009, la principal causa de este proyecto es que en los modelos tradicionales la base es que los datos están en disco y son almacenadas como paginas en disco, esto crea un overhead grande a la hora de acceder a registros, si los registros están siempre en memoria el acceso a los datos se simplifica lo que hace que tengamos estructuras de datos mas simples optimizadas para memoria.
El primer paso fue moverse de una aproximación particionada (que lo que hace es asimilar a un sistema multiprocesador a un sistema distribuido) hacia un diseño sin bloqueos lo que incrementa la escalabilidad.
Los bloqueos son sistemas de sincronización para evitar corrupción en sistemas concurrentes, desgraciadamente esto crea cuellos de botella en sistema multiprocesador y limita el uso de cpu.
Hekaton utiliza un sistema sin bloqueos (optimista), nunca se bloquea datos de las estructuras, el reto de este sistema es proporcionar el beneficio de un sistema sin bloqueos y evitar corrupción, es donde entra el control de visiones (MVCC – multiversion concurrency control).
MVCC, ha demostrado en las pruebas que es ideal para un sistema con alta carga y alta contención, en un sistema de concurrencia de una sola versión los datos son sobrescritos en cada cambio, MVCC maneja los cambios marcando los datos antiguos como obsoletos y añadiendo una nueva versión, en cualquier momento hay diferentes versiones de los datos, pero solo una es la última. El gran beneficio es que las actualizaciones añaden nuevas versiones sin interferir en las lecturas concurrentes.
Hekaton implementa una nueva forma de motor transaccional MVCC, en el siguiente enlace se puede ver mas información sobre este motor (High-Performance Concurrency Control Mechanisms for Main-Memory Databases)
Además del control concurrente de versiones hay otros cambios, como un nuevo árbol binario para almacenar los datos, este nuevo árbol binario se llama Bw-Tree, aprovechando la filosofía optimista sin bloqueos de Hekaton se ha optimizado la estructura para ofrecer un mejor rendimiento a nivel de cache del procesador. Podeis leer mas sobre este nuevo árbol binario aquí: http://research.microsoft.com/apps/pubs/default.aspx?id=178758
Tradicionalmente cuando se implementa un mecanismo sin bloqueos la primera opción es una “skiplist” (http://en.wikipedia.org/wiki/Skiplist) ya que se percibe más ligero que un árbol binario(B-Tree) el Bw-Tree demuestra que esto es falso y se puede tener una implementación de un árbol binario de mayor rendimiento que una skiplist.
Una de las mayores empresas de apuestas online (BWIN) colabora a la hora de probar Hekaton en entornos reales, BWIN tenia un problema de rendimiento en su web (15.000 peticiones/segundo) y no escalaba más, después de implementar Hekaton en parte del sistema el problema se solucionó llegando las pruebas de carga hasta 250.000 peticiones/segundo. Podéis comprobar la experiencia en el siguiente video:
El proyecto de Hekaton nace gracias a la colaboración entre Microsoft Research y el grupo de SQL Server, según sepamos mas de esta tecnología os iremos actualizando.
Hekaton aumentando el rendimiento cien veces.
http://research.microsoft.com/en-us/news/features/hekaton-122012.aspx
http://blogs.technet.com/b/dataplatforminsider/archive/2012/12/11/how-fast-is-project-codenamed-hekaton-it-s-wicked-fast.aspx
Pablo Gavela López – Ingeniero de Soporte de SQL Server
A la hora de crear un índice en una de nuestras tablas, especialmente si es de un tamaño considerable, una de las preguntas que nos pueden surgir es: ¿Cuánto espacio nos va a ocupar?
Veamos un ejemplo concreto, y luego trataremos de explicarlo. Imaginemos que tenemos una tabla con los clientes de un gimnasio, con una primary key que sería el número de socio, y que realizamos muchas búsquedas basadas en el número de teléfono del cliente. Nos estaríamos planteando crear un índice no-clúster para el número de teléfono.
Nuestra tabla sería la siguiente:
Esta tabla tiene un millón de socios (pongamos que es un gimnasio con mucho éxito), y el tamaño de la tabla observamos que es:
Si creamos el índice no clusterizado, utilizando la constraint unique, vemos que ocupa:
Veamos cómo es la estructura de este índice no clúster:
En el nivel inferior, cada línea tendrá:
-El número de teléfono, de tipo char(9) que ocupará 9 bytes
-El puntero a la página donde se encuentra el dato, 6 bytes
-Un overhead de 2 bytes
Por lo tanto, tendremos 17 bytes en cada entrada. Además por cada una de ellas, necesitaremos dos bytes en el slot array (http://blogs.msdn.com/b/askjay/archive/2011/01/07/what-is-a-slot-array.aspx). En total, 19 bytes.
En cada página, tenemos disponibles 8096 bytes (8K de página menos el overhead), por lo que en cada página del último nivel, podemos incluir (8096/19)= 426 entradas. Como tenemos un millón de registros, necesitaremos (1000000/506=2347,41), como necesitamos un número entero de páginas: 2348.
Hay que tener en cuenta que este número de páginas indica tan sólo el número de páginas en el nivel inferior. A continuación, existiría otro nivel que en lugar de referenciar la página donde está el dato, referencia la página del nivel inferior. Y por último, el nivel raíz, que apunta a este nivel intermedio.
Estamos encontrándonos con un problema después de la instalación de SQL Server 2012 Service Pack 1.
Después de instalar el Service Pack 1 de SQL Server 2012 uno o mas de los siguientes síntomas pueden aparecer:
El uso de CPU es casi del 100%, el consumidor principal de CPU es msiexec.exe
El archivo '%systemroot%\system32\config\SOFTWARE' empieza a crecer de manera indefinida, se crean un montón de registros en las siguientes claves del registro:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\NGenService\Roots
o
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727\NGenService\Roots
Los siguientes errores aparecen en el visor de eventos de aplicación:
1101 de “.NET Runtime Optimization”
1001 de “MSInstaller
Es imposible arrancar Management Studio, cada vez que se intenta iniciar el siguiente error aparece:
"Cannot find one or more componente. Please reinstall the application".
Debido a un problema de firmado en algunos ensamblados el proceso de ngen intenta recompilar estos ensamblados de forma indefinida provocando los síntomas descritos.
1 – Parar la ejecución de ngen para evitar el uso de CPU y la generación de claves en el registro con los siguientes comandos:
- %SystemRoot%\Microsoft.Net\Framework\v4.0.30319\ngen queue pause - %SystemRoot%\Microsoft.Net\Framework64\v4.0.30319\ngen queue pause
2 – Instalar el Cumulative Update 2 de SQL Server 2012 Service Pack 1: http://support.microsoft.com/kb/2790947
Esto instala los ensamblados correctos evitando la generación de nuevas claves en el registro
3 – Ejecutar los siguientes comandos para eliminar el exceso de claves en el registro:
- %SystemRoot%\Microsoft.Net\Framework\v4.0.30319\ngen eqi - %SystemRoot%\Microsoft.Net\Framework64\v4.0.30319\ngen eqi
Si el registro de Windows a crecido de forma exagerada que hace que la máquina no rinda del todo bien deberemos compactar el registro, para ello:
1 – Arrancar Windows en modo reparación (F8 en el arranque)
2 – Abrir un línea de comandos
3 – Buscar la unidad donde está la instalación de Windows [drive] puedes encontrarla en el dialogo “System Recovery Options” Sustituir [drive] por esta unidad en las instrucciones.
4 – Navegar al directorio Windows\system32\config
[drive]:
cd [drive]:\Windows\System32\config
5 – Cargar la clave de registro SOFTWARE
reg load HKLM\Bloated SOFTWARE
6 – Start REGEDIT
7 – Click derecho en HKEY_LOCAL_MACHINE\Bloated y hacer clieck en export. Salvar el archivo como “Registry Hive File” en “[drive]:\Windows\system32\config\SOFTWARENew”
8 – Cerrar REGEDIT, esto es necesario para evitar que REGEDIT bloquee el archivo SOFTWARE
9 – Descargar la rama Bloated del registro
reg unload HKLM\Bloated
10 – Renombrar [drive]:\Windows\system32\config\SOFTWARE a [drive]:\Windows\system32\config\SOFTWAREOld
11 - Renombrar [drive]:\Windows\system32\config\SOFTWARENew a [drive]:\Windows\system32\config\SOFTWARE
12 – Salir de la línea de comandos y reiniciar la máquina.
Podéis leer mas información sobre este problema aquí: http://support.microsoft.com/kb/2800050
Si el archivo '%systemroot%\system32\config\SOFTWARE' ha alcanzado los 2GB y el sistema no arranca la mejor alternativa es reinstalar el sistema operativo.
Para cargar el registro en el modo reparación “REG LOAD” se necesita una cantidad importante de RAM, para un archivo SOFTWARE de 2GB se necesitan en torno a 8GB de RAM.
• Síntoma
El cliente experimenta el siguiente mensaje de error al ejecutar un informe de Reporting Services causado al conectarse a las bases de datos de SQL Server y a los cubos de SSAS desde Reporting Services.
· Error al procesar el informe. (rsProcessingAborted)
· No se puede crear una conexión al origen de datos 'DataSource1'. (rsErrorOpeningConnection)
· The connection either timed out or was lost.
· Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
· An existing connection was forcibly closed by the remote host
Al ejecutar el informe desde el servidor de Reporting Services el error no se produce.
Las credenciales usadas en el datasource del informe son Windows Integrada. Si cambiamos las credenciales de conexión al datasource por Credenciales Almancenadas, el error no se produce, ni desde el servidor de Reporting Services ni desde una máquina cliente.
Entorno:
1 máquina cliente desde donde reprocimos los mensajes de error anteriores al ejecutar un informe.
1 servidor SSRS
1 servidor SQL Server + SSAS
• Causa
Al usar credenciales de Windows Integrada en el datasource de un informe, si ejecutamos el informe desde una máquina cliente, las credenciales del usuario harán un doble salto: pasando de la máquina cliente al servidor de Reporting Services y de este al servidor de base de datos.
Para este tipo de entornos, Reporting Services debe utilizar la autenticación Kerberos.
En este artículo se describen los diferentes pasos a seguir para configurar Kerberos en este tipo de entornos.
• Configuración
1. En el archivo de configuración de rsreportserver.config (C:\Program Files\Microsoft SQL Server\MSRS11.MSSQLSERVER\Reporting Services\ReportServer) la autenticación configurada debe ser Negotiate.
<AuthenticationTypes>
<RSWindowsNegotiate/>
</AuthenticationTypes>
2. Configurar los SPNs de la cuenta de servicio de los tres servicios (SSRS,SQL SERVER y SSAS) usando la línea de comando:
setspn -s SPN dominio\CuentaDeServicio * El comando setspn -s impide tregistrar un SPN que ya está registrados, evitando así la duplicidad de SPN para una cuenta. * Para registrar un SPN se necesita que el usuario que lo hace sea administrador del dominio.
setspn -s SPN dominio\CuentaDeServicio
* El comando setspn -s impide tregistrar un SPN que ya está registrados, evitando así la duplicidad de SPN para una cuenta.
* Para registrar un SPN se necesita que el usuario que lo hace sea administrador del dominio.
a. SPNs necesarios en Reporting Services (deben registrarse para la cuenta de servicio de SSRS).
HTTP/<hostname> HTTP/<hostname.dominio> donde hostname es el utilizado en las URLs de las sites de SSRS: /reports">http://<hostname>/reports
HTTP/<hostname>
HTTP/<hostname.dominio>
donde hostname es el utilizado en las URLs de las sites de SSRS:
/reports">http://<hostname>/reports
b. SPNs necesarios en SQL SERVER y SSAS
(Siempre nos referimos a las base de datos utilizada por el informe y definida en su data source y en la instancia de SQL Server que aloja dicha base de datos). INSTANCIAS PREDETERMINADAS SQL SERVER (deben registrarse para la cuenta de servicio de SQLSERVER). Si se trata de una instancia por defecto (MSSQLSERVER) que escucha en el puerto por defecto: MSSQLSvc/<serverhostname.dominio>:1433 Para una instancia por defecto que escucha en un puerto distinto a TCP: MSSQLSvc/<serverhostname.dominio> SSAS (deben registrarse para la cuenta de servicio de SSAS). Para una instancia por defecto: MSOLAPSvc.3/serverHostName.dominio MSOLAPSvc.3/serverHostName INSTANCIAS CON NOMBRE SQL SERVER (deben registrarse para la cuenta de servicio de SQLSERVER). Para una instance nombrada que escucha en un puerto TCP MSSQLSvc/<serverhostname.dominio>:puerto Para una instance nombrada que escucha en un puerto distinto a TCP: MSSQLSvc/<serverhostname.dominio>:nombredeinstancia SSAS (deben registrarse para la cuenta de servicio de SSAS). Para una instancia con nombre: MSOLAPSvc.3/serverHostName.dominio:instanceName MSOLAPSvc.3/serverHostName:instanceName Para instancias con nombre es necesario configurar los SPNs para SQL Browser: MOLAPDisco.3/serverHostName MOLAPDisco.3/serverHostName.dominio
(Siempre nos referimos a las base de datos utilizada por el informe y definida en su data source y en la instancia de SQL Server que aloja dicha base de datos).
INSTANCIAS PREDETERMINADAS
SQL SERVER (deben registrarse para la cuenta de servicio de SQLSERVER).
Si se trata de una instancia por defecto (MSSQLSERVER) que escucha en el puerto por defecto:
MSSQLSvc/<serverhostname.dominio>:1433
Para una instancia por defecto que escucha en un puerto distinto a TCP:
MSSQLSvc/<serverhostname.dominio>
SSAS (deben registrarse para la cuenta de servicio de SSAS).
Para una instancia por defecto:
MSOLAPSvc.3/serverHostName.dominio
MSOLAPSvc.3/serverHostName
INSTANCIAS CON NOMBRE
Para una instance nombrada que escucha en un puerto TCP
MSSQLSvc/<serverhostname.dominio>:puerto
Para una instance nombrada que escucha en un puerto distinto a TCP:
MSSQLSvc/<serverhostname.dominio>:nombredeinstancia
Para una instancia con nombre:
MSOLAPSvc.3/serverHostName.dominio:instanceName
MSOLAPSvc.3/serverHostName:instanceName
Para instancias con nombre es necesario configurar los SPNs para SQL Browser:
MOLAPDisco.3/serverHostName MOLAPDisco.3/serverHostName.dominio
3. Habilitar para delegación las cuentas de máquina y las cuentas de servicio requeridas en el entorno en el Directorio Activo.
a. Comprueba que la opción "Account is sensitive and cannot be delegated" para la cuenta especifica no está seleccionada (está opción se encuentra en la pestaña “Cuenta” de las propiedades de la cuenta seleccionada). En la pestaña "Delegación" podrá configurar una de las siguientes opciones: b. Full delegation: la cuenta se habilita para delegación para cualquier servicio. c. Constrained delegation: la cuenta se habilita sólo para aquerllos servicios que se configuren en esta pestaña.
a. Comprueba que la opción "Account is sensitive and cannot be delegated" para la cuenta especifica no está seleccionada (está opción se encuentra en la pestaña “Cuenta” de las propiedades de la cuenta seleccionada).
En la pestaña "Delegación" podrá configurar una de las siguientes opciones:
b. Full delegation: la cuenta se habilita para delegación para cualquier servicio.
c. Constrained delegation: la cuenta se habilita sólo para aquerllos servicios que se configuren en esta pestaña.
Más información :
Registrar un nombre principal de servicio para las conexiones con Kerberos
http://msdn.microsoft.com/es-es/library/ms191153.aspx
Cómo configurar SQL Server 2008 Analysis Services y SQL Server 2005 Analysis Services para utilizar la autenticación Kerberos
(este artículo también aplica SSAS 2008 R2)
http://support.microsoft.com/kb/917409
Si el error continua reproduciéndose...
1. Comprobar que no existan SPNs duplicados para ninguna cuenta de servicio. Esta comprobación la realizamos mediante la línea de comandos: setspn –x.
Si existe alguna lo eliminamos mediante el comando:
Setspn –d SPN dominio\cuentadeservicio
2. Si en algún momento anterior a la configuración de Kerberos hemos cambiado la cuenta de servicio de cualquiera de estos tres servicios, asegurarse de que este cambio se ha realizado mediante la consola de administración del servicio correspondiente:
* Reporting Services Configuration Manager
* SQL Server Configuration Manager.
En caso contrario, la cuenta de servicio modificada no habrá sido completamente actualizada.
3. Si los puntos 1 y 2 están comprobados habilitar los logs verbose de Kerberos en el servidor de base de datos y ver el mensaje de error en los logs de eventos de sistema.
Es importante deshabilitar los estos logs una vez reproducido el problema para no tener impacto sobre el servidor.
Cómo habilitar el registro de sucesos de Kerberos
http://support.microsoft.com/kb/262177
· Beatriz Sanagustín -
Ingeniero de soporte de Reporting Services
O porque necesito 10.000.000 archivos de datos para tempdb.
A lo largo de las versiones de SQL Server el uso de tempdb se ha hecho cada vez mayor para diferentes partes del sistema, el mayor cambio se vivió de 2000 a 2005 y en 2008 este uso se incrementó un poquito más. Por tanto es crítico tener una configuración correcta para tempdb.
tempdb es usado principalmente en:
Fácil, tantos como cores físicos tenga nuestra máquina http://msdn.microsoft.com/en-us/library/ms175527.aspx hasta un máximo de 8, a partir de 8 archivos deberemos estudiar si el coste de tener muchos archivos para tempdb es menor que las mejoras alcanzadas por tener tantos archivos, esto depende del tipo de carga que tengamos en tempdb y debe ser estudiado para cada situación.
La mejor forma es monitorizar las esperas con la siguiente query:
SELECT wt.session_id AS [Waiting Session ID], waiting_text.text AS [Waiting SQL], wt.wait_type, bc.session_id AS [Blocking Session ID], blocking_text.text AS [Blocking SQL], resource_description FROM sys.dm_os_waiting_tasks wt LEFT OUTER JOIN sys.dm_exec_connections wc on wt.session_id=wc.session_id LEFT OUTER JOIN sys.dm_exec_connections bc on wt.blocking_session_id=bc.session_id OUTER APPLY sys.dm_exec_sql_text(wc.most_recent_sql_handle) AS waiting_text OUTER APPLY sys.dm_exec_sql_text(bc.most_recent_sql_handle) AS blocking_text
Dependiendo del tipo de espera y recurso el tipo de contención es diferente y la solución también.
Primero vamos a explicar como leer los recursos de página, un recurso de página se compone de tres partes X:Y:Z donde:
X – ID de la base de datos (SELECT * FROM sys.databases WHERE database_id = X para obtener la base de datos)
Y – ID del archivo de la base de datos (SELECT * FROM sys.master_files where database_id = X and file_id = Y para obtener el archivo en cuestión)
Caso 1 - Tipo de espera PAGEIOLATCH_XX – Recurso 2:Y:Z
PAGEIOLATCH_XX (XX cualquier valor) Indica que SQL a iniciado una lectura de disco y está esperando a que la pagina esté en memoria para continuar la ejecución de la query.
En este caso deberemos
1 – Estudiar si el rendimiento de los discos es adecuado
2 – Separar diferentes archivos de tempdb en diferentes discos para mejorar el rendimiento de entrada salida
Caso 2 – Tipo de espera PAGALATCH_UP – Recurso 2:Y:1 o "2:Y:P (P múltiplo de 8088)
La pagina 1 y las páginas múltiplo de 8088 son un tipo de página especial llamadas PFS (Page Free Space) estas paginas sirven para llevar la cuenta de que páginas están usadas y cuales no y cuando se crea una nueva tabla debemos consultarlas y actualizarlas convenientemente, para evitar corrupción SQL debe serializar las actualizaciones a estas paginas.
Para solucionar este tipo de contención deberemos:
1 – Crear tantos archivos de base de datos como cores físicos tenga la máquina
SQL Server intenta asignar el trabajo nuevo a diferentes archivos de base de datos al tener mas archivos de base de datos reducimos la probabilidad de que dos threads ataquen el mismo archivo mismo PFS.
2 – En casos extremos deberemos habilitar el traceflag 1118 al inicio de SQL Server. http://blogs.msdn.com/b/psssql/archive/2008/12/17/sql-server-2005-and-2008-trace-flag-1118-t1118-usage.aspx
Por defecto SQL Server cuando crea una nueva tabla reserva las primeras paginas de 1 en 1, a la novena pagina las paginas son reservadas de 8 en 8, esto es para optimizar el espacio. Con esta opción activada SQL Server reserva las páginas de 8 en 8 desde el principio reduciendo los viajes al PFS.
Un saludo,
Pablo Gavela López – Microsoft Customer Support Services