Discussion :

[maxtechnologie]

Bonjour

je suis en train de planifier un plan de haute disponibité en enreprise.

et j'aimerais bien avoir votre avis par rapport au hardware necessaire pour une alwayson / Mirroring sans latence ou bien minime au niveau performance IO/NETWORK..

j'ai une base de données de 50GO actuellement sur un Serveur Hp proliant ML 350 G8 six-core/ 72Go de RAM sql standard edition 2008 r2 DisK SAS 10K 2*300GO en RAID 1.

tout va bien c'est rapide sauf qu'en cas de grosse requette qui génére beaucoup de IOPS par seconde ce qui paralyse completement le serveur quelque minute ( 5-10 minute MAX).

j'aimerais bien connaitre une configuration qui pourrait m’épargner ces lenteurs surtout que la mise en mirroir en mode synchrone ( le mode qui m'intérésse justement ) dégrade un peu les performances vu que le serveur principal attent le commit des transactions sur le serveur miroir j'ai lu pas mal de chose sur les forum de microsoft et j'aimerais bien lancer tout ça proprement .

alors svp que pouvez vous me conseillé comme matériel??? ( les disques SSD et un bon switch 1GO enre les deux serveurs pourrait il etre un bon choix ?)

et surtout est ce que le raid 1 est un allié de choix sur un serveur qui fait du mirroring ou pas? ( a ma connaisse le raid il est fort en lecteur rapide , mais en lecture il est trés lent )

je vous remercie d'avance pour vos réponse .

Cordialement.

[SQLpro]

Il serait intéressant de savoir quelles sont ces grosses requêtes et pourquoi elles se comportent de la sorte... Parce qu'avec 50 Go de base et 74 de RAM... J'ai du mal à comprendre !

A +

[maxtechnologie]

Ah cette question j'ai fais pas mal de verification j'ai fais un sql profiler pour essayer de trouver ces requettes la sans succes je constate que la file d'attente disque augmente considérablement en lecture et ecriture et la c'est le blackout . j'avais 32 GO des que j'ai augmenté a 72GO ( je l'ai fais que recemment ) je commence moins a sentir ce probléme la , j'ai d'ailleurs vu cette solution sur votre blog disant qu'en augmenté la mémoire sql serveur ira moins chercher les page sur le disque .


j'ai essayer des resquette pour voir qu'est ce qui bouffent les ressources a ce moment X sans succès. ça m'arrive preseque plus maintenant avec les 72GO je sais c'est pas une solution mais c'est ce que j'avais sous la main vu que je suis pas le developpeur de l'erp que nous utilisons.



Cdt

[SQLpro]

Si vous avez de la contention disque, cela peut provenir du sous système disque lui même qui n'est pas à la hauteur !
Comment est composé physiquement votre stockage ?

A +

[maxtechnologie]

notre stockage est comme suit :
SERVEUR HP PROLIANT ML 350 GEN8
COntroleur en RAID 1
2*300GO SAS 10K la base de donnés est sur un disque local E( DATA/LOG) et la base TEMP sur C: , je pense justement a les changer avec de 15K ou bien des disque SSD.

la file d'attente augmente considérablement a plusieurs miliseconde sur la vue perform disque de windows et les client sont bloqué en attente la fin de cette requette

je vous remercie pour votre réaction.

[SQLpro]

Quel est la carte controleur ?

[maxtechnologie]

c est une Smart array P420i controller.

[SQLpro]

Questions :
1) comment E et C ont-ils été taillés ? Sont-ils alignés sur les disques physiques du RAID ?
2) que donne la requête suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
SELECT DB_NAME(mf.database_id) AS db_name, type_desc, 
       name, LEFT(physical_name, 3) AS unit, 
       size * 8 AS size_KB, growth, is_percent_growth, 
       volume_mount_point, file_system_type, total_bytes, available_bytes, 
       is_compressed
FROM   sys.master_files AS mf
       CROSS APPLY sys.dm_os_volume_stats(mf.database_id, mf.file_id);

A +

[maxtechnologie]

concernant la code transact que vous m'avez donner ça fonctionne pas il parait qu'il reconnait pas la vue sur mon 2008 sql server

Msg 208, Level 16, State 1, Line 1
Nom d'objet 'sys.dm_os_volume_stats' non valide.


j'ai utilisé exec sp_spaceused et d'autre procédure pour vous donner un peu une idée sur la taille de la base,

2 concernant les deux partitions ( c et d) ils sont toujours les deux sur le même disque DUR de 300GO ce dernier et en mirroring sur un autre disque de 300GO ( j'ai 2 HDD 300GO en mirroring)


database_name database_size unallocated space
BASE_PROD1 74354.75 MB 16091.34 MB

reserved data index_size unused
52752224 KB 42597408 KB 10108952 KB 45864 KB

------------------------------------------------------------------------

name Total disk space
BASEPROD1 74354 MB
master 5 MB
model 3 MB
msdb 84 MB
ReportServer 10 MB
ReportServerTempDB 3 MB
BASEPROD2 2167 MB
tempdb 8 MB

------------------------------------------------------------------------

file_id name type_desc physical_name size max_size
1 MODELE_MODE_data ROWS d:\PGI01\DBASEPROD1\DBBASEPROD1.mdf 8653720 -1
2 MODELE_MODE_log LOG d:\PGI01\Dkrishna\DBBASEPROD1.ldf 863688 -1


file_id name type_desc physical_name size max_size
1 tempdev ROWS C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\tempdb.mdf 263168 -1
2 templog LOG C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\templog.ldf 1544 -1


Merci

[SQLpro]

Dans votre premier message vous dites que vous êtes sur "sql standard edition 2008 r2", maintenant vous me dites que vous êtes sur du 2008, faudrais savoir !

Soyez clair net et précis, cela évitera de faire perdre du temps à tous, vous compris !

Commencez par savoir ce avec quoi vous travaillez en laçant la requête

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT @@VERSION

A +

[maxtechnologie]

je pense que oui je suis sur 2008 R2

voici le résultat de la requête

(No column name)
Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64)
Apr 2 2010 15:48:46
Copyright (c) Microsoft Corporation
Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7600: )

[SQLpro]

Donc, vous êtes sur SQL Server 2008 R2 Standard Edition
mais ce qu'il y a de grave c'est : (RTM) - 10.50.1600.1
Cela veut dire que vous n'avez passé aucun patch et donc vous êtes sujet aux pires attaques.
Commencez pas passer le SP 3 et vous verrez que la requête donnée marche !
Vous devriez être en 10.50.6000.34 ou 10.53.6000.34...

Il y a quand même un minimum de chose à faire pour administrer un serveur SQL !

A +

[maxtechnologie]

Bonjour

je m'excuse un peu du retard je devais faire cette mise a jour a minuit , pas facile de faire ça en production , en fait quand je vois que tout marche bien j’évite les mise a jour des fois ça creer plus de probleme. en tout cas voici le resultat de la commande.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
 
db_name	type_desc	name	unit	size_KB	growth	is_percent_growth	volume_mount_point	file_system_type	total_bytes	available_bytes	is_compressed
master	ROWS	master	C:\	4096	10	1	C:\	NTFS	127015059456	65352445952	0
master	LOG	mastlog	C:\	1280	10	1	C:\	NTFS	127015059456	65352445952	0
tempdb	ROWS	tempdev	C:\	8192	10	1	C:\	NTFS	127015059456	65352445952	0
tempdb	LOG	templog	C:\	512	10	1	C:\	NTFS	127015059456	65352445952	0
model	ROWS	modeldev	C:\	2304	128	0	C:\	NTFS	127015059456	65352445952	0
model	LOG	modellog	C:\	768	10	1	C:\	NTFS	127015059456	65352445952	0
msdb	ROWS	MSDBData	C:\	84928	10	1	C:\	NTFS	127015059456	65352445952	0
msdb	LOG	MSDBLog	C:\	9216	10	1	C:\	NTFS	127015059456	65352445952	0
ReportServer	ROWS	ReportServer	C:\	4352	128	0	C:\	NTFS	127015059456	65352445952	0
ReportServer	LOG	ReportServer_log	C:\	6400	10	1	C:\	NTFS	127015059456	65352445952	0
ReportServerTempDB	ROWS	ReportServerTempDB	C:\	2304	128	0	C:\	NTFS	127015059456	65352445952	0
ReportServerTempDB	LOG	ReportServerTempDB_log	C:\	832	10	1	C:\	NTFS	127015059456	65352445952	0
BASEPROD1	ROWS	MODELE_MODE_data	d:\	69229760	15	1	d:\	NTFS	172843069440	37315407872	0
BASEPROD1	LOG	MODELE_MODE_log	d:\	6909504	15	1	d:\	NTFS	172843069440	37315407872	0
BASEPROD2	ROWS	MODELE_MODE_data	d:\	2117376	10	1	d:\	NTFS	172843069440	37315407872	0
BASEPROD2	LOG	MODELE_MODE_log	d:\	102144	10	1	d:\	NTFS	172843069440	37315407872	0

Merciiii

[SQLpro]

Pour la base BASEPROD1, vos fichiers sont en croissance automatique avec un pas en pourcentage de 15%. Pour le JT cela fait des incréments de 8 Go !, pour les données, cela fait un incrément de 80 Go... !!!

À moins que vous ne soyez sur un super SSD, ces opérations vont prendre du temps... au détriment des transactions.

Commencez par dimensionner vos fichiers correctement en allouant entre 20 et 30% de place en plus sur chaque fichiers. Modifier la méthode de pourcentage en taille fixe à 250 Mo.

A +

[maxtechnologie]

je viens de modifié le pourcentage en taille fix a 250mo, j'aimerais bien connaitre comment vous avez calculer ça si c'est possible de me donner un lien vers une doc .

pour ma base prod1 j'ai beaucoup d'espace inoccupé en mdf du rebuild de tout mes index et je veux pas faire un shrink pour ne pas causé une défragmentation des index cela risquerai de rendre mes requete plus lente selon une doc que j'ai lu .
puis je connaitre connaitre la requete qui demande beaucoup de ressource I/O et qui bloque mon serveur pendant quelque minute? et eventuellement regler ce probléme avant de prévoir de passer en always on ou bien mise en mirroir

Merci SQLPRO.

[SQLpro]

pour ma base prod1 j'ai beaucoup d'espace inoccupé en mdf du rebuild de tout mes index et je veux pas faire un shrink pour ne pas causé une défragmentation des index cela risquerai de rendre mes requete plus lente selon une doc que j'ai lu .

Dans ce cas inutile en effet d'augmenter les enveloppes de fichier. Mesurez cependant bien la chose avec :
https://blog.developpez.com/sqlpro/p...e-de-vos-bases

puis je connaitre connaitre la requete qui demande beaucoup de ressource I/O et qui bloque mon serveur pendant quelque minute? et eventuellement regler ce probléme avant de prévoir de passer en always on ou bien mise en mirroir

Merci SQLPRO.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
SELECT TOP(10) * 
FROM sys.dm_exec_query_stats AS qs WITH (NOLOCK)
     CROSS APPLY sys.dm_exec_sql_text(sql_handle)
     CROSS APPLY sys.dm_exec_query_plan(plan_handle)
WHERE qs.total_physical_reads > 0
ORDER BY qs.total_physical_reads DESC, qs.total_logical_reads DESC 
OPTION (RECOMPILE);

A +

[maxtechnologie]

je viens de tester la procédure sp__METRIQUE_STOCKAGE et ça m'a fait vraiment peur j'ai tellement d'espace inoccupé j'ai un fichier journal de 6748 et j'utilise que 31 un fichier de data de 67607 mo et j'utilise que 51306 mo les fichier data je comprend cette augmentation parcque le RBUILD Crée de nouveau index et supprime normalement les anciens mais ne rend pas l'espace supprimé au systeme mais les fichier log pourquoi leur taille reste comme ça ? en sachant que je suis en mode SIMPLE le checkpoint devrait enregistrer tout en disque normalement? . j'aimerais bien recupérer cette espace mais je me dis aussi si je le fais en shrink je vais fragmenter tout mes index et si je lance un rebuild a nouveau ma base va grossir a nouveau donc je suis un peu comme une souris en cage a ce niveau.

la fragmentation du fichier data j'en ai peur mais le fichier log puis-je en faire un shrink et recupérer l'espace je suis qu'en mode simple pour l'instant.

j'ai vu la liste des top10 des requête coûtante en IO read physique et logique , ça m'aide vraiment pas a determiné qu'est ce qui bloqué mon serveur avant l'augmentationde la RAM. mais je me rappelle bien que je voyais le longueur de file d'attente du disque monter en fléche a 100% et disque de 100Ko/s a 1Gbps .


Merci SQLPRO.

[SQLpro]

Si vous avez autant de libre, il me semble intéressant de faire du SHRINKFILE.

Néanmoins, il est important de savoir que travail est fait dans le plan de maintenance, parce qu'il peut sans doute être optimisé...

À quelle fréquence a t-il lieu ?

Auriez vous le code de ce processus de maintenance ?

A +

[maxtechnologie]

en fait j'ai totalement désactiver tout ce qui as une relation au shrink (en l'occurence ce qui cause tout se vide dans le fichier data et log ) des que j'ai lu les best practice que c'etais le demon incarné .

pour les plans de maintenance j'ai une verification d'intégrité de toutes mes bases de maniére quotidienne a minuit ainsi qu'un' sauvegarde de toutes mes bases en full

un rebuild de tout mes index une fois par 2 semaine , ainsi que les mises a jour de statistiques.

si y'a un code qui peut optimisé mes bases ça serait encore mieux, je sens preseque plus les lenteurs des requette avec l'ajout de mémoire a 72 Go , je pense c'est du au fait que la base tient toute entiére ans la mémoire ce qui réduit gravement les I/O sur disque dur ça m'arrange pour l'instant , mais pour la mise en miroir est ce que ça génére des transactions enorme en mode haute securité ? j'ai lu beaucoup de chose est avant de me lancer j'ai besoin de savoir est ce que mon Sub System Disk va suivre ou pas .! j'ai vu que le serveur Principal envoyer des requete au secondaire et attendait une confirmation du commit cette attente peut générer des lenteurs .... !!


Merciii

[SQLpro]

un rebuild de tout mes index une fois par 2 semaine , ainsi que les mises a jour de statistiques.

Il faudrait faire non pas un rebuild de tous les index mais une défragmentation raisonnée des index suivi d'une mises à jours des stats obsolètes.

Et cela TOUTES LES nuits.

Vos bases sont-elles en AUTO_UPDATE_STATS ? AUTO_UPDATE_STATS_ASYNC ? AUTO_CREATE_STATS ?

A +

PS je peut vous donner un bout de code pour faire la maintenance des index et stats sur toutes les bases...