He estado leyendo un interesante 'whitepaper' sobre como diseñar el despliegue físico de las bases de datos en SQL Server 2005. A parte de unos buenos indices, un buen despliegue físico es vital para asegurar el correcto rendimiento y la escalabilidad de nuestra instalación de SQL Server y por lo tanto de nuestra aplicación/es.
En este 'whitepaper' se cubren aspectos relativos al diseño de los archivos de almacenamiento de nuestra base de datos, consideraciones sobre el hardware del servidor de datos (discos, interfaces, buses, niveles RAID etc…) y revisas diferentes patrones de carga a los que puede estar sometido nuestro servidor y los requisitos de I/O de diferentes tamaños de aplicación.
El documento recomienda una serie de pasos a dar a la hora de abordar el diseño físico de la base de datos y nos enseña como darlos:
1. Caraterizar la carga de Entrada/Salida de la aplicación
2. Determinar los requisitos de confiabilidad y rendimiento del sistema de base de datos
3. Determinar los requisitos de hardware necesarios para soportar las deciones hechas en los pasos 1 y 2
4. Configurar SQL Sever 2005 para aprovechar los cambios hecho en el paso 3
5. Hacer seguimiento del redimiento en respuesta a los cambio en la carga
Tambien da una serie de recomendaciones, que traduzco aquí, si quereís saber la justificación teneís que leer el documento:
• Siempre utilizar 'Page Checksum' para auditar la integridad de los datos.
• Considerar la utilización de compresión para grupos de archivos de solo de solo lectura para una mayor eficiencia en el almacenamiento.
• Utilizar NTFS por seguridad y para disponer de algunas caracteristicas avanzadas de SQL Server 2005.
• Usar 'instant file initialization' para optimizar el rendimiento.
• Utilizar Windows Network Service Account por seguridad.
• Utilizar crecimento manual de archivos de la base de datos.
• Usar particionado de datos (solo disponible en Enterprise Edition) para una mayor flexibilidad
• Alinear el almacenamiento de índices con sus tablas para un mantenimiento más facil y rápido.
• Alinear el alamacenamiento de las tablas comumente utilizadas juntas en 'joins' para obtener mejor rendimiento y mejorar el mantenimiento.
• Elejir el nivel de RAID con cuidado. Para un rendimiento excelente y alta confiabilidad tanto en patrones tanto de lectura como en escritura elija RAID10, para patrones de solo lectura elija RAID5.
• Para lograr paralelismo en Entrada/Salida optimizado utilize un tamaño de banda de 64Kb o 256Kb.
• Para mejorar la escalabilidad a futuro y facilitar el mantenimiento, utilize puntos de montaje de volumenes.
• Para incrementar la confiabilidad en el ancho de banda de bus, utilice software de 'multipathing'.
• Para pequeños servidores con menos de tres dicos PCI puede ser suficiente, sin embargo PCI-X está recomendado y puede servir un mayor rango de cargas de trabajo.
• Utilizar discos enchufados directamente es el enfoque recomendado para servidores pequeños a medianos.
• Se recomienda utilzar SAN para grandes servidores.
• Los sistemás NAS no se recomiendan, mejor usar iSCSI en su lugar.
• Para mejorar la capacidad de recuperación, utilize SCSI en lugar de SATA o IDE.
• Para grandes cargas, utilize SCSI o SATA con soporte TCQ.
• Almacenar el log de trasacciones separado de los archivos de datos. No en una banda en el mismo disco que los archivos de datos.
• Para grandes demandas de ancho de banda en el bus de Entrada/Salida, utilizar un bus diferente para los archivos del log de transacciones.
• El número de archivos de datos en un único grupo de archivos debe ser igual al número de CPUs.
muy interesante,…
saludos..
Percy Reyes.
QUIERO HACER LA CONEXION DE SQL A C#.NET ME PODRIA AYUDAR COMO HACERLA.. GRACIAS…
Me ha parecido muy interesante, sobre todo por que estaba buscando documentame para meter un cajon iSCSI con una SAN GigaBit y montar en ella una base de datos SQL Server y he podkido comprobar que haciendolo bien no tendre problemas de rendimiento
Muy interesante el articulo, pero ahora tengo una duda con respecto a los archivos. No podrá pasar lo mismo que pasa con PST de outlook, es decir a una tamaño y truena? ¿Estos archivos tienen un limite?
En principio los ficheros de SQL Server no tienen por que tener tamaño maximo (yo los he visto de 16 GB), pero lo que esta claro es que no es lo mejor ya que los rendimientos pueden bajar muchisimo en estos casos.
para el que quiere hacer la conexion C# – SQL
primero añader el namespace system.data.sqlclient
despues puedes crear un objeto sqlconnection donde le pasas la cadena de conexion en el constructor.
despues creas un objeto sqlcommand, en el constructor le pasas la sentencia y el segundo parametro es el objeto de la conexion.
EL sqlcommand tiene 2 metodos importantes>
ExecuteNonReader()->ejecuta la sentencia pero no devuelve nada, bueno para consultas update, delete, etc
ExecuteReader()->devuelve un objeto sqldatareader con las tuplas devueltas por la consulta que lo puedes recorrer con un ciclo while con el metodo que tiene dentro Read()
while(objdatareader.Read())
{
….
}
Muy bueno el articulo, pero tengo una consulta…
Es posible ver la arquitectura o el diseño logico de la base de datos en Sql Server 2000, me gustaria saber cuanto puede influir agregar un campo nuevo a una tabla de la base de datos, este campo me va a permitir clasificar los parametros que tengo en ella por la forma de operar o por modulo.
si me pueden ayudar en esa inquetud, se lo agradeceria….
atentas a sus comentarios….
Caro