Relog.exe est un utilitaire intégré à l'OS windows et présent sur les windows XP,7,8 et 10 coté workstation et 2003, 2008, 2008R2 2012 coté serveur.
Cet utilitaire prend en entré un fichier de trace perfmon avec plus ou moins de compteurs actifs dans la trace.
Théoriquement il est facile d'intégrer ces traces dans une base de données avec la synthaxe suivante
relog matrace.blg -o SQL:DSNODBC!IDTRACE
Avec :
# conversion blg --> csv ls -r -include *.blg | foreach{relog $_ -f csv -o $_`.csv} # retrait de l'apostrophe ls -r -include *.blg.csv | foreach-object{(get-content $_) -replace "'"," " | set-content -path $_}
ls -r -include *.csv | foreach{relog $_ -o SQL:ODBC_MSS_PERFMON_2000K!"$($_.directory.name)"}
Modèle des tables de traces
Par contre le modèle des tables générées par relog (cf mdsn) ne me semble pas approprié pour un reporting performant. Le modèle est un modèle normalisé, très souple pour intégrer de nouveaux compteurs mais générant du coup 1 lignes par compteur et par capture.
J'ai l'habitude d'intégrer de nombreux compteurs sur un serveur MS SQL Server. Ces compteurs sont d'autant plus nombreux qu'il y a d'instance hébergées sur la machine. Avec 6 instances SQL server 2005 je monte à plus de 400 compteurs entre les compteurs système (cpu,mem, disques, réseau) et les compteurs sgbd (lock/latches, buffer, session, log, fichier et autres ratios... Si on fait un capture toute les minutes on a 60 * 24 * 400 = 500.000 lignes par jour par machine.
Si on souhaite intégrer les traces de dix machines (60 instances) on se retrouve avec 5.000.000 de lignes par jours
Il est donc indispensable de purger ces tables de traces: par un batch de nuit pas exemple. Une conservation sur 30 jours maximum me parait une bonne approche.
Une des solutions pour réduire le volume de données est de ré-échantilloner les données via relog -t en utilisant un ré-échantillonage toute les 5 ou 10 minutes par exemple.
I was glad to see on mssqltips a script to generate column list for table in order to by use in hashbytes function later for table comparison : article with original get_hash_field function
But as often I needed to do more than just concatenate all fields. My need is :
For that I use store procedure instead of function and dynamic sql was mandatory (for the parameters @p_exception_column_list and @p_key_column_list that are strings with quotes) :
Lire la suite : generate filtered column list for hashbytes
Nagios is a great free tool to supervize many many things in IT. SQL Server is one appliation that can be monitored by Nagios. A great plugin check_mssql_health contains many checks from performance counters to space used and connection time (36 checks at the time of writing).
In order to secure checks on databases, you need to create logins, users and roles on every instances and databases you want to monitor. The Consol Labs web site (Nagios pluggins & Addons editor) give you a script to create (and drop if needed) these objects on one MSSQL instance but :
1 - We found some missings elements on the script
2 - We will give you one method to quickly launch your create script on several MSSQL instances easily using MSSQL Central Management Server or SSMS Registered Groups
Lire la suite : Generate login, user and role for monitoring with Nagios and check_mssql_health
Lors d'un changement de charset depuis un charset monobyte (comme le MSWIN1252 ou le WE8ISO9959P1) vers un charset multi-bytes (comme le AL32UTF8 ou l'UTF8) un phénomène d'agrandissement des tailles en octets des chaines de caractères converties vont probablement entrainer des rejets si une opération classique d'export/import est jouée. Par exemple lorsqu'une table est créée, la taille d'un champs caractère est fixée définitivement. Un VARCHAR(50) dans un CS mono-byte aura une taille de 50 octets (bytes). Si pour une ligne donnée, les 50 octets sont occupées totallement par une chaine de caractères dont au moins un des caractères n'est pas dans les caractères ANSI de base (€, §,@,...) ces caractères auront une taille de 2 octets (voir plus) dans un CS comme l'UTF8.
l'export (datapump naturellement !) depuis une base source (en MS1252 par exemple) va générer un fichier dump, ce fichier s'il est pris tel-quel et qu'un import est joué sur une base cible en UTF8, il sera interprété par l'import en créant les tables avec des colonnes dont la taille en octet sera telle que défini dans la base source (VARCHAR2(50) BYTES par exemple) et ceci même si on positionne un NLS_LENGTH_SEMANTICS à CHAR en cible. L'import créra donc des tables ayant des colonnes dont la tailles max sera insuffisantes pour stocker tous les caractères des chaines sources converties dans le CS cible. Les lignes seront rejetées.
Vous pouvez avoir une idée des "dégats" en lancer l'utilitaire CSSCAN disponible dans le répertoire $ORACLE_HOME/rdbms/admin/scripts
Voici donc comment faire pour s'en sortir en intervenant sur le script de création des tables pour forcer ces creates à incorporer des VARCHAR2(x) CHAR en définition de colonne.
L’objectif de cet article est de décrire précisément la procédure à exécuter pour effectuer la bascule du jeu de caractère MSWIN1252 (ou WE88859Px) en UTF8 sur une nouvelle base de données
La base de données de destination est disponible et le jeu de caractères est déjà en UTF8.
Les schémas sont supprimés sur la base de données de destination.
Toutes les manipulations sont effectuées à partir d’un export DATAPUMP « FULL » de la base de données source.
Lire la suite : Changement de jeu de caractères avec Oracle database
Articles traitant de l'intégration de données
Des tutoriaux et cours gratuits sur Oracle
Tutoriaux sur Unix et les shells scripts