Une des difficultées dans la gestion du base de données MSSQL est de controller l'espace de stockage et vérifier si une pénurie d'espace disque ou une limite dans la taille de fichier journal ou de données ne va pas entrainer le blocage des transactions.
Les difficultés résident dans plusieurs aspects :
Comment être alerté avant le blocage avec tous ces paramètres en jeux ?
Je vous propose d'étudier, pour répondre à cette question, les strategies de la base de données SQL Server. Nouveautés de SQL serveur 2008, ces strategies sont très puissantes pour controler des aspects des bases de données et des instances.
Les strategies de base de données s'appuie sur plusieurs objets :
La version 11 de SQL server (aka Denali) dispose d'un assistant de création pour les "extended events". Ces évènements permettent de suivre et de tracer des points complexes sur le serveur de base de données.
Voyons comment procéder pour créer et tracer ces évènements avec le nouvel assistant intégré à SQL Server Denali.
Le lancement du "session wizard" s'effectue à partir de la section de management dans SSMS :
|
Lire la suite : SQL Server 2012 (v11 Denali) : Extended Events et Session Wizard
Esc cancel/go back to normal mode Annuler / basculer en mode normal
:q quit Quitter
:wq! write and quit Sauvegarder et quitter
G go to eof Aller à la fin du fichier
1G go to line 1 Aller à la ligne 1
50G go to line 50 Aller à la ligne 50
- go to begin of prev line Aller au bédut de la ligne précédente
+ go to begin of next line Aller au début de la ligne suivante
$ go to end of current line Aller à la fin de la ligne courante
^ go to begin of current line Aller au début de la ligne courante
/xxx find xxx Trouver le mot xxx
z. refresh Rafraichir
dd delete line Supprimer la ligne
D delete rest of line Supprimer la ligne à partir du curseur
x delete current char Supprimer le caractère courrant
a insert after current char Passer en mode insertion après le curseur
i insert ahead of current char Passer en mode insertion avant le curseur
o insert after current line Passer en mode insertion après la ligne courante
cw change word under cursor Modifier le mot sous le curseur
J join lines Joindre le lignes
yy copy line to clipboard Copier la ligne
p paste line above cursor Coller les données après le curseur
Une nouveauté sur la 11g est l'apparition de l'ACS pour Adaptive Cursor Sharing. Cette nouvelle fonctionnalité permet de pallier aux problèmes de bind rencontrer sur les requêtes SQL utilisant des paramètres.
Rappel : Il est possible d'utiliser des variables ou des litéraux dans les requêtes. Les litéraux sont des valeurs en dur dans la requête (type='manager' par exemple). Chaque requête génère alors un plan potentiellement différent pour chaque valeur du litéral. Plus le nombre requête avec des valeurs différentes est important plus la consommation mémoire dans le sharepool est importante.
De plus le calcul d'un nouveau plan (hard parse) est très couteux en CPU. Pour pallier cette problématique, l'utilisation des variables dans les requêtes permet de limiter ce problème car un seul plan est déterminé par l'optimiseur et les valeurs. Les requêtes suivantes vont reprendre le plan calculé (soft parse). Le problème c'est que le premier plan calculer n'est pas forcement le plus optimal suivant les valeurs utilisées pour chaque variable.
Un paramètre d'initialisation : CURSOR_SHARING pouvait prendre plusieurs valeurs et le comportement de l'optimiseur est différent suivant qu'il y ai ou non des histogrammes sur les colonnes :
Prenons un exemple de requête :
SELECT * FROM emp WHERE TYPE='Manager'
CURSOR_SHARING | Consommation Mémoire | Performance de la requête | Comportement de l'optimiseur |
EXACT | La plus forte (chaque requête a son propre curseur) | la meilleure (chaque requête a son propre plan, optimal pour les litéraux utilisés) |
l'optimiseur vous la requête tel quelle (qu'il y ai ou non des histogrammes) |
FORCE | La meilleure (la plus réduite possible) | potentiellement le pire, l'optimiseur forcant l'utilisation de variable et ne calculant alors qu'un seul plan. | l'optimiseur force le remplacement du ou des litéraux par des variables (qu'il y ai ou non des histogrammes) --> where type=:a |
SIMILAR sans Histo | La meilleure (la plus réduite possible) | potentiellement le pire, l'optimiseur forcant l'utilisation de variable et ne calculant alors qu'un seul plan. | Le fait qu'il n'y ai pas d'histogramme indique pour l'optimiseur que la colonne est répartie de manière équitable (not skew = pas de biais), il va donc utiliser le remplacement de la ou les variables --> where type=:a |
SIMILAR avec Histo | Pas autant que le mode EXACT mais assez proche tout de même | la meilleure (chaque requête a son propre plan, optimal pour les litéraux utilisés) | Pour l'optimiseur le fait qu'il y ai un histogramme lui indique que la colonne contient des données non uniformement distribuées (les valeurs peuvent influencer le plan). Dans ce cas, il n'opére pas de modification de la requête. --> where type='Manager' |
Avec l'ACS, le comportement de l'optimiseur est un peut plus complexe :
Lire la suite : Oracle 11g : Adaptive Cursor Sharing
Articles traitant de l'intégration de données
Des tutoriaux et cours gratuits sur Oracle
Tutoriaux sur Unix et les shells scripts