Tatouages de DB et traçabilité

Un des plus grands défis auquel un dba est confronté est de connaitre les implications exactes des databases exploitées sur ses instances SQL…

En gros, combien de personnes meurent en cas de soucis, quelle sont les applications qui y sont connectées, qui peut y faire joujou, quels sont les créneaux d’administration possibles, le type de backup adéquat etc etc…Sans compter le jour béni de la migration, où on se prend délicieusement les pieds dans le tapis ou le seau sur la figure sans connaissance de toutes les petites ramifications. Bref hop 30% du temps de projet (et je suis gentiiiiiiiiille—toujours)

Dans le monde des tendres licornes, une merveilleuse CMDB, parfaitement à jour, sera capable de donner dans l’instant jusqu’au groupe sanguin du développeur du dernier package, car on le sait bien le rhesus O+ a tendance à abuser du NOLOCK…

Plus probablement, après être venu remplacer le DBA précedent en burn-out, on se sera retrouvé  face à ceci

Alors que bien entendu l’objectif absolu est plutot d’approcher ça…(oui j’ai toujours regretté le petit personnel)

Sans m’égarer , je dois tout de meme confesser une vraie tendance à vouloir avoir sous controle nombre de choses: mes serveurs et leurs database, les developpeurs et leur code, le san et ses IOPS, le réseau et sa @#$$$*** de latence … (ajoutons y les project manager, les commerciaux, la circulation sur les routes et le fond sonore généré par mes filles…je crois que j’ai la fibre dominante)
Les deux premiers points  au moins sont dans mon job description… Et le vôtre.
la Solitude du DBA m’ayant appris l’autonomie , j’ai pris pour habitude de documenter, inventorier, repertorier, lister etc..
DBA NSA meme combat, j’ai meme des scripts qui tournent pour connaitre exactement qui se connecte sur quoi a partir de où –et que donc “OUI on peut DECOMISSIONNER!!!”–les mecs ca n’ose rien jeter c’est connu, vieux t-shirt ou db pourrie “on ne sait jamais”.
Evidemment les informations collectées me sont précieuses…utiles. Au point que j’aime pouvoir les lire pour regler mes tâches.

Tout ceci pour m’amener au vif du sujet. Cette information morcelée, fragmentaire manquante est cependant indispensable pour mener à bien notre travail de DBA:

• maintenance
• backup
• haute disponibilité
• déplacement
• etc etc

C’est la raison pour laquelle j’ai décidé de “tatouer” les databases tout comme on bague les pigeons, on trace la viande bovine…

L’idée m’en est venue via un petit utilitaire sympa http://www.sqltreeo.com/wp/ qui utilise tout simplement les propriétés étendues des databases pour les placer dans des “virtuels folders” –ce qui est bien confortable. Bon sang mais bien sûr… En utilisant moi aussi les prorpiétés étendues et en y créant des champs personnalisés je peux noter des infos qui suivront la db où qu’elle soit, meme après un move ou un restore, d’environnement en environnement..On peut démarrer dès la conception avec les SSDT ….

Et ensuite je peux l’exploiter… non seulement pour garder mon inventaire à jour mais aussi pour piloter mes actions.
C’est ainsi que nous tatouons nos DB avec un RPO pour definer la fréquence et le type de Backup—J’ai adapté les scripts de Ola Hallengren en conséquence. Nous avons aussi un HA qui permet de les ajouter dans un groupe de disponibilité via PowerShell et de nous assurer d’un certain nombre de choses–genre recréation des logins sur les replicas…Un DoHealthCheck pour notre petite routine de check quotidienne…et on continue

Ces proprietés sont très faciles à mettre en place et à gérer:

en T-SQL… genre

use [replacewithdbname]
EXEC sp_addextendedproperty @name = ‘HA’, @value = ‘1’;
EXEC sp_addextendedproperty @name = ‘RPO’, @value = ‘Hourly’;
EXEC sp_addextendedproperty @name = ‘SLA’, @value = ‘HIGH’;
Go

en SSMS

Et ensuite à lire:

genre en PwShell

$DatabaseList = $sqlServerPrim.Databases
foreach ($Database in $DatabaseList)
{
#$ag=invoke-sqlcmd “select replica_id from sys.databases”
$sla=$Database.ExtendedProperties | where {$_.name -eq “ha”} | Select Value
$sla.value

etc…..

ou en T-sql —genre…

DECLARE @str NVARCHAR(512)
SELECT @str = ‘select ”?” as databaseName,”U” as DatabaseType,”1” as selected from [?].sys.extended_properties where name=”RPO” and cast(value as varchar(10)) =”’ + @RPO + ””
INSERT INTO @SelectedDatabases (DatabaseName, DatabaseType, Selected)
exec sp_MSforeachdb @str

Bref une fonctionnalité bien trop sous-utilisée et dont je suis sure votre créativité ne demandera qu’a se repaître.

ENJOY!!!!