none
Rendimiento 2008 R2 RRS feed

  • Pregunta

  • Estamos trabajando en una simulación con SQL, la cuestión es: desde el punto de vista de rendimiento, que es mejor trabajar con 3 DB de 2Gb cada una o una sola DB de 6Gb. Cómo trabaja mejor SQL 2008 R2?

    Hay alguien que tiene experiencia en esto?.

    Muchas gracias.

    martes, 14 de junio de 2011 16:05

Respuestas

  • Los factores que afectan al rendimiento están en :

    1.- Memoria, es un espacio compartido para todas las bases de datos, por lo que será irrelevante.

    2.- Disco, Estarán en ficheros distintos, y si estos están en discos distintos pueden beneficiarse del paralelismo en las lecturas, pero de igual forma lo harán si creas varios files en varios filegroups. (irellevante por tanto)

    3.- Red, A todas luces irrelevante.

    4.- Seguridad, Al tener varias BBDD's tendrás una ligera sobrecarga (insignificante) porque cuando quieras hacer consultas cruzadas entre bbdd hay que comprobar que l usuario que está conectado tiene permisos y cuales en la otra BBDD.

    5.- Dependiendo del diseño , es posible que en un futuro pudieras beneficiarte de tenerla separadas, para saí poder tenerlas en hardware distinto.

    Se me olvidan cosas, seguro, porque estas consideraciones hay que pensarlas más, pero, de momento puedes ir haciendote a una idea.


    Comparte lo que sepas, aprende lo que no sepas (FGG) http://www.portalsql.com
    martes, 14 de junio de 2011 18:30
    Moderador

Todas las respuestas

  • Pues, sinceramente, ni idea. Nunca me he planteado hacer una prueba a ver cual de esas dos configuraciones de memoria pudiera rendir más, pero apostaría a que habría poca o ninguna diferencia y, en cualquier caso, invertiría mi tiempo en hacer otro tipo de pruebas o en un análisis de otros aspectos que sí que tienen un impacto más grande en el rendimiento de una instancia de SQL Server (empezando por cómo se diseñan las bases de datos)

    martes, 14 de junio de 2011 16:22
  • Los factores que afectan al rendimiento están en :

    1.- Memoria, es un espacio compartido para todas las bases de datos, por lo que será irrelevante.

    2.- Disco, Estarán en ficheros distintos, y si estos están en discos distintos pueden beneficiarse del paralelismo en las lecturas, pero de igual forma lo harán si creas varios files en varios filegroups. (irellevante por tanto)

    3.- Red, A todas luces irrelevante.

    4.- Seguridad, Al tener varias BBDD's tendrás una ligera sobrecarga (insignificante) porque cuando quieras hacer consultas cruzadas entre bbdd hay que comprobar que l usuario que está conectado tiene permisos y cuales en la otra BBDD.

    5.- Dependiendo del diseño , es posible que en un futuro pudieras beneficiarte de tenerla separadas, para saí poder tenerlas en hardware distinto.

    Se me olvidan cosas, seguro, porque estas consideraciones hay que pensarlas más, pero, de momento puedes ir haciendote a una idea.


    Comparte lo que sepas, aprende lo que no sepas (FGG) http://www.portalsql.com
    martes, 14 de junio de 2011 18:30
    Moderador
  • SQL Server 2008 R2 es un administrador de bases de datos relacionales, lo que, y perdón por lo obvio, hace que esté preparado para trabajar con múltiples bases de datos. Ahora bien, la respuesta a tu pregunta depende de múltiples cosas, como si son bases de datos transaccionales o informacionales, o si alguna de ellas interactua con la otra o si simplemente hay que afinar algunos tiempos de procesamiento como lectura o inserciones o actualizaciones.

    Finalmente, los temas de performance o de rendimiento, están más relacionados con percepciones y momentos en el tiempo sobre el comportamiento de una aplicación particular. Así que mi recomendación es que establezcas una "línea de base" sobre tus dos escenarios y luego apliques ciertas prácticas recomendadas, como las que están en http://technet.microsoft.com/en-us/sqlserver/bb671430.aspx para ver si las líneas de base mejoran o empeoran. Ahí tendrás tu mismo tu respuesta.

    Saludos,

     

    Guillermo


    Guillermo Taylor F. IT Pro & Xbox gamer
    martes, 14 de junio de 2011 19:02
  • Guillermo estoy de acuerdo contigo en que hacer una linea base es importantisimo, como también lo es seguir las buenas practicas de diseño.  Hace hice ese trabajo en sistemas en producción muy estresados. Llegué a cambiar de lugar una base de datos y cambié tablas por vistas (para evitar una replicación).  Es decir, cuando le he dicho a CartoHiper-V los condicionantes, simplemente estoy aportando mi experiencia con esa linea base. 

    Sin embargo, no estoy totalmente de acuerdo en que el rendimiento solo sea cuestión de percepción.  El número de páginas que lee una consulta es un valor absoluto.

    Con este script

    select 1 id ,CAST('hola' as CHAR(4000)) texto
    
    into tablademo
    
    from sys.dm_exec_sessions cross join sys.dm_exec_sessions s1
    
     cross join sys.dm_exec_sessions s2
    
    go
    
    set statistics io on
    
    go
    
    select * from tablademo 
    
    
    
    


    el resultado en mi máquina es  

    (27000 row(s) affected)

    Table 'tablademo'. Scan count 1, logical reads 13500, physical reads 0, read-ahead reads 1347, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

    Curiosamente identico, nada subjetivo.

    En resumen, el rendimiento es algo totalmente objetivo. ,mi consulta necesita 13500 páginas, en ambos casos y sin ninguna subjetividad. La sensación de usuario, si es subjetiva y para volver a sensaciones subjetivas de "buen comportamiento" se trazan lineas base, en las que curiosamente se mide, fundamentlamente los parámetros que yo comentaba en mi mensaje anterior (junto con algun contador adicional relacionado con numero de conexiones/usuarios y algun comportamiento de caché).

     

     

    Si luego ejecuto

    go
    
    dbcc dropcleanbuffers()
    
    dbcc freeproccache()
    
    go
    
    use master
    
    go
    
    select * from demo.dbo.tablademo
    
    

    el resultado es

    (27000 row(s) affected) Table 'tablademo'. Scan count 1, logical reads 13500, physical reads 0, read-ahead reads 1347, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Curiosamente el mismo. Por esto, y por lo expuesto te digo que el rendimiento no es algo subjetivo, en tanto que es algo medible y comprobable. Lo subjetivo es la sensación de usuario , que es para lo que se crean las lineas base, sin embargo creo que en este hilo no se pregunta por sensación de usuario, sino por diferencias entre una alternativa y la otra. Espero que se entienda mi argumentación. Saludos Cordiales
    Comparte lo que sepas, aprende lo que no sepas (FGG) http://www.portalsql.com

     

    (27000 row(s) affected)

    Table 'tablademo'. Scan count 1, logical reads 13500, physical reads 0, read-ahead reads 1347, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

     

    martes, 14 de junio de 2011 21:30
    Moderador
  • Buenos consejos te están dando. Solo me gustaría añadirte, para que una de tus valoraciones en el momento de decidir si tendras una sola base de datos, o la dividiras en 4 bases de datos diferentes: Intenta ver cuanta relación tendrán entre si los datos de las distintas bases de datos. Piensa que las claves foraneas (limitación referencial entre dos tablas), no pueden abarcar/darse entre dos tablas de dos bases de datos diferentes. Para sustituir esta funcionalidad, podrás utilizar disparadores, que son más lentos, y darán peores rendimientos, atendiendo a tu pregunta.
     Norman M. Pardell 

    ||Microsoft Certified IT Professional|| Database Administrator. Database Developer. SQL Server 2008



    martes, 14 de junio de 2011 23:33
  • Muchas gracias por vuestros comentarios.

    Voy a analizar primero todas mis tablas y vistas y a evaluar que es lo mejor, en una sola BD o en tres distintas.

    Ya os mantendré informados sobre los resultados.

     

    miércoles, 15 de junio de 2011 7:41
  • Miguel, entiendo el argumento y concuerdo contigo. Tal vez no supe expresarme bien en cuanto a que el desempeño en algún momento puede arrojar buenos números, como muy bien lo demuestras, pero de pronto, y de acuerdo con el comportamiento de la aplicación, tal vez el desempeño no sea tan bueno a futuro y haya que hacer algo adicional. Es claro que el rendimiento no es algo subjetivo pero también es claro que lo que se hizo en un momento y con una línea base de pronto hay que revisarlo en el futuro. Es algo que por experiencia quise compartir...

    Saludos,

     

     


    Guillermo Taylor F. IT Pro & Xbox gamer
    miércoles, 15 de junio de 2011 18:16