DBA SQL Server - Pascal MESSAGER (freelance)

Mercredi 2 avril 2008

SQL 2008 : c'est parti

Ca y est j'ai installé sql 2008 ctp de février.

Il a fallu s'y reprendre à plusieurs fois et télécharger en tout près de 3 Go de données (15h de download !), entre les fichiers corrompus (celui de 1,2 go) les services packs indispensables, le framework... D'ailleurs j'ai noté le processus d'installation au fur et à mesure avec copie d'écrans... si ça intéresse quelqu'un.

Premiers tests
Express sur windows xp : management studio 2005 ne reconnait pas un serveur 2008 et refuse de se connecter.
Dev sur windows 2003 : management studio se connecte, toute l'interface est ok, mais refuse d'exécuter la moindre requête (attente infinie). Je bricole donc avec sqlcmd et dissèque le profiler en attendant de comprendre ou réinstaller.

Mais les premières impressions sont bonnes. Je compte approfondir notamment analysis services qui semble plus convivial.

Bon point aussi, dans la doc (encore mal traduite mais c'est une béta), des tutoriels en fonction des différents utilsateurs (dba, développeurs...)

Pleins de webcasts pour s'initier sérieusement à sql 2008 avant de l'installer ici : http://www.microsoft.com/sqlserver/2008/en/us/events-webcasts.aspx Il faut s'inscrire, les vidéos durent de 60 à 90' et c'est excellent pour améliorer son anglais.
Pour les francophones purs http://technet.microsoft.com/fr-fr/bb608272.aspx , des présentations de 20' environ.

(à suivre)

par Pascal MESSAGER
ajouter un commentaire commentaires (0) créer un trackback recommander

Dimanche 24 février 2008

Fiabilité des données, talon d'Achille de l'informatique

Le "Grand Crash Mondial" (copyright PM) sera-t'il dû à un dysfonctionnement informatique ?

Si un trader seul (sic) peut faire sauter une banque et volatiliser 5 millards d'euros, combien de chômeurs pourrait fabriquer un système informatique devenu fou ?

Tout informaticien un peu expérimenté a déjà vu des programmes qui fonctionnent par miracle, à grands coups de réparation de bugs et de verrues. Parfois pour gérer des applications sérieuses, voire "mission critical" comme disent les yankees. Et de prier pour que celles qui pilotent les centrales nucléaires soient, elles, en béton armé consolidé renforcé et que nos frontières arrêtent les bugs. Prions !

Les bases de données ne sont pas exemptes, et comme elles ont détestable propriété de tout enregistrer (bin oui c'est à ça qu'elles servent), on peut leur demander rétroactivement si leurs données sont elles en bon état. Et c'est pas triste. Un peu comme quand on tire le frigo et qu'on y découvre derrière le stylo de grand-père qu'on croyait disparu (le stylo pas grand-père), un vieux ticket de loto jamais vérifié... et les restes de la boite de petits pois renversée l'été dernier !

Quand j'audite une base de données, j'ai ma boite à outils avec des scripts d'analyses du serveur. L'un de ces scripts recherche les trous de date dans toutes les tables. J'ai d'ailleurs fini par l'industrialiser (voir liens en bas à gauche).

Entre les tables obsolètes, les doublons et les trous de dates, je trouve toujours des anomalies. C'est un indice de qualité de l'application.

Ca ne provoque pas forcément un crash, plutôt des manques à gagner. Dans au moins deux missions précédentes, "quelques" (sic) euros ont ainsi été oubliés par une des parties !

Mais il y a des directeurs informatiques qui risquent de se retrouver au chômage le jour où un dysfonctionnement (euphémisme pour plantage) survient.

par Pascal MESSAGER
ajouter un commentaire commentaires (0) créer un trackback recommander

Dimanche 2 septembre 2007

SOS SQL "pin pon pin pon"

Les missions se suivent... et ne se ressemblent pas. Cette année c'est plutôt des missions courtes, avec une dominante expertise express, voire intervention pompier.

J'en ai fait une, l'autre jour dans le plus pur style "Ghostbuster", vous savez les geeks qui débarquent toutes sirènes hurlantes pour chasser les esprits malfaisants !

Appelé en catastrophe un samedi vers 13 heures alors que je m'apprêtais à profiter paresseusement du week-end, par un client affolé. Les performances du serveur se sont effondrées et les abonnés (un site web très spécialisé) n'accédent plus à leurs comptes !

Je saute sur mon scooter et fonce vers Paris-centre. Moins d'une heure après l'appel téléphonique, j'ai déjà lancé mon script d'analyse magique et regarde ce qui se passe, en relation étroite avec l'administrateur système et le programmeur web, également convoqués d'urgence.

On a bossé non-stop jusqu'à 23h... et ça a remarché ! Les perfs étaient redevenues normales. Un réglage de config du serveur web à corriger, mais l'analyse SQL a permis de cerner le problème

C'est là qu'on apprécie d'avoir préparé à l'avance toute une procédure d'analyse. Pour ne pas perdre de temps et foncer direct vers les points les plus pertinents.

Il y a des jours où on est content du travail efficace :-)

par Pascal MESSAGER publié dans : dba-sqlserver
ajouter un commentaire commentaires (0) créer un trackback recommander

Mercredi 27 juillet 2005

Scénarios de restauration

Lorsque l'on crée une sauvegarde il est capital de se poser la question de la restauration. En particulier : "Dans quel cas de figure est-on amené à faire une restauration, et qu'est-ce que ça règle comme problème ?"

Dans l'imagerie d'Epinal des informaticiens, le risque de perte de données est symbolisé par la perte du disque dur. Vieille réminiscence d'un temps où les coûteux disques de quelques Méga octets avaient une fiabilité douteuse.

Or ce n'est plus le cas aujourd'hui. Les disques approchent le Tera octets avec une fiabilité remarquable, et pour un prix suffisament faible pour qu'on puisse les dupliquer (mirroring, RAID...)

En réalité, la perte physique du disque contenant les dnnées est aujourd'hui un scénario presque négligeable. Mais d'autres événements ont pris le relais. Dont l'erreur humaine qui n'est pas le moindre.

Voici une petite liste non exhaustive de scénarios de 'perte' de données, ou d'appel à une restauration :

Matériel
Disque défectueux	Perte physique du disque contenant sql server.
Disque défectueux	Perte physique du disque contenant des bases de données.
Electronique serveur	Machine physique défectueuse.
Site	Incendie ou destruction totale de la salle serveur.
SQL
Corruption base	Fichiers de la base physiquement corrompus.
Perte login	Perte de droits d’accès, admin ou utilisateur.
Erreur humaine
Bug applicatif	Découverte d’un bug après mise en prod qui affecte la cohérence des données.
Opération inopinée	Destruction involontaire de données (delete sauvage…)
Malveillance	Modification volontaire des données par un attaquant. Peut remonter loin dans le temps.
Virus	Virus corrompant les données et programmes.
Maintenance
Duplication	Demande de duplication de la base vers une autre machine (de test notamment)
Retour version	Annulation d’une mise à jour logicielle qui s’avère défectueuse.
Déplacement	Changement de machine physique supportant le serveur sql.
Mode dégradé
Coupure électricité	En cas de coupure d’électricité, les onduleurs ont une autonomie très limitée. Or certaines applications sont plus prioritaires que d'autres.
Performances	Baisse de performances subite.

Il est clair que pour certains scénarios une application bête et méchante de la restauration ne suffit pas. Par exemple (cas le plus difficile) si un virus a lentement corrompu les données. Il faut appliquer alors une stratégie adaptée.

La préparation de ces scénarios et la mise en en place de procédures semi-automatiques de restauration facilite et accélère le travail de reprise.

par Pascal MESSAGER publié dans : dba-sqlserver
ajouter un commentaire commentaires (0) créer un trackback recommander

Mardi 5 juillet 2005

Sauvegardes : durée réelle d'un incident

Il ne suffit pas de faire des sauvegardes pour se sentir en sécurité. Outre que j'ai trop vu de serveurs mal voire pas sauvegardés du tout, j'en ai vu aussi où la capacité de reprise du travail normal suite à un plantage était douteuse.

Lors dun incident, le stress est particulièrement important. La perte de temps et les erreurs qui en découlent peuvent être pires que lincident lui-même. Doù limportance de savoir restaurer une base dans la sérénité, donc de réaliser la manipulation de temps en temps.

Mais même en situation optimum :

L'incident est repéré tout de suite.
Les responsables peuvent facilement décider de restaurer la base affectée.
Il n'y a pas de manip de matériel à changer.
Les sauvegardes sont gentiment planifiées, y-compris le journal de transaction.
Le DBA sait faire une restauration en sifflotant.
Les fichiers sont en ligne...

... le temps incompressible d'interruption de productivité n'est pas négligeable.

A noter qu'on a ici affaire à un bug gentil, il est même plutôt coopératif. Ce n'est pas toujours le cas !

Le diagramme ci-dessous exprime l'enchainement des événements dans un cas favorable.

Malgré la bonne volonté de tous, le temps d'interruption est de cinq heures.

Or on a très vite un dérapage si un quelconque des intervenants n'accomplit pas sa tâche dans le temps minimum théorique imparti. Autant dire que le dérapage est inéluctable.

Ce qui se traduit par une perte sèche d'activité = Nombre employés (ou clients !) * Durée d'interruption.

Conclusion : Sachez mettre en place un mécanisme d'intervention d'urgence. La sérénité qui en découle n'a pas de prix.

par Pascal MESSAGER publié dans : dba-sqlserver
ajouter un commentaire commentaires (0) créer un trackback recommander

Pascal MESSAGER, dba sqlserver

Présentation

Navigation

Articles récents

Pages

SQL 2008 : c'est parti

Fiabilité des données, talon d'Achille de l'informatique

SOS SQL "pin pon pin pon"

Scénarios de restauration

Sauvegardes : durée réelle d'un incident