Discussion :

[Free10]

Bonsoir a tous ,
Je m'occupe d'une base de données sqlserver 2008 je dois l optimiser. J'ai besoin de quelques conseils please.
La base contient que deux groupes de fichiers ( primary et log), les fichiers de données sont stockés dans primary.
J'ai pensé de créer d'autres groupes de fichier afin de séparer les fichier de données et ceux du système.
Questions : Est ce que le déplacement des fichiers de données vers les nouveaux groupes qui seront crées n affectera pas l'accès aux données , ie les requêtes déja écrites retourneront les meme résultats que ceux avant le déplacement des fichiers?
Si c'est faisable , est ce que cela aura un effet sur la performance ? si oui C'est quoi l explication ?
Quels sont d'autres point à voir pour l'optimisation ?

Une autre question concernant le journal de transactions
Il est désactivé en raison de l'esapace important qu il occupe, en revanche sans le journal des transaction il y aura perte de données en cas de crash,
Est ce que il y a une possiblité de l'activer et de définir un seuil à partir du quel il enregistre sur le disque et s'efface ???

et tout autre conseil est le bienvenu
MErci d'avance

[pcaboche]

Bonsoir a tous ,
Je m'occupe d'une base de données sqlserver 2008 je dois l optimiser. J'ai besoin de quelques conseils please.
La base contient que deux groupes de fichiers ( primary et log), les fichiers de données sont stockés dans primary.
J'ai pensé de créer d'autres groupes de fichier afin de séparer les fichier de données et ceux du système.
Questions : Est ce que le déplacement des fichiers de données vers les nouveaux groupes qui seront crées n affectera pas l'accès aux données , ie les requêtes déja écrites retourneront les meme résultats que ceux avant le déplacement des fichiers?
Si c'est faisable , est ce que cela aura un effet sur la performance ? si oui C'est quoi l explication ?

Faire une recherche sur "table and index partitioning".

http://msdn.microsoft.com/en-us/library/ms190787.aspx


Explication rapide :

Il est possible de placer les données d'une même table (logique) sur différents supports (physiques).
C'est possible grâce aux "Filegroups" et aux fonctions de partitionnement.

Par exemple, on peut définir un Filegroup sur un support rapide (ex. des SSD) et un autre sur un support plus lent mais avec plus d'espace de stockage (ex. des disques dur).

Ensuite on définit des fonctions de partitionnement pour que les données accédées souvent se retrouvent dans le Filegroup sur le support rapide (SSD) et les données moins souvent accédées (ex. historique) dans le Filegroup sur le support de plus grande capacité.
On peut aussi définir d'autres stratégies de partitionnement (ex. partitionnement des données par mois)

Donc les requêtes (logiques) restent les mêmes, mais on a une plus grande liberté du support (physique) des données.


Pour une explication plus détaillée faire des recherches.

Une autre question concernant le journal de transactions
Il est désactivé en raison de l'esapace important qu il occupe, en revanche sans le journal des transaction il y aura perte de données en cas de crash,
Est ce que il y a une possiblité de l'activer et de définir un seuil à partir du quel il enregistre sur le disque et s'efface ???

1. définir une stratégie maintenance :
- backups (full, differential, log) de manière régulière
- index reorganize / index rebuild (pour les perfs)

2. passer le Recovery Model à Full (uniquement si les backups planifiés fonctionnent, sinon ça remplit les logs)

Pour plus d'infos, faire une recherche sur :
- les différents Recovery Model (notamment Full et Simple)
- les Transaction Logs
- les types de backup (full, differential, log)
(les 3 sont liés)

[SQLpro]

Je m'occupe d'une base de données sqlserver 2008 je dois l optimiser. J'ai besoin de quelques conseils please.
La base contient que deux groupes de fichiers ( primary et log), les fichiers de données sont stockés dans primary.
J'ai pensé de créer d'autres groupes de fichier afin de séparer les fichier de données et ceux du système.

Créer plusieurs groupes de fichiers et plusieurs fichier vous fera gagner en performance à 2 conditions :
1) que chacun des fichiers soient créés sur un disque physique différent
2) que chaque fichier soit dimensionné de façon suffisante pour ne plus avoir aucune opération de croissance pour les 3 à 5 années de production à venir (capacity planning).

Questions : Est ce que le déplacement des fichiers de données vers les nouveaux groupes qui seront crées n affectera pas l'accès aux données , ie les requêtes déja écrites retourneront les meme résultats que ceux avant le déplacement des fichiers?

1) le déplacement du stockage ne modifie pas les données !
2) lors de la migration des objets (index) les tables et index sont inaccessible, le temps de bouger.
Pour savoir comment migrer des objets d'un "storage" à l'autre, lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p5...space_de_stock

Si c'est faisable , est ce que cela aura un effet sur la performance ? si oui C'est quoi l explication ?

Si les espaces de stockage sont mécaniquement indépendant, les opérations de lecture et d'écriture physique seront parallélisées.
Si l'espace de stockage est suffisamment grand, il n'y a plus d'opération de croissance qui ralentit considérablement les performances. Faites le test que je donne ici pour vous en convaincre : http://blog.developpez.com/sqlpro/p5..._fichiers_et_t

Quels sont d'autres point à voir pour l'optimisation ?

Comme déjà dit, le recalculs des statistiques et la défragmentation des index. À faire en principe 1 fois par 24h.
Plus important encore :
1) bien dimensionner le fichier du Journal des transactions (environ 20 à 30% du volume global de la base à terme) et le placer sur un disque physique différent de celui des données.
2) dimensionner correctement le stockage de la base tempdb, à raison de n fichiers de données dans PRIMARY, n étant le nombre de core ou de CPU, de façon à n'avoir jamais aucune opération de croissance
3) régler globalement le parallélisme en fonction du nombre de fichier de stockage des différentes bases
4) fixer les valeurs min et max de la RAM de SQL Server

Une autre question concernant le journal de transactions
Il est désactivé en raison de l'esapace important qu il occupe, en revanche sans le journal des transaction il y aura perte de données en cas de crash,

Il n'est pas possible de désactiver la journalisation des transactions. Les transactions sont toujours enregistrées dans le Journal des transaction, mais on peut limiter les entrées en choisissant tel ou tel mode de journalisation (FULL, BULK LOGGED, SIMPLE)

Est ce que il y a une possibilité de l'activer et de définir un seuil à partir du quel il enregistre sur le disque et s'efface ???

En mode simple il se recycle tout seul, mais en cas d'erreur ou vous ne pourrez pas revenir à un point dans le temps pour récupérer les données écrasées ou la fin de vie de la base.
En mode FULL vous devez élaborer une stratégie de purge du journal en effectuant des sauvegardes du journal de transaction (BACKUP LOG et non BACKUP DATABASE).

et tout autre conseil est le bienvenu
MErci d'avance

A +