mardi 26 décembre 2006

SSIS - Bug ou feature ?

Bonjour à tous !!!

Voici une grande question concernant le tout beau SQL Server Integration Services !
En effet, bon nombre d'utilisateurs de SSIS auront pu lire ça et là que ce dernier est prévu pour gérer les fichiers XML... Et tout le monde se précipite donc sur cette fabuleuse invention qu'est le "XML File Source"... Somme toute, logique !

J'ai pu lire également que SSIS n'utilise pas les DTD pour des raisons de sécurité, et privilégie l'utilisation des tous beaux XSD !
Jusque là, pas de problème... On peut même lire qu'en cas de nécessité, il suffit de mettre la propriété DTDProhibit à False pour voir SSIS employer une technique éprouvée... Et là, les ennuis commencent !

En présentant un XML valide disposant d'une balise DOCTYPE, je ne pensais pas me retrouver à faire autant de travail dans un outil qui pour moi devait me permettre un développement rapide...
En effet, la première constatation est que la balise DOCTYPE génère une erreur... SSIS propose d'ailleurs dans son message de modifier la valeur de la propriété DTDProhibit...
Logiquement, je recherche la propriété, et là, grande surprise ! Cette propriété n'est accessible qu'en programmation ! Ainsi donc, il ne me reste que deux possibilités pour intégrer un document XML tout ce qu'il y a de plus traditionnel :
- Parser le document en mode texte et supprimer les balises DOCTYPE avant d'intégrer le fichier,
- Programmer un chargement du document dans un XmlDocument...

Résultat, l'intégration d'un simple fichier XML devient très complexe grâce à SSIS ! Bref, un grand progrès...

Donc, bug ou feature ? La firme de Redmond a-t-elle délibérément porté une attaque aux DTD ? N'était-il pas possible de laisser cette propriété visible sur le composant "XML File Source" ?
Dans tous les cas, seuls les utilisateurs s'en trouvent lésés... A mon grand regret...

Un logiciel pour les audits de Bases de données...

Bonjour !

Voici un coup de coeur pour un programme que mon pôle va acquérir dans les jours à venir...
Les logiciels de l'éditeur APEX sont purement et simplement incontournables !!!

En ce qui me concerne, je ne sais pas combien de scripts différents j'ai pu développer ces derniers temps pour un résultat texte médiocre... Certes, cette technique reste appropriée et permet de générer des informations utiles et pratiques à analyser...
Mais que dire alors du résultat obtenu avec APEX SQL... Une pure merveille !!!

Bref, visitez le site http://www.apexsql.com/products.asp, testez, et adoptez !

dimanche 24 décembre 2006

Informations sur la taille des fichiers d'une base de données

Bonjour à tous !

Je viens aujourd'hui traiter d'un sujet que bon nombre de DBA ont à affronter, et ne disposent que rarement des informations le concernant : je veux parler de l'espace restant sur les différents fichiers avant le désastreux et non moins célèbre "Auto-Growth" !

Voici donc quelques commandes très utiles que vous pourrez essayer sans risques...

1 - sp_helpdb :
La première procédure stockée à utiliser dès que l'on recherche des informations sur la taille des différentes bases de données.
Si l'on spécifie en argument le nom d'une base de données, on obtient les informations découpées par fichier... Bref, un sur ensemble de la procédure sp_helpfile !

2 - sp_helpfile :
Là encore, une des procédures stockées très utilisées. Si cette procédure ne permet pas d'obtenir des informations sur le taux d'utilisation des fichiers, elle permet de connaître d'un seul coup d'oeil la structure fichier de la base de données et la taille de chacun.

3 - sp_spaceused :
Une jolie procédure stockée qui permet de connaître les informations de taille de la base de données courante...
A noter qu'il est possible de préciser le nom d'un objet de la base de données pour obtenir des informations sur la taille occupée.
Cette procédure stockée peut s'avérer très utile lors d'un audit afin de repérer les objets volumineux et, le cas échéant, coûteux en ressource disque.

4 - DBCC SHOWFILESTATS :
Une commande non documentée de SQL Server... Et pourtant tellement importante !
En effet, il s'agit de la seule commande permettant d'obtenir le taux d'utilisation des fichiers de données d'une base... Sans recourrir aux tables système bien entendu ;)
Une information cependant : les informations délivrées par cette commande ont pour unité un "extent"... Dans la plupart des cas un extent est de 64 Ko... Alors à vos calculettes !

5 - DBCC SQLPERF(LOGSPACE) :
Si DBCC SHOWFILESTATS permet d'afficher le taux de remplissage des fichiers de données d'une base, DBCC SQLPERF(LOGSPACE) fournit cette information pour les journaux de transactions de toutes les bases de données... Et en Mo s'il vous plaît !
Bref, encore une commande très utile pour savoir si le journal de transactions va bientôt exploser ;)

Voilà donc pour quelques commandes à utiliser sans modération, qu'il s'agisse de SQL Server 2000 ou 2005 ! Et oui, la firme de Redmond a pour une fois choisi de rester compatible... Pour notre plus grand bonheur :D

vendredi 22 décembre 2006

Bug SQL Server 2005 - Version française...

Vous avez dit un bug ?
Oui, tout à fait... J'étais tranquillement en train de faire une jolie démo de la réplication de capture instantanée, Snapshot pour les intimes.
Au détour d'une explication, je vais dans les jobs de l'agent SQL consulter l'historique des messages, histoire de montrer comment constater que la réplication tournait bien... Pour faire le beau en somme...
Et comme toute démo qui se respecte, un vilain petit lutin est intervenu...
Une erreur non critique intervient systématiquement sur la première étape : "Message de démarrage de l'agent de capture instantanée."

Je me suis alors empressé de vérifier l'équivalent sur la version anglaise, et là, Ô surprise, pas d'erreur... Serait-ce la petite apostrophe qui poserait tant de problèmes ?
Dans tous les cas, cette erreur n'est pas corrigée par le service pack 1... Et comme la version CTP du service pack 2 n'existe pas en français, impossible de savoir si ce bug persistera après le SP2...

J'en conclus donc qu'il est important d'utiliser uniquement des versions anglaises en production...
A bon entendeur,

Nouveau blog, nouvelle présentation...

Bonjour à tous,

juste un premier message pour rappeler le contenu de ce blog...

Je mettrai donc ici tous les tricks et tous les bugs que j'ai pu recenser et que l'on trouve difficilement sur le net.
Histoire de faciliter la vie de mes amis les développeurs. Ce blog sera consacré au produit SQL Server 2005 et à ses intéractions avec le CLR .NET.

Voilà, en attendant les tricks, surfez bien !