none
KB de best practices RRS feed

  • Pregunta

  • Hola team, quisiera saber si alguien me puede colaborar con un link de un Kb microsoft dónde esté especificado por que debemos tener un disco para data y otro para log y por que estos discos no pueden compartir conn las unidades donde se depositan backups.

    Gracias

    jueves, 22 de marzo de 2018 22:28

Respuestas

  • https://blogs.technet.microsoft.com/sql_server_isv/2010/11/11/sql-server-drive-configurations/

    En este link te lo explican, pero vamos todo eso no es ni más ni menos que recomendaciones general de sentido común. 

    Los discos de datos se escriben de forma asíncrona a los commit de los queries, esto es, tu haces commit y en los discos de datos llega el dato más tarde, es el log de transacciones el que garantiza que si se perdiera la corriente no se perderían los datos. 

    Por el contrario en el fichero de log de transacciones  se escribe de forma síncrona, es decir, cuando haces un commit, en tanto en cuanto no esté escrito en disco no te devulve el control, incluso si no has hecho commit, cada acción de modificación de datos es escrita en este log de forma síncrona, así pues, cuanto más rápido sea ... mejor. 

    El no compartirlos con las unidades de backup... imagina que tienes 10 backups históricos, es decir el espacio que ocupe 1 multiplicado por 10, en una unidad que es la misma donde están tus datos, y por tanto de disco "caro", parece que también es de sentido común.

    Por cierto, los discos de TempDB también merecen consideración especial, no solo en que discos se pone sino en el número de ficheros que se le generan y esto tiene que ver más con la posibilidad de paralelismo y los hilos que pueden ejecutar.


    Comparte lo que sepas, aprende lo que no sepas (FGG)
    portalSQL
    El rincón del DBA


    viernes, 23 de marzo de 2018 6:53
    Moderador

Todas las respuestas

  • Saludos,

    Esto ya no es tan realista hoy en día por nuevos tipos de soluciones de storage que existen como las NAS, Storage spaces, SAN, etc. 

    En otro casi.

    Sobre tu pregunta porque no debe de estar el backup donde tengas data files... si pierdes el data file y el backup realmente no tendras manera de recuperarte.

    https://technet.microsoft.com/en-us/library/cc966534.aspx?f=255&MSPPError=-2147217396


    Blog: www.sqlservertoolbox.blogspot.com.mx

    viernes, 23 de marzo de 2018 0:33
  • https://blogs.technet.microsoft.com/sql_server_isv/2010/11/11/sql-server-drive-configurations/

    En este link te lo explican, pero vamos todo eso no es ni más ni menos que recomendaciones general de sentido común. 

    Los discos de datos se escriben de forma asíncrona a los commit de los queries, esto es, tu haces commit y en los discos de datos llega el dato más tarde, es el log de transacciones el que garantiza que si se perdiera la corriente no se perderían los datos. 

    Por el contrario en el fichero de log de transacciones  se escribe de forma síncrona, es decir, cuando haces un commit, en tanto en cuanto no esté escrito en disco no te devulve el control, incluso si no has hecho commit, cada acción de modificación de datos es escrita en este log de forma síncrona, así pues, cuanto más rápido sea ... mejor. 

    El no compartirlos con las unidades de backup... imagina que tienes 10 backups históricos, es decir el espacio que ocupe 1 multiplicado por 10, en una unidad que es la misma donde están tus datos, y por tanto de disco "caro", parece que también es de sentido común.

    Por cierto, los discos de TempDB también merecen consideración especial, no solo en que discos se pone sino en el número de ficheros que se le generan y esto tiene que ver más con la posibilidad de paralelismo y los hilos que pueden ejecutar.


    Comparte lo que sepas, aprende lo que no sepas (FGG)
    portalSQL
    El rincón del DBA


    viernes, 23 de marzo de 2018 6:53
    Moderador
  • Saludos.

    Creo que se te paso un poco lo técnico, aunque no creo que deberiamos nosotros de preocuparnos por costo fue bueno tu nota sobre este punto pues storage es caro.


    Blog: www.sqlservertoolbox.blogspot.com.mx

    viernes, 23 de marzo de 2018 17:24
  • Enrique mi comentario de "caro" está entrecomillado porque no me refiero tanto al coste económico, que también, como al hecho de que si tienes 10 backups ocupas 10x el tamaño de 1 y en términos de ocupación eso también es caro. Es normal querer tener los backups por ejemplo de principio y final de mes de los últimos x meses mas todos los del ultimo mes y cosas así. eso son muchos backups. 

    En mis instalaciones, generalmente pido disco IDE para poner esos backups y además la gente de sistemas se los lleva a otros medios incluso mas baratos. Pero insisto, no hablo en términos económicos, o al menos no solamente en esos términos. 


    Comparte lo que sepas, aprende lo que no sepas (FGG)
    portalSQL
    El rincón del DBA

    martes, 27 de marzo de 2018 6:18
    Moderador
  • Saludos Miguel,

    Entiendo tu punto aunque claro no tocamos tema como deduplicacion, compresión etc. Mi punto era mas sobre el hecho de que esto creo que es mas algo que deberia de realizar el arquitecto que diseña y no tanto un DBA (aunque es comprensible que en empresas pequeñas a medianas talvez esto recaiga directamente en el DBA). 

    Creo que hace rato no veo cintas y sere feliz sino las vuelvo a ver. 


    Blog: www.sqlservertoolbox.blogspot.com.mx

    martes, 27 de marzo de 2018 14:04