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:
Raquel Vicente de la Rosa
Ingeniero de Soporte de SQL Server
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
En esta entrada vamos a ver que recomendaciones tenemos para configurar la memoria:
¿Que es eso de ‘max server memory’?
La eterna pregunta de ¿cuánta memoria doy a mi servidor?
¿Que problemas pueden surgir si tengo poca memoria?
Empecemos por la primera pregunta:
‘max server memory’ es una de las configuraciones avanzadas de memoria que tiene SQL Server, esta opción limita el tamaño máximo que puede tener el Buffer Pool (Cache usada para las páginas de las bases de datos).
Las recomendaciones sobre el valor que debemos tener en este parámetro se pueden encontrar aquí:
http://msdn.microsoft.com/en-us/library/ms178067.aspx Por defecto SQL maneja su propia memoria, en la mayoría de los casos que SQL Server es el único proceso que requiere grandes cantidades de memoria no es ningún problema. Pero si tenemos otras tareas que sean grandes consumidoras, por ejemplo más de una instancia de SQL Server, o un trabajo de SSIS que trabaje con gran cantidad de datos entonces es cuando pueden surgir los problemas.
Lock Pages in Memory es una función que nos proporciona Windows para que una aplicación pueda bloquear memoria física y esta no sea paginada. Esto le viene muy bien a SQL Server, evidentemente por temas de seguridad ningún proceso puede hacer uso de esta característica si no tiene los permisos necesarios, para que SQL Server haga uso simplemente tenemos que darle los permisos y reiniciar la instancia. Nunca habilitar Lock Pages in Memory sin antes haber establecido un valor para “max server memory”
http://msdn.microsoft.com/en-us/library/ms190730.aspx
Las recomendaciones generales son las siguientes:
Por que recomendamos lock pages in memory para Windows 2003
Windows 2003 tiene un algoritmo de paginación muy agresivo y puede paginar una gran porción de la memoria de SQL Server afectando negativamente al rendimiento. ( http://support.microsoft.com/kb/918483 )
A continuación
El máximo consumidor de memoria en SQL Server es el buffer pool, por tanto deberemos dimensionar según la cantidad de datos que va a mover SQL Server, por ejemplo si nuestras bases de datos ocupan 10GB tener 20GB no va ayudar mucho más que tener 16 ya que prácticamente todos los datos van a residir en memoria. Para tomar la decisión de ampliar la memoria contamos principalmente con dos contadores de rendimiento dentro del grupo Buffer Manager (http://msdn.microsoft.com/en-us/library/aa173929(v=sql.80).aspx), a saber:
- Buffer Cache Hit Ratio: Porcentaje de páginas que han sido encontradas en memoria sin necesidad de acceder al disco. La recomendación es que este contador se mantenga en un 99%
- Page life expectancy: Número de segundos que una pagina está en el buffer sin que sea referenciada. Si este contador se mantiene por debajo de los 300 segundos deberemos pensar en aumentar la cantidad de RAM del sistema.
También es posible que debido a la falta de un índice tengamos estos valores bajos ya que en vez de hacer un “seek” sobre un índice hacemos un “scan” necesitando mas memoria para resolver la query, por tanto antes de ampliar RAM deberemos estudiar si optimizando nuestras queries podemos reducir el consumo de RAM.
y por último
El principal problema que veremos es un mayor acceso a los discos con la consiguiente perdida de rendimiento. Intermitentemente SQL Server imprime en el errorlog información de memoria si detecta que hay fallo de memoria, en casos extremos SQL puede dejar de responder generando volcados de memoria, generalmente de tipo Non-yielding IOCP Listener seguido de un mensaje relaccionado con la memoria como por ejemplo: “LazyWriter: warning, no free buffers found”
2012-08-13 09:18:32.62 Server **Dump thread - spid = 0, PSS = 0x0000000000000000, EC = 0x0000000000000000 2012-08-13 09:18:32.65 Server ***Stack Dump being sent to C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\SQLDump0001.txt 2012-08-13 09:18:32.65 Server * ******************************************************************************* 2012-08-13 09:18:32.65 Server * 2012-08-13 09:18:32.65 Server * BEGIN STACK DUMP: 2012-08-13 09:18:32.65 Server * 08/13/12 09:18:32 spid 0 2012-08-13 09:18:32.65 Server * 2012-08-13 09:18:32.65 Server * Non-yielding IOCP Listener 2012-08-13 09:18:32.65 Server * 2012-08-13 09:18:32.65 Server * ******************************************************************************* 2012-08-13 09:18:32.65 Server * ------------------------------------------------------------------------------- 2012-08-13 09:18:32.65 Server * Short Stack Dump 2012-08-13 09:18:32.92 Server Stack Signature for the dump is 0x0000000000000278 2012-08-13 09:18:47.46 spid2s LazyWriter: warning, no free buffers found.
Con esto termino este articulo, cuidado con asignar poca memoria al servidor!
En MSDN hemos publicado una serie de artículos introductorios a SQL 2012, podéis encontrarlos en el siguiente enlace: http://msdn.microsoft.com/es-es/sqlserver/hh974403
¡Esperamos que os sean útiles!
Si os encontráis con este mensaje de error cuando intentáis ejecutar un informe desde a Report Manager (/reports">http://<servername>/reports) aquí tenéis una posible explicación al problema.
Si los síntomas que detectáis son los siguientes:
* Este error lo reproducís sólo cuando accedéis desde una determinada máquina de trabajo. * Los usuarios afectados pueden acceder correctamente al informe desde otra máquina.
entonces es muy posible que el problema lo esté causando una clave de registro en la máquina afectada que contiene un valor con un carácter ilegal. Aquí os dejo más detalles y la solución a este problema.
Cuando instalas programas de terceros o instalas determinados componentes de Windows como Microsoft.NET Framework o Windows XP SP2, se añaden tokens a la cadena de registro del User Agent. Como este registro se crea para la versión concreta del navegador que estés utilizando en el momento de la instalación, aunque hayas actualizado la versión de tu navegador esta clave de registro continúa existiendo.
Nos centramos en la clave de registro creada para Internet Explorer (más información en http://msdn.microsoft.com/es-es/library/ms537503(v=vs.85).aspx )
Los tokens que los programas necesitan añadir a la cadena de User Agent se añaden a la siguiente clave de registro. HKEY_LOCAL_MACHINE (or HKEY_CURRENT_USER) SOFTWARE Microsoft Windows CurrentVersion Internet Settings (Internet Explorer version) User Agent Pre Platform Token = Value Post Platform Token = Value
Si los valores que se añaden contienen algún carácter ilegal, como la letra Ñ en nuestro abecedario o caracteres cirílicos usados en otros alfabetos, el siguiente error es devuelto al usuario: "Specified value has invalid Control characters.Parameter name: value"
Para solucionar este problema, desde la máquina que presenta este error, accede a la consola de registro (run --> regedit) y busca la clave: HKCU (o HKLM)\Software\Microsoft\Windows\CurrentVersion\Internet Settings\(IE version)\User Agent\Post Platform (o Pre Platform)
Si los valores de estos tokens contienen un carácter ilegal (recordemos un ejemplo, la letra Ñ) y la versión de IE es anterior a la que actualmente usas sigue los siguiente pasos:
1. Haz un backup del registro (siempre recomendado antes de realizar cualquier cambio) http://support.microsoft.com/kb/322756/
2. Elimina las entradas que contienen el carácter ilegal.
4. Accede de nuevo a reporting services y comprueba que el problema se ha resuelto.
Al ser una clave de registro creada por una versión antigua de Internet Explorer este cambio no tiene impacto negativo en la funcionalidad de la máquina.
Si detectas cualquier problema tras el cambio restaura el backup que has hecho del registro.
Información adicional sobre el agente de usuario
User Agent es usado para identificar la aplicación (normalmente un buscador cliente) que está pidiendo la información al servidor. Cuando accedes a una página web, el buscador desde el que accedes manda la cadena de user agent al servidor que aloja la web que estás visitando. Esta cadena de conexión contiene tokens que varían según el navegador utilizado. Generalmente estos tokens proveen la siguiente información: indica el buscador que utilizas, la versión del buscador y detalles de sobre tu sistema como el sistema operativo y la versión. El servidor web usa esta información para proveer el contenido que se adapta a tu buscador.
Beatriz Sanagustín -