La pregunta, (me imagino la mayor�a de las respuestas) es: �que estrategia
de "optimizaciones" de BBDD me recomendais)?
Como plan de mantenimiento hago esto (es lo mismo que hac�a con SQL 2000,
pero me da la sensaci�n de que ahora con 2008 no es lo bueno que deber�a):
* Reducir BBDD.
* Backup completo.
* Backup del log de transacciones (se repite cada seis horas).
* Reorganizar �ndices (�nicamente dos d�as a la semana).
�Es correcto?
Con el servidor antiguo, (menos recursos, 32bits y SQL 2000) la tarea
"reorganizar �ndices" tardaba seis horas (BBDD de 200Gb), sin embargo, ahora
con el servidor nuevo (todav�a en pruebas) que es mucho mas potente, de
64bits y SQL 2008 tarda �18 horas!, con lo que supongo que algo estoy
haciendo mal.
�Podr�ais orientarme?
Gracias una vez mas por vuestra magn�fica ayuda.
Diego Fern�ndez
El plan de mantenimiento es m�s o menos el mismo. No recomiendo en absoluto
reducir el tama�o de la base de datos, con eso s�lo consigues mayor
fragmentaci�n y por tanto peor rendimiento. A cambio a�adir�a la opci�n de
comprobar la integridad de la base de datos, algo que no parece que hagas.
Te recomiendo implementar la soluci�n de Ola Hallengren
(http://ola.hallengren.com/), que es mejor (por muchas razones) que los
planes de mantenimiento de SQL Server.
--
-----------------------------
"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es f�cil, si ambas est�n congeladas."
Edward V. Berard, ingeniero inform�tico
"Diego Fern�ndez" <dfern...@grupo-centauro.com> wrote in message
news:E4A558F5-A3C6-477E...@microsoft.com...
La BBDD est� configurada igual, a excepci�n de que el tipo de almacenamiento
ha cambiado (antes era fibra �ptica y ahora es iSCSI), pero en teor�a
deber�a ir incluso m�s r�pido el nuevo (iSCSI) debido a que tiene mas ancho
de banda que el antiguo.
No conoc�a la soluci�n de Ola Hallengren, voy a leerme la documentaci�n y
intentar utilizarla.
Una pregunta sobre los filegroups: si est�n el la misma unidad l�gica (es
decir, en los mismos discos f�sicos y mismo RAID) �se consigue algo poniendo
mas de un fichero (tipo bbdd.mdf y bbdd_1.ndf)?, es que he leido que se
recomienda poner esos dos ficheros (mdf y ndf) pero no entiendo cual puede
ser la "mejor�a" si est�n en el mismo recurso de hardware.
Un saludo.
Diego Fern�ndez
"Carlos Sacristan" <nom...@nomail.com> escribi� en el mensaje de
noticias:OzvI8XDa...@TK2MSFTNGP04.phx.gbl...
En cuanto a los ficheros, la idea para mejorar el rendimiento es separarlos
en discos distintos. Si est�n en el mismo no vas a obtener mejora en ese
sentido. Existe un art�culo muy bueno sobre dise�o f�sico en
http://technet.microsoft.com/es-es/library/cc966414%28en-us%29.aspx?ppud=4;
en �l se hace referencia a
http://technet.microsoft.com/es-es/library/cc966460%28en-us%29.aspx en el
que hay un apartado espec�fico que responde detalladamente a las preguntas
- �cu�ntos archivos crear por grupo de archivos?
- �cu�ntos grupos de archivos crear?
- �c�mo colocar los objetos de usuario (tablas e �ndices) en estos
grupos de archivos?
- �c�mo configurar el hw para obtener el m�ximo rendimiento?
- �hay que crear grupos de archivos en base de datos peque�as?
Recomiendo su lectura.
En cuanto a la soluci�n de Ola, la verdad es que cuando la descubr� me
pareci� muy buena, y seg�n he ido conoci�ndola mejor me parece a�n. Adem�s
puedes comentar con el creador cualquier tema que te surja (problemas y/o
mejoras), es una persona muy accesible en ese sentido.
--
-----------------------------
"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es f�cil, si ambas est�n congeladas."
Edward V. Berard, ingeniero inform�tico
"Diego Fern�ndez" <dfern...@grupo-centauro.com> wrote in message
news:uD%23274Da...@TK2MSFTNGP02.phx.gbl...
"The number of data files within a single filegroup should equal to the
number of CPU cores. "
No entiendo el motivo de esto, aunque no tengo ning�n problema en hacerlo.
A�n as�, como tengo 2 Xeon quadcore (Windows los ve como 16 n�cleos)...
�tendr�a que crear 16 ficheros o 8 ficheros?
No he vuelto a lanzar la optimizaci�n para ver si tardaba lo mismo, pero
ahora mismo est� lanzada la optimizaci�n mediante el proceso de Ola y ver�
cuanto tarda.
Bueno, contin�o "aprendiendo" lo que puedo...
Un saludo.
Diego Fern�ndez
"Carlos Sacristan" <nom...@nomail.com> escribi� en el mensaje de
noticias:e5licGEa...@TK2MSFTNGP04.phx.gbl...
En cuanto al n�mero de ficheros a crear, ser�a igual al n�mero de CPU que
SQL Server detecta. 2 CPU quadcore son 8 n�cleos, y as� los deber�a ver
Windows y por tanto SQL Server. �Dices que W detecta 16? �Est�s seguro que
s�lo tienes 2 quadcore?
--
-----------------------------
"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es f�cil, si ambas est�n congeladas."
Edward V. Berard, ingeniero inform�tico
"Diego Fern�ndez" <dfern...@grupo-centauro.com> wrote in message
news:uyxAu2F...@TK2MSFTNGP04.phx.gbl...
En el "administrador de tareas"-> pesta�a "rendimiento" me aparecen 16
procesadores, pero esto me ha ocurrido "desde siempre" con los procesadores
Xeon, que por cada uno dice que hay dos.
En el nuevo "monitor de recursos" de 2008, �nicamente aparecen 8.
En las "propiedades del servidor" del Management Studio, me dice que tengo
16 procesadores.
Obviamente, el dato "correcto" son 8 n�cleos, pero... �para SQL ser� lo
�ptimo 8 o 16?
Por otra parte, sobre "como colocar los datos (tablas, �ndices) en los
ficheros, aqu� creo que no tengo nada que hacer, ya que la BBDD es de
Navision (Dynamics Nav 2009) y toda esa gesti�n la hace la aplicaci�n.
Gracias otra vez por tu ayuda.
Diego Fern�ndez
"Carlos Sacristan" <nom...@nomail.com> escribi� en el mensaje de
noticias:#cxPc7Fa...@TK2MSFTNGP05.phx.gbl...
Normalmente no es una buena pr�ctica habilitar hyperthreading en un servidor
dedicado a SQL Server. Revisa si esto est� as� (en
http://blogs.msdn.com/arvindsh/archive/2008/12/19/windows-sql-server-and-multi-core-hyper-threading.aspx
se muestra una forma de ver el n�mero de sockets, n�cleos y CPU l�gicas)
Una vez que compruebes esto, lo suyo ser�a crear esos 8 ficheros (2 CPU x 4
n�cleos)
--
-----------------------------
"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es f�cil, si ambas est�n congeladas."
Edward V. Berard, ingeniero inform�tico
"Diego Fern�ndez" <dfern...@grupo-centauro.com> wrote in message
news:OixOdDG...@TK2MSFTNGP04.phx.gbl...
Efectivamente, el coreinfo de SysInternals me dice que tengo ocho n�cleos
con Hyper-threading, tal y como t� decias...
Esta es la informaci�n que saca:
Logical to Physical Processor Map:
**-------------- Physical Processor 0 (Hyperthreaded)
--**------------ Physical Processor 1 (Hyperthreaded)
----**---------- Physical Processor 2 (Hyperthreaded)
------**-------- Physical Processor 3 (Hyperthreaded)
--------**------ Physical Processor 4 (Hyperthreaded)
----------**---- Physical Processor 5 (Hyperthreaded)
------------**-- Physical Processor 6 (Hyperthreaded)
--------------** Physical Processor 7 (Hyperthreaded)
...
Voy a desactivar el Hyper-threading y crear esos ocho ficheros.
Adem�s de en tempdb y la BBDD de la aplicaci�n �lo hago con master, model,
etc...?
�Tengo que hacer 8 ficheros �nicamente para la parte de BBDD o tambi�n para
el Log de transacciones debo tener 8?
Gracias de nuevo.
Diego.
"Carlos Sacristan" <nom...@nomail.com> escribi� en el mensaje de
noticias:emMxRVGa...@TK2MSFTNGP06.phx.gbl...
El log de transacciones no se ve beneficiado por el hecho de tener m�s de un
fichero, ya que su naturaleza es circular y por tanto s�lo estar�a usando un
archivo cada vez.
En cuanto a lo de Navision, habr�a que mirar la garant�a, pero igual s� que
se puede modificar la base de datos que te crea la instalaci�n del producto
para que los datos (�ndices agrupados) vayan a un filegroup (marc�ndolo como
predeterminado) y crear otro filegroup para los �ndices no agrupados. Los
ficheros de esos filegroups estar�an en discos distintos, claro.
--
-----------------------------
"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es f�cil, si ambas est�n congeladas."
Edward V. Berard, ingeniero inform�tico
"Diego Fern�ndez" <dfern...@grupo-centauro.com> wrote in message
news:OD47P8Oa...@TK2MSFTNGP06.phx.gbl...
Si dices que el servidor es nuevo imagino que tendr�s un Xeon serie 5500
o 3500. Yo me pensar�a muy bien lo de desactivar SMT (Simultaneous Multi-Threading)
a ciegas .
Un saludo,
Rub�n Garrig�s
Solid Quality Mentors
Blog: http://blogs.solidq.com/es/elrincondeldba
Efectivamente es un Xeon serie 5500...
Lo desactivo �nicamente porque seg�n me comentan es "lo recomendado" para un
SQL Server...
Realmente, yo no se si es mejor o peor tenerlo activado.
�Puedes decirme el porque debo tenerlo o darme alguna referencia?
En lo que he leido sobre Hyper-threading, la verdad es que mis conocimientos
no me han llegado para saber como afectar� el tenerlo activo o no.
Un saludo y gracias.
Diego Fern�ndez
"Ruben Garrigos" <rgarrigo...@solidq.com> escribi� en el mensaje de
noticias:2ec7293338788...@news.microsoft.com...
La recomendaci�n de deshabilitar HT para SQL Server viene de lejos, pues
pod�a dar problemas de rendimiento. En
http://blogs.msdn.com/slavao/archive/2005/11/12/492119.aspx puedes leer una
prueba de ello. Esto es lo que conoc�a yo y fue por lo que te coment� eso en
mis respuestas.
Habl� con Rub�n despu�s de leer su respuesta y lo siguiente ser�a m�s o
menos lo que hay que aplicar ahora.
Parece ser que esta nueva generaci�n de procesadores han evolucionado ese
concepto de Hyperthreading (en
http://software.intel.com/en-us/blogs/2009/03/11/learning-experience-of-numa-and-intels-next-generation-xeon-processor-i/
se explica m�s t�cnicamente en qu� consiste) y en sistemas donde se realicen
muchas lecturas o escrituras peque�as (donde el paralelismo no suele ser muy
com�n, es decir, t�pico sistema OLTP) puede verse beneficiado de esta nueva
arquitectura. En
http://sqlblog.com/blogs/joe_chang/archive/2009/04/01/early-intel-nehalem-xeon-5500-performance-results.aspx
se comentan los resultados del test TPC-E con estos nuevos procesadores,
claramente mejores que los antiguos QuadCore.
El comentario de Rub�n iba m�s encaminado (entiendo yo) a que la "vieja"
recomendaci�n de deshabilitar HT en una m�quina donde vaya a correr SQL
Server no deber�a aplicarse sin m�s, sino realizando test de carga que
validen c�mo rinde mejor ese servidor.
Espero haber aclarado el tema.
--
-----------------------------
"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es f�cil, si ambas est�n congeladas."
Edward V. Berard, ingeniero inform�tico
"Diego Fern�ndez" <dfern...@grupo-centauro.com> wrote in message
news:E1CDBEB0-16D0-4EFD...@microsoft.com...
Por lo que comentas y los enlaces con la respuesta al HT de los nuevos
QuadCore, cuando est� en producci�n y lleve unos cuantos d�as monitorizando
el rendimiento, lo habilitar� de nuevo y continuar� monitorizando a ver si
veo diferencias en las mediciones.
Una �ltima consulta... si lo habilito de nuevo, como para SQL Server habr�
16 procesadores en lugar de 8... �debo tener 16 ficheros de BBDD o
�nicamente 8 que son los procesadores "reales".
Gracias una vez mas por tu gran ayuda.
Diego Fern�ndez
"Carlos Sacristan" <nom...@nomail.com> escribi� en el mensaje de
noticias:uXNs31Ob...@TK2MSFTNGP04.phx.gbl...
Creo que cuando estaba habilitado, Windows ve�a 16 y SQL Server 8
�nicamente, �no?. Yo crear�a tantos archivos como n�cleos viera SQL Server.
--
-----------------------------
"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es f�cil, si ambas est�n congeladas."
Edward V. Berard, ingeniero inform�tico
"Diego Fern�ndez" <dfern...@grupo-centauro.com> wrote in message
news:O4uN61bb...@TK2MSFTNGP04.phx.gbl...
Windows ve�a en el "monitor de recursos" 8 y en el "administrador de tareas"
16. SQL ve�a 16.
Entonces crear� esos 16 archivos.
Un saludo.
Diego Fern�ndez
"Carlos Sacristan" <nom...@nomail.com> escribi� en el mensaje de
noticias:#HZl07bb...@TK2MSFTNGP02.phx.gbl...