SQL Server - Réduction automatique (AUTO_SHRINK), une mauvaise pratique !

La réduction automatique est une mauvaise pratique en environnement de production. Laissez ce paramètre à False dans un environnement de production.


Remarque :
  • Les opérations de rétrécissement de fichiers doivent être réservées aux cas bien particuliers et spécifiques, par exemple, manque d'espace disque sur un serveur de test ou de développement.
  • Les opérations de rétrécissement sont très gourmandes en ressources CPU et opérations disques I/O, et peuvent même générer des time-out du sous-système I/O.
  • Les opérations de rétrécissement provoquent la fragmentation des indexes. Et oui ! le rétrécissement consiste à déplacer les données de façon brutale sans aucune précaution particulière, plus ou moins intelligente.
  • Les opérations de rétrécissement ont pour effet de déplacer beaucoup de données à travers le tampon mémoire, et finissent par vider le cache des données vers le disque, ce qui provoque un ralentissement considérable.
  • Pendant que SQL Server compacte les fichiers, la base est entièrement verrouillée.
  • Lorsque à l’inverse le système a besoins d’espace disque après un rétrécissement, (effet yo-yo après un régime !), le moteur de base de données, pour pouvoir allouer de l’espace disque, pose des verrous de niveau FS, sur les data files, et pendant tout ce temps la base entière est verrouillée. Ceci a également un impact très préjudiciable sur les performances !

Conlusion

Dans un environnement de production assurez-vous que l'option de base de données "Reduction automatique" est bien définie à False, et au besoin lancez la commande ci-dessous :
ALTER DATABASE [Nom_de_votre_base_de_donnees] SET AUTO_SHRINK OFF WITH NO_WAIT

SQL Server - Vérifier et réparer une base de donnée DBCC CHECKDB

Dans cet article j’explique comment vérifier et réparer une base de données SQL Server.
J’explique notamment comment faire la distinction entre les opérations et options qui peuvent potentiellement générer des PERTES DE DONNEES et celles qui ne génèrent pas de perte de données.

1 - Vérifier l’intégrité d’une base de données

La commande DBCC CHECHDB vérifie la cohérence et l’intégrité d’une base de données. Elle constitue la principale méthode de recherche d’une corruption dans la base. La commande DBCC CHECKDB effectue les vérifications suivantes :

La conjecture des champions sauteurs

Selon des analyses informatiques et heuristiques effectuées sur des ordinateurs on a pu faire le constat suivant :

- Jusqu'à l'entier 389, l'écart le plus fréquemment observé entre deux nombres premiers consécutifs est 2. Ensuite l’écart le plus fréquent est 6 et cela semble le rester très longtemps.
Le champion 6 est détrôné vers 1,70 1036, et est alors remplacé par 30.
(remarquez au passage que 30 = 2x3x5 et que le champion précédent 6 = 2x3).

- Plus généralement, on a constaté que les champions successifs sont les produits de nombres premiers : 2, puis 6 = 2x3, puis 30 = 2x3x5 puis 210 = 2x3x5x7 puis 2310 = 2x3x5x7x11 etc.

Suite à ce constat, une loi remarquable a été énoncée :

Si on note D(n) = 2x3x5x....xpn le produit des nombres premiers jusqu'au n-ième, alors D(n) deviendrait le champion à partir du nombre :
N(n) = exp[( 2x3x5x....x pn-1x(pn-1)/ln((pn-1)/pn-2))]

n D(n) N(n)
2 6 389
3 30 1,70 1036
4 210 5,81 10428
5 2310 1,48 108656
6 30030 1,30 10138357
... ... .....
10 6469693230 3,56 1074595540317

Testée à l'aide d'ordinateurs la loi remarquable ci-dessus apparaît confirmée.

Il ne vous aura pas échappé que ce type d'analyse fait de l'arithmétique une bien étrange science ! En effet, il n'y a ni théorème ni démonstration, seulement des résultats établis par des d'ordinateurs, des pures conjectures !

SQL Server - Comment exprimer dans une clause WHERE que deux ensembles A et B sont égaux ?

I – Prolégomènes
En complément de mon précédent article : "SQL Server - Comment exprimer dans une clause WHERE qu'un ensemble A est inclus dans un ensemble B ?", j'explique ici "Comment exprimer dans une clause WHERE que deux ensembles A et B sont égaux ?".

SQL Server - Comment exprimer dans une clause WHERE qu'un ensemble A est inclus dans un ensemble B ?

I - Prolégomènes
Soient 2 ensembles A et B, où par analogie avec la notion de Relation (autrement dit une table) du modèle relationnel, les éléments de chacun des 2 ensembles A et B sont représentés par des lignes ; il s’agit tout simplement des lignes de tables.

Rappelons au passage, qu’une Relation, dans la théorie des ensembles, et également dans le modèle relationnel utilisé par les SGBD relationnels comme ORACLE, SQL Server, DB2, etc. n’est autre chose, qu’un sous-ensemble du Produit cartésien de degré n (n-uplet) de n ensembles Dn, où chaque Dn représente l’ensemble dans lequel les données de la colonne Cn de la Relation prennent valeur. Les ensembles Dn sont généralement définis par intention et représentent les types de données des colonnes Cn. Exemple : VARCHAR(10), DATETIME, DECIMAL(18, 6), etc.

Un problème, assez récurrent dans SQL, est le suivant : "Comment exprimer, en SQL, dans une clause WHERE, le fait qu’un ensemble A doit être inclus dans un ensemble B ? Exemple : Tous les Clients doivent être également des Personnes morales, autrement dit, l’ensemble des Clients doit être inclus dans l’ensemble des Personnes morales ?".

SQL Server - Lister les propriétés d'une instance SQL Server

Ci-dessous une fonction qui peut se révéler très pratique pour obtenir, en une fois, toutes les propriétés et informations importantes du Serveur et de l’instance SQL Server.

SQL Server - NULL, or NOT NULL : that is the question !

Il arrive assez souvent de constater dans les script de création de tables (CREATE TABLE) ou de modification de structures de tables (ALTER TABLE), que certaines colonnes ne sont dotées d'aucune mention précisant leur caractère nullable ou non-nullable.

SQL Server - Gestion des exceptions TRY .. CATCH.. Rendre une application plus robuste

I - Introduction

Depuis SQL Server 2005, (et donc valable également sous SQL Server 2008, 2008 R2 etc.), il est enfin possible de gérer sérieusement les exceptions au travers les constructions TRY CATCH.
La gestion des erreurs dans les versions précédentes, sous SQL Server 2000 par exemple, n'était pas vraiment à la hauteur et n'était pas digne d'un langage évolué moderne.
Sous SQL Server 2000, la détection et la gestion des erreurs déclenchées par les commandes T-SQL ne pouvaient être effectuées qu'en vérifiant le contenu de la variable système globale @@error. Celle-ci retourne le numéro d'erreur déclenchée par la dernière instruction T-SQL exécutée. Donc, sous SQL Server 2000, Il fallait lire le contenu de la variable @@error après chaque instruction T-SQL ! Il faillait, en plus, généralement, stocker le contenu de @@error dans une variable locale ! En effet, la variable globale @@error est effacée et réinitialisée (remise à zéro) à chaque exécution d'une instruction. Cette approche complètement archaïque conduisait à surcharger le code T-SQL des procédures par des instructions comme « IF @@error <> 0 .. » jusqu'à le rendre illisible !

La construction TRY ..CATCH disponible depuis SQL Server 2005 (et donc valable également sous SQL Server 2008, 2008 R2 etc.), offre une syntaxe beaucoup plus lisible, avec laquelle les développeurs sont déjà habitués au travers d'autres langages évolués comme C# ou C++.

Dans cet article, je vais vous présenter, au travers d'exemples concrets, comment grâce à la construction TRY CATCH, combinée à l'option XACT_ABORT, et à la fonction XACT_STATE(), vous pouvez écrire du code T-SQL robuste intégrant une gestion sérieuse et solide des erreurs. Dans cet article, j'explique également comment, au travers ces nouvelles constructions (TRY CATCH, etc.),  annuler et mettre fin aux transactions en erreur et libérer ainsi les verrous posés sur les enregistrements par les transactions.

La conjecture des nombres premiers jumeaux

Deux nombres premiers jumeaux sont deux nombres distants de 2 unités.
Parmi les plus petits nombres premiers jumeaux, vous avez :
3-5,  7-9,  11-13,  17-19,  29-31, etc.

La conjecture des nombres premiers jumeaux stipule ceci :
« Il existe une infinité de nombres premiers jumeaux »

Les observations numériques et des raisonnements heuristiques semblent justifier la conjecture, mais aucune démonstration n'en a encore été faite !

SQL Server - Démystifier le type DATETIME et utiliser le format ISO 8601


I - Introduction

La manipulation des dates sous SQL Server a toujours été un cauchemar pour les utilisateurs et même pour les développeurs. Dans les forums dédiés à SQL Server, vous rencontrerez une avalanche de questions au sujet de type DATETIME.

Ces difficultés, à mon sens, proviennent, d'une part du fait que les fonctions, fournies par SQL Server, ne sont pas assez évoluées pour une manipulation aisée des dates (des améliorations ont été apportées sous SQL Server 2012 pour combler cette lacune, mais au moment où je rédige cet article, tout le monde n'utilise pas encore SQL Server 2012 ! Aussi je n'aborde pas le sujet.), d'autre part, de la confusion, ou de la non compréhension, du type DATETIME, tel qu'il est perçu par les utilisateurs et même par les développeurs.

Ces difficultés se déclinent sous 2 aspects :
- L'aspect expression des dates. C'est à dire, « comment exprimer, de manière littérale, une constante date ».
- L'aspect présentation des dates. C'est à dire, « comment présenter les dates au format chaîne de caractères pour les besoins de reporting etc ». Exemple « le Lundi 12 octobre 2012 à 15h20 ».

Le présent article traite et met l'accent sur le premier aspect du problème, c.à.d « l'expression et la manipulation des constantes DATETIME sous forme littérale ».

Comment déboguer les procédures, fonctions et triggers sous SSMS 2008 (SQL Server 2008 Management Studio)


Vous trouverez ci-dessous le lien vers un article que j'ai publié sur le site  developpez.com, un des plus importants sites francophones dédiés au développement informatique.

Cet article explique comment déboguer une procédure stockée, une fonction ou un trigger sous SSMS 2008 (SQL Server 2008 Management Studio). En d'autres termes, il explique comment définir des points d'arrêts, comment faire du pas à pas dans les blocs T-SQL, comment consulter le contenu des variables locales et variables systèmes @@, etc.

Comment déboguer les procédures, fonctions et triggers sous SSMS 2008 (SQL Server 2008 Management Studio)

La version de l'article au format  pdf ainsi que la version, hors lignes, au format html, sont  téléchargeables depuis le même lien ci-dessus.

La conjecture des nombres parfaits impairs

On connait des nombres pairs qui sont égaux à la somme de leurs diviseurs propres. Exemple :
6 = 1+2+3
28 = 1+2+4+7+14
On dit que 6 et 28 sont des nombres parfaits. On connait, en tout et pour tout aujourd’hui, 47 nombres parfaits ! Mais on ne sait pas s'il en existe une infinité (?). On conjecture que 'Oui'.
Plus intéressant encore, on ne connait aucun nombre parfait impair, sans que jamais personne n'ait pu démontrer qu'il n'en existe pas.
L'affirmation « Il n'existe aucun nombre parfait impair » est une conjecture jugée aujourd'hui très vraisemblable mais non prouvée !
On a juste pu établir et démontrer que si n est un nombre parfait impair, alors il possède au moins 300 chiffres (donc pas la peine de chercher des nombres parfaits impairs à la main !).

Décidabilité, indécidabilité algorithmique d'un problème et programmes informatiques


Définition : Décidabilité, indécidabilité algorithmique d'un problème
Un problème est dit décidable s'il existe un algorithme, une procédure qui termine en un nombre fini d'étapes, qui le décide, c'est-à-dire qui réponde par oui ou par non à la question posée par le problème.
S'il n'existe pas de tels algorithmes, le problème est dit indécidable.

Exemple de problème indécidable : L'indécidabilité du problème de l'arrêt
L'indécidabilité du problème de l'arrêt a été démontrée par Alan Turing en 1936 :
« Il n'existe pas d'algorithme qui permette de décider si, étant donnée une machine de Turing quelconque et son état initial, le calcul de celle-ci s'arrête ou non ».

Du fait de la thèse de Church (du mathématicien Alonzo Church), ce résultat est très général. Depuis l'apparition de l'informatique, on peut l'interpréter ainsi :
« Il n'existe pas de programme permettant de tester n'importe quel programme informatique écrit dans un langage suffisamment puissant, tel que tous ceux qui sont utilisés aujourd'hui en pratique, afin de conclure dans tous les cas s'il s'arrêtera en un temps fini ou bouclera à jamais ! »

L'infini et l'hypothèse du continu (HC)


Pendant très longtemps, jusqu'à la fin du XIX siècle, l'étude de l'infini était considérée comme n'appartenant pas à la science. L'étude de l'infini était du domaine de la philosophie voire même de la religion. C'est grâce à la témérité de Bolzano et de Cantor que l'infini devient un sujet mathématique légitime.
Avant d'exposer l'hypothèse du continu (HC), je voudrais, avant toute chose, rappeler quelques définitions.

SQL Server - Quel type de données choisir Float ou Decimal ?

Il arrive assez souvent, lors de la conception d'une base de données, que certains hésitent sur le choix du type de données d'une colonne. Ils se posent la question, tout à fait légitime : « Dois-je choisir le type Float ou le type Decimal ? » (pour ne citer que ces 2 types de données numériques). 
Il est vrai que la réponse n'est pas évidente et fait même parfois l'objet de discussions interminables sur les forum ! 
Cet article se propose de vous aider ou du moins de vous éclairer et vous permettre de faire un choix, en toute connaissance de cause.

Mathématique

Théorie des ensembles
Divers

Informatique

SQL Server Développement
SQL Server Administration 
Algorithmique