Partición en Windows para SQL Server, ¿MBR o GPT?

Zuljin

Zuljin

Fundador
Miembro del Equipo
Fundador
ADMIN
Se incorporó
15 Enero 2004
Mensajes
11.880
No me manejo mucho en Windows, así que ahí va la pregunta:

Estoy montando una plataforma de pruebas para estudiar ciertos comportamientos en base de datos. El entorno es:

Vmware 6.0
Máquina virtual con 60GB de RAM y 8 núcleos virtuales.
Windows Server 2016
SQL Server 2017 Enterprise Edition.
Volúmenes separados para Sistema Operativo, Data y Logs.
Uso: OLPT intenso.
Tamaño de la base de datos: no mayor a los 200GB.

La primera pregunta es qué partición elegir para la data de la base de datos, ¿MBR o GPT?
Estoy leyendo y la diferencia que mencionan es netamente que GPT soporta más de 2 teras, pero para mi prueba necesito rendimiento.

Gracias
 
Sort by date Sort by votes
FranciscoCL

FranciscoCL

-_-
Se incorporó
4 Marzo 2005
Mensajes
7.831
Con GPT y los últimos Windows el equipo me bootea más rápido, es la única ventaja como usuario común que he encontrado. No sé en otros ámbitos.
 
Upvote 0
NIN

NIN

Opteron Fanboy
Se incorporó
5 Septiembre 2005
Mensajes
1.447
Zuljin dijo:
Vale. Terminé usando GPT igual.
Haz clic para expandir...

Ese es el esquema o estilo de particionado del disco duro. Prácticamente no influye una vez que arranca el sistema operativo porque ahí comienza a trabajar el sistema de archivos. Debes seleccionar un sistema de archivos que se ajuste a la necesidad que tengas (XFS, Ext3-4, BtrFS, etc) o ir probando uno a uno. Si vas a trabajar con Windows, creo que el abanico de sistemas de archivos se limitará a ReFS y NTFS

https://docs.microsoft.com/en-us/windows-server/storage/refs/refs-overview

Si pruebas en Linux, BtrFS ofrece buenas caracteristicas

https://mariadb.com/resources/blog/what-best-linux-filesystem-mariadb

Sobre el rendimiento, mas que el FS, lo primero es establecer que arreglo de discos duros ofrece el mejor rendimiento, ya que sería una locura escribir una BD sobre un disco suelto. Luego ver que discos ofrecen mejor rendimiento, que controladora ofrece buen rendimiento, si hay caché de escritura, si es HW-RAID o HBA, si existe la posibilidad de usar SSD como caché de escritura, etc etc. En el fondo establecer via HW una plataforma que provea el mejor rendimiento transaccional.

Desconozco si el Hypervisor juega en contra a la hora de evaluar el rendimiento de un FS. Vmware trabaja sobre su propio sistema de archivos para los almacenes por lo que estarías estableciendo un sistema de archivos sobre otro sistema de archivos (HDD >> VMFS >> (DB FS)).

De momento son las unicas observaciones que se me ocurren.
 
Upvote 0
Zuljin

Zuljin

Fundador
Miembro del Equipo
Fundador
ADMIN
Se incorporó
15 Enero 2004
Mensajes
11.880
NIN dijo:
Ese es el esquema o estilo de particionado del disco duro. Prácticamente no influye una vez que arranca el sistema operativo porque ahí comienza a trabajar el sistema de archivos. Debes seleccionar un sistema de archivos que se ajuste a la necesidad que tengas (XFS, Ext3-4, BtrFS, etc) o ir probando uno a uno. Si vas a trabajar con Windows, creo que el abanico de sistemas de archivos se limitará a ReFS y NTFS

https://docs.microsoft.com/en-us/windows-server/storage/refs/refs-overview

Si pruebas en Linux, BtrFS ofrece buenas caracteristicas

https://mariadb.com/resources/blog/what-best-linux-filesystem-mariadb

Sobre el rendimiento, mas que el FS, lo primero es establecer que arreglo de discos duros ofrece el mejor rendimiento, ya que sería una locura escribir una BD sobre un disco suelto. Luego ver que discos ofrecen mejor rendimiento, que controladora ofrece buen rendimiento, si hay caché de escritura, si es HW-RAID o HBA, si existe la posibilidad de usar SSD como caché de escritura, etc etc. En el fondo establecer via HW una plataforma que provea el mejor rendimiento transaccional.

Desconozco si el Hypervisor juega en contra a la hora de evaluar el rendimiento de un FS. Vmware trabaja sobre su propio sistema de archivos para los almacenes por lo que estarías estableciendo un sistema de archivos sobre otro sistema de archivos (HDD >> VMFS >> (DB FS)).

De momento son las unicas observaciones que se me ocurren.
Haz clic para expandir...

Era Windows y SqlServer no más. Los arreglos están fuera del alcance de la pregunta, ya que el storage maneja dinámicamente las capas de disco y de storage según acceso a disco.


Al final el único tip importante que me encontré era considerar el tamaño del bloque según el tipo de uso de la base de datos: si es OLTP un bloque de 8k. Si es una base de datos tipo Datawarehousing o para reportería dura, irle por un bloque más grande. Y siempre NTFS, ya FAT no entra a jugar.
 
Upvote 0
Zuljin

Zuljin

Fundador
Miembro del Equipo
Fundador
ADMIN
Se incorporó
15 Enero 2004
Mensajes
11.880
NIN dijo:
http://www.hammerdb.com/hammerdb_mssql_oltp_best_practice.pdf

Siempre se enfocan en cpu y memoria pero dan poco enfasis en el almacenamiento. Me imagino que 8k es el termino medio para la lectura/escritura y el desperdicio de espacio.
Haz clic para expandir...
No es por desperdicio de espacio, tiene que ver con la particularidad de una base de datos con comportamientos OLTP: muchas lecturas y escrituras de pequeños bloques al azar.

Enviado desde mi Moto E (4) Plus mediante Tapatalk
 
Upvote 0
You must log in or register to reply here.
Subir