Discussion :

[PortForwadingNoob]

Bonjour,
En gros on est sur une ancienne version DELL avec SQL serveur 2014 et on passe sur du DELL en SQL Serveur 2019.
J’ai 2 serveurs d’applications et 2 serveurs de données (principale et secours) SQL 2019 Express pour les serveurs d’applications et SQL 2019 Standard pour les serveurs de données.
La config pour les serveurs d’applications est :
- Disque 0 MR419i + 2x480Go [System (C:)]
- Disque 1 960Go [Applicatif (E:)]
- Disque 2 960Go [Applicatif (E:)]
- Avec disque 1 et 2 en RAID 1
La config pour les serveurs de données est :
- Disque 0 MR419ip + 480Go [System (C:)]
- Disque 1 1,92To [SQL (E:) SQL_DUMP (V:)]
- Disque 2 1,92To [SQL (E:) SQL_DUMP (V:)]
- Avec disque 1 et 2 en RAID 1
- Disque 3 1,2To [SQL_LDF_FILES (L:)]
- Disque 4 1,2To [SQL_MDF_FILES (M:)]
- Disque 5 1,2To [SQL_LDF_FILES (N:)]
- Disque 6 1,2To [SQL_TEMPDB_FLASH (T:)]
- Disque 7 1,2To [WSUS (W:)]
- Avec disque de 3 à 7 en RAID 5
Je ne suis pas un très grand connaisseur de Microsoft SQL Server. C’est dans mon sujet de stage et j’aimerais savoir à quoi sert le disque 1 et 2 pour les serveurs de données.
Merci d'avance.

[binarygirl]

Apparemment, les logs de transactions vont sur un disque à part, ce qui me semble être une bonne pratique, pour des raisons de performance.
Ce point est d'ailleurs décrit dans la doc mais sans rentrer dans le détail. Si vous tapez certains mots-clé comme: transaction log separate disk vous devriez trouver pas mal d'infos à ce sujet.
Les noms donnent un indice:

• LDF: Log Database File
• MDF: Main Database File

[AaâÂäÄàAaâÂäÄàAaâÂäÄ]

C’est dans mon sujet de stage et j’aimerais savoir à quoi sert le disque 1 et 2 pour les serveurs de données.

Sérieusement, sans aller voir dans les répertoires, je ne vois pas comment on pourrait deviner
SQL_DUMP, ça pourrait potentiellement avoir rapport avec les sauvegardes de bds, mais ça ne serait pas la première fois qu'un nom de disque ne correspondent pas à son utilisation réelle...

[PortForwadingNoob]

Merci

[SQLpro]

Globalement la séparation données d'un côté (tables et index) et logs de l'autre (journal de transactions) n'a d'intérêt que si l'on dispose de deux systèmes de disques PHYSIQUEMENT différents.

En effet en cas de casse des disques de l'un on peut s'appuyer sur l'autre pour reconstituer la base de données.
Si le disque de données est mort et des données perdues, on peut repartir du journal de transactions pour reconstituer les données sans aucune perte. Ceci suppose d'avoir :
des bases de données en mode de journalisation (RECOVERY) compelt (FULL) et des sauvegardes : au moins une complète (la dernière) et transactionnelles (toutes celles depuis la la complète) et de faire une dernière sauvegarde transactionnelle de la fin du journal (c'est possible même si la base est morte - voir cela en cours de DBA...) en mode d'urgence
Si le disque du journal est mort il suffit de faire une sauvegarde des données (complète) en mode d'urgence. Vous allez perdre les quelques instant de vie de la base, c'est à dire quelques unes des dernières transactions qui n'ont pas encore été reportées dans les fichiers de données.

Ceci dit, comme aujourd'hui soit on est en VM soit on est sur un SAN mutualisé cette disposition ancestrale n'a aucun sens et s'avère même parfaitement idiote car elle fait perdre de la capacité de stockage...

Enfin, utilisez des disques organisés en agrégat de type RAID 5 est une imbécilité que je rencontre fréquemment chez les clients qui se croient naïvement en sureté... Mais c'est hélas faux... En effet, vous lirez sur Wikipédia (qui parfois raconte des bêtises, mais là c'est pas trop mal) que le RAID5 peut avoir des effets pervers (destruction irréversible du stockage) en plus de s'avérer le plus lent des systèmes de stockage... En effet son coût est d'environ 2,5 fois plus long en écriture et 2 fois plus long en lecture qu'un disque unique, alors que le RAID 0 est deux fois plus rapide qu'un disque unique en lecture comme en écriture (donc un rapport de 4 à 5 fois plus rapide). Mais comme le RAID 0 n'apporte pas de sécurité il vaut mieux utiliser du RAID 1 : même durée en écriture, mais lecture divisé par deux, par rapport à un disque unique... Et en combinant RAID 0 + 1 on obtient 4 fois plus rapide en lecture et deux fois plus en écriture. Comparé à du RAID 5, le RAID 0+1 (ou RAID 10) est :
4 fois plus rapide en écriture et 10 fois plus rapide en lecture que le RAID 5 avec seulement un disque de plus (soit une augmentation de coût de 33% pour un gain de 4 à 10 fois !), et en beaucoup plus fiable...

Donc, si vous voulez de la performance, il vaut mieux oragnisaer vos bases de données SQL Server comme suit :

La config pour les serveurs de données est :
- Disque 0 MR419ip + 480Go [System (C:)] => l'OS et les exécutables MS SQL Server
- Disque 1 1,92To [SQL (E:) SQL_DUMP (V:)] => la moité des fichiers de données + la moitié des journaux de transaction
- Disque 2 1,92To [SQL (E:) SQL_DUMP (V:)] => l'autre moité des fichiers de données + l'autre moitié des journaux de transaction
- Avec disque 1 et 2 en RAID 1

- Disque 3 1,2To [SQL_LDF_FILES (L:)] => sauvegarde transactionnelles
- Disque 4 1,2To [SQL_MDF_FILES (M:)] => fichier 1 des sauvegardes FULL mutifamille (permet de stocker la sauvegarde sur plusieurs fichiers chacun contenant une partie de la sauvegarde)
- Disque 5 1,2To [SQL_LDF_FILES (N:)]=> fichier 2 des sauvegardes FULL mutifamille (permet de stocker la sauvegarde sur plusieurs fichiers chacun contenant une partie de la sauvegarde)
- Disque 6 1,2To [SQL_TEMPDB_FLASH (T:)] => les fichiers de la base tempdb (base contenant les objets temporaires) à condition qu'il s'agisse bien de flash....
- Disque 7 1,2To [WSUS (W:)] => tout autre chose
- Avec disque de 3 à 7 en RAID 5

Apparemment, les logs de transactions vont sur un disque à part, ce qui me semble être une bonne pratique, pour des raisons de performance.

Et non, ça c'est une vieille connerie qui date de Mathusalem... enfin de la version 2000 ou on en était au disques magnétiques.... À partir du moment ou l'on a des SANs mutualisés ou de la VM, ça ne sert à rien au niveau des performances....

A +

[PortForwadingNoob]

J'aurais une autre question concernant l'architecture des serveurs. Vous pouvez voir l'architecture générale sur l'image ci-desous.
Le but est de mettre les 4 nouveaux serveurs en parallèle avec les anciens serveurs (2 SQL Server 2014 Express et 2 SQL Server 2014)
pour faire le transfert progressif de la partie automate vers les nouveaux serveurs (sans stopper le fonctionnement, pour qu'une fois
les nouveaux serveurs complètement requalifiés, les anciens seront démantelés et utiliser autre part à la place d'un système encore plus vieux).

J'aimerais savoir, pour la mise en parallèle, comment peut on faire pour garantir la continuité de service tout en réalisant les transfert progressif.
Merci.