La taille des bases de données revue à  la hausse avec Exchange 2003 SP2

Vous avez probablement entendu parler de l’une des grandes nouveautés dbase de données.

Organisation des index dans SQL Server 2005

SQL Server 2005 introduit un nouveau modèle pour les commandes DDL (Data Definition Language). Vous allez créer tous les objets au moyen d’une commande CREATE, les supprimer à l’aide d’une commande DROP et les modifier avec ALTER.SQL Server 2005 n’utilisera pas de procédures stockées distinctes pour modifier un aspect d’un objet, comme sp_defaultdb dans SQL Server 2000 et 7.0, qui modifie la base de données par défaut d’un utilisateur, ou encore les commandes de création spéciales à finalité unique telles que sp_addtype. SQL Server 2000 a déjà fait un pas dans cette direction en améliorant la fonctionnalité de la commande ALTER DATABASE afin d’inclure toutes les modifications apportées aux propriétés de base de données et en décourageant le recours à la commande sp_dboption.

Vue d’ensemble des informations de fragmentation SQL Server

L’article « Organisation des index dans SQL Server 2005 » présente les spécifications permettant d’appeler la nouvelle fonction TVF (Table-Valued Function) sys.dm_db_index_physical_stats() dans SQL Server utilise des listes de pages séparées (organisées en fonction du mode de stockage par SQL Server des données sur la page). Par ailleurs, la version 2005 introduit la possibilité de créer une table ou un index sur des partitions distinctes, chaque partition ayant sa propre liste de pages. Une liste de pages d’un type pour une partition est appelée unité d’allocation. SQL Server 2005 gère un maximum de trois unités d’allocation pour chaque table ou index de chaque partition. Ces trois unités d’allocation sont mappés avec trois types de pages gérés par SQL Server 2005 : IN_ROW_DATA (à savoir les lignes de données ou d’index classiques), LOB_DATA (à savoir, les données d’objets de grande taille, telles que text, ntext ou image) et ROW_ OVERFLOW_DATA (un nouveau type de stockage).

Démystification du débogage dans SQL Server 2005

Pour déboguer une procédure stockée T-SQL dans SQL Server 2000, vous faites appel à l’Analyseur de requêtes (Query Analyzer). Il suffit de cliquer avec le bouton droit de la souris sur la procédure stockée et de sélectionner Débogage (Debug). Dans SQL Server 2005, l’Analyseur de requêtes est remplacé par SQL Server Management Studio et il serait logique de penser que la démarche sera similaire, à savoir cliquer avec le bouton droit de la souris sur la procédure stockée T-SQL et sélectionner la fonction de débogage de Management Studio. Ce n’est malheureusement pas aussi simple car vous ne trouverez aucune option de débogage.Dans SQL Server 2005, le débogage d’une procédure stockée T-SQL passe par l’utilisation de l’environnement de développement Visual Studio 2005. Mais, avant d’en arriver là, il faut avoir de la matière à déboguer. Au lieu de reprendre une procédure stockée existante ou d’en créer une dans Management Studio, nous allons en construire une via le type de projet mal connu Database de Visual Studio 2005. Dans les projets Database, vous pouvez accéder au Query and View Designer, lequel fournit des outils graphiques pouvant servir à créer des procédures stockées T-SQL.

Maintenez vos lots dans l’ignorance

Imaginez le scénario suivant : vous venez de finaliser la création d’un lot dans SQL Server Integration Services (SSIS). Vous l’avez testé avec différentes entrées et tout semble fonctionner à merveille. La gestion des erreurs est adaptée, vous partagez les lots qui isolent la logique commune en tant que sous-lots, vous disposez de gestionnaires d’événements qui vous informent de problèmes éventuels dans les lots ou qui gèrent la sortie des erreurs de la tâche de flux de données.Cette dernière se déroule rapidement et sans accroc dans votre environnement de développement. Ensuite, vous transférez le lot sur le serveur de production et patatras ! Des erreurs se produisent et plus rien ne semble fonctionner. Cette situation a-t-elle un air de déjà vu ?

Les lots SSIS sont étroitement liés à leur environnement d’exécution. Ils référencent des dossiers et fichiers sur certains lecteurs, se connectent à des serveurs spécifiques, sont à l’écoute d’événements particuliers et assurent d’autres fonctions liées à l’environnement. Même si la création d’un lot simple est relativement facile, la tâche peut prendre des allures de défi si elle consiste à écrire un lot encore capable de s’exécuter correctement dès lors qu’il est déployé sur un autre ordinateur.

Ce défi est l’un des plus courants auxquels les utilisateurs de SSIS sont confrontés. Bien que SSIS propose certains outils pour résoudre ces questions, il n’est pas toujours évident d’identifier la bonne approche ou de savoir comment appliquer les outils en question.

Cet article se propose d’expliquer comment utiliser les configurations SSIS et les expressions de propriété afin de résoudre le problème des lots dépendants de l’emplacement. Il présente une méthodologie générale permettant de simplifier le déploiement des lots et une approche aux problèmes les plus fréquents concernant leur portabilité. En appliquant ces concepts et pratiques aux situations rencontrées dans votre environnement, vous pouvez réduire l’incidence d’un échec des lots au cours de leur déploiement.

Conception bitemporelle : une notion du temps peut en cacher une autre

Imaginez que votre base de données soit une machine à voyager dans le temps, vous pourriez traiter toutes les requêtes des utilisateurs ! L’analyse décisionnelle (en anglais BI, Business Intelligence), qui inclut OLAP, les data warehouses et les data marts ou encore le data mining, est un secteur en pleine expansion.Parmi les points communs fondamentaux des technologies BI, citons la gestion des données historiques et la mise en oeuvre d’une logique temporelle. Par exemple, un entrepôt de données type stocke des informations sur les ventes qu’une entreprise comptabilise par périodes de temps. Les données de vente de base peuvent avoir un historique concernant leurs révisions. Les conceptions de base de données bitemporelles améliorent les technologies BI en proposant une structure générale pour les données temporelles.

La conception de base de données bitemporelle constitue une technologie largement sous-utilisée, aux multiples applications possibles. La majorité des bases de données ont une forte proportion de contenu et de logique à caractère temporel ou pourraient exploiter ceux-ci à leur avantage. De nombreuses applications pourraient tirer parti de la conception bitemporelle, notamment la vente au détail, les systèmes de réservation, de prix, de taux de remise, de taux d’intérêt ou de planification de la production, la gestion des stocks, la médecine clinique et bien d’autres encore. La technologie bitemporelle propose une structure formelle permettant d’ajouter une notion temporelle à vos bases de données. Le présent article aborde certains concepts et propose des exemples de cette approche. Les détails de mise en oeuvre et d’autres améliorations feront l’objet de prochains articles.

Réplication de base de données contre réplication du stockage

De nombreux base de données permet de satisfaire des exigences de réplication spécifiques non prises en charge par l’autre approche. Le présent article se propose d’examiner les trois facteurs décisifs à prendre en considération afin de combiner au mieux les deux approches pour votre organisation.

Optimisation des bases de données MS SQL Server – Partie 1

On a beau répéter que l'optimisation de bases de données ne relève pas d'outils ni d'automatismes, mais du simple artisanat, il y a toujours quelques personnages pour prétendre qu'il suffit de faire ceci ou cela, pour obtenir de bonnes performances. Si les choses sont plus complexes qu'il n'y paraît, il n'en reste pas moins vrai que certains principes simples et des règles d'une grande évidence qui devraient guider l'équipe en charge du développement d'un projet informatique, sont souvent ignorées voire sciemment bafouées.

 Cette série d'articles a pour but de présenter l'optimisation des bases de données sous toutes ses facettes. Il ne s'agit pas d'un cours technique (pour cela la place manquerait), mais plus globalement d'une réflexion sur les erreurs à ne pas commettre, celles à rectifier et les mesures à prendre dans le cadre de l'exploitation courante d'une base de données.

Compressez vos données

Les .NET Framework pour étendre la puissance de SQL Server 2005.

Construisez vos propres systèmes de sécurité automatisés

Il était une époque où la sécurité des SQL Server n’aurait l’idée de donner le feu vert à une base de données sans contrôler au préalable ses vulnérabilités concernant la sécurité, par exemple la présence de mots de passe faibles ou de firewalls perméables. Mais comment savoir si vous avez vérifié tous les paramètres de sécurité essentiels ? Ainsi, si vous omettez de verrouiller vos dossiers d’installation ou de désactiver le compte Invité (Guest) de votre serveur, vous serez à la fête !

La réponse à la question ci-dessus consiste à élaborer un plan structuré de test de la sécurité, afin de contrôler différents paramètres de configuration requis par votre entreprise et de générer les rapports consignant les résultats des tests. Cet article présente, dans un premier temps, les aspects constitutifs d’une approche de test de la sécurité, puis fournit des exemples de code TSQL utilisables afin d’automatiser certaines parties de votre processus de test de la configuration et de génération des rapports correspondants. Mais commençons par le commencement.

SQL 2008 : nouveaux types de données

SQL Server 2008 propose donc une gestion optimisée de ces éléments avec les types: goemetry, geography et filestream. Mais ce n'est pas la seule évolution proposée par SQL Server 2008 au niveau des données. En effet, SQL Server 2008 propose une gestion plus fine des données de type date et heure en proposant différents types de données. SQL Server 2008 offre également la possibilité de gérer correctement les données hiérarchiques par l'intermédiaire du type hierarchyid et les différentesméthodes associées.

Mais avant de commencer à présenter ces différents points, il est important, de souligner, que lorsque vous écrivez du code Transact SQL depuis SQL Server Management Studio (SSMS) le complément automatique du code est maintenant actif. L'avantage est double car il évite les erreurs de saisie et permet également d'écrire plus rapidement le code. Il n'y a maintenant plus de doute possible quant à l'orthographe exacte d'une variable ou bien le nom d'une méthode.

Visual Explain ou 5 moyens essentiels d’utiliser iSeries Navigator

Dans l’article « A little feedback mechanisms », j’expliquais les divers mécanismes de retour d’information de DB2 for i5/OS SQL . L’un des plus intéressants et utiles est Visual Explain. Comme je le décrivais dans l’article, Visual Explain fait partie intégrante d’iSeries Navigator – l’interface graphique pour i5/OS et DB2 for i5/OS.Avec i5/OS V5R4, iSeries Navigator était nettement amélioré pour fournir plus d’informations grâce à davantage d’outils. Dans la foulée, Visual Explain a lui aussi été amélioré. Nous avons comparé Visual Explain aux autres sources d’informations sur les moteurs de bases de données et les optimiseurs de requêtes. Il est le meilleur pour extraire des données et les rassembler en un endroit et pour afficher l’information de manière concise. Voici donc cinq moyens essentiels pour bien utiliser Visual Explain.

Réunion du GUSS : SQL Server 2008, vers une amélioration de l’ergonomie !

En décembre dernier,  la réunion du groupe des utilisateurs francophone de SQL Server (le GUSS) s’est tenue dans les locaux de Microsoft France. Ce rendez-vous fut l’occasion d’une rencontre entre les membres du groupe, mais aussi de découvrir en avant-première, la version 2008 de Microsoft SQL Server. Cette preview était animée par Patrick Guimonet, et […]

Visualiser les données à  partir de WDSC

En pensant « WDSc », beaucoup pensent aussi « Ah oui, c’est ce qui me permet de coder mes programmes RPG au lieu d’utiliser PDM/SEU ». Bien vu ! Mais WDSc (WebSphere Development Studio client), ou peut-être plus précisément la RAD (Rational Software Development) plate-forme animée par Eclipse, va bien au-delà d’un coding sympa en RPG. Du développement de programmes RPG et d’applications Web à l’utilisation d’un générateur d’applications (comme Enterprise Generation Language ou EGL) et à l’exploration des bases de données où qu’elles se trouvent, les outils dont dispose WDSc peuvent remplir la mission.Cet article se concentre sur Data perspective de WDSc. Cependant, si vous faites tout le travail de base de données sur l’i5 avec des fichiers physiques et logiques provenant de DDS, il n’y a peutêtre pas là pour vous grand-chose de substantiel. Mais si vous utilisez SQL pour construire et maintenir des bases de données, ou si vous envisagez d’utiliser WDSc pour d’autres genres de développement applicatif que RPG (par exemple, applications Java, EGL d’IBM), alors la Data perspective deviendra rapidement votre amie.

Sécuriser votre base de données avec le point de sortie Open Database File

Établir, appliquer et maintenir une politique de sécurité de la base de données, voilà qui devrait figurer tout en haut de votre liste de priorités. L’i5 offre de nombreuses fonctions de sécurité et de préservation des données. Je présente ici le point de sortie Open Database File et explique comment il permet de combler des lacunes potentielles du système de sécurité de la base de données i5.

Une question d’intégrité : guide pratique des transactions sur bases de données

Le traitement transactionnel est au coeur de la plupart des applications i5. Une application est une opération logique unique qui consiste généralement à lire ou à mettre à jour une ou plusieurs tables de bases de données (plus banalement, des fichiers). Quelle que soit l’action des utilisateurs : saisir des commandes, planifier des réservations d’hôtel, ou exécuter des transactions financières, une application doit être conçue de telle sorte que toutes les transactions satisfassent au test « ACID »« ACID » :
• Atomicité (Atomicity) : Tous les effets d’une transaction réussissent ou tous échouent.
• Cohérence (Consistency) : La base de données reste dans un état cohérent vis-à-vis de ses règles d’intégrité, et cela qu’une transaction s’exécute correctement ou échoue.
• Isolation : Les effets d’une transaction sont isolés des effets des transactions effectuées au même moment par d’autres applications et utilisateurs.
• Durabilité (Durability) : Les effets d’une transaction bien « committed » persistent même en cas de défaillance du système.

Sans la puissance et la sophistication de i5/OS et de DB2, il serait pratiquement impossible de s’assurer que les applications remplissent tous les critères ACID. Heureusement, il est facile d’effectuer des transactions fiables sur le i5 quand les applications bénéficient de la journalisation et du contrôle de commitment : deux fonctions intégrées dans l’architecture i5 depuis le S/38.

Deux de ces critères, la cohérence et la durabilité, sont plutôt simples et assurés automatiquement, pour la plupart, par DB2. Pour maintenir la cohérence de la base de données, DB2 rejette les mises à jour qui violent les contraintes suivantes d’une table : clé primaire, unique, clé étrangère, ou vérification. Les développeurs d’applications n’ont que deux choses à faire :

• Définir les contraintes appropriées sur l’instruction Create Table SQL ou sur la commande CL Add Physical File Contrainst (AddPfCst).
• Ajouter le code applicatif nécessaire pour détecter et traiter les erreurs d’I/O, y compris les violations de contraintes.

La durabilité est instaurée quand une table est journalisée: c’est ce qui se passe par défaut quand on crée une table avec une instruction SQL Create Table. On peut aussi utiliser la commande CL JrnPf pour journaliser une table (ou un fichier physique non-SQL). Quand une table est journalisée, le système écrit une entrée dans un récepteur du journal et l’envoie de force en stockage auxiliaire avant que la table de base de données associée ne soit physiquement modifiée. Quand une table est ouverte sous le contrôle de commitment, le système écrit aussi les entrées du journal pour les opérations commit et rollback.

Si une table est endommagée, vous pouvez récupérer ses mises à jour en restaurant la table à l’aide de la sauvegarde la plus récente puis en appliquant les entrées du journal pour amener la table au niveau de la dernière opération de mise à jour ou de la dernière transaction « committed ». La journalisation des tables est une bonne pratique que l’on devrait appliquer systématiquement pour la plupart des tables de base de données. (Vous trouverez de la documentation sur la journalisation dans la rubrique Systems ManagementIJournal Management dans le V5R4 Information Center.) DB2 prend aussi en charge le principe de « toutes ou aucune » transactions (c’est-à-dire l’atomicité) et plusieurs niveaux d’isolation des transactions. Bien que ce soient des aspects distincts du support des transactions, sur l’i5 ils sont tous assurés par l’environnement de contrôle de commitment i5/OS. Le contrôle de commitment, à son tour, compte sur la journalisation pour garantir le principe « toutes ou aucune » tra

Interview Walter Scott : Les systèmes de sauvegarde et de restauration

Quelques questions à Walter Scott, Président-directeur général, Imceda Software. Mise en ligne : 15 Novembre 2006, Publication SQLServer : Avril 2005.

Les systèmes de sauvegarde et de restauration destinés à votre entreprise ne sont pas seulement bénéfiques pour l’activité, ils sont obligatoires.

Pilote automatique

par Herts Chen - Mis en ligne le 18/02/2004

Raccourcissez le temps de réplication instantanée et de configuration avec cet outil d'automatisation

Quand vous appliquez la réplication instantanée à  de grandes bases de données, l'étape qui supprime les enregistrements cibles et celle qui copie en bloc les données sources dans des tables cibles indexées peuvent créer deux goulets d'étranglement des performances...Quand vous appliquez la réplication instantanée à  de grandes bases de données, l'étape qui supprime les enregistrements cibles et celle qui copie en bloc les données sources dans des tables cibles indexées peuvent créer deux goulets d'étranglement des performances. Pour éliminer ces goulets d'étranglement - et donc optimiser la réplication - vous pouvez ajouter des étapes personnalisées aux jobs Snapshot and Distribution Agent. Dans le premier article de cette série en trois parties, « Ouvrez la voie à  la réplication snapshot à  grande échelle », octobre 2002, (ou sur www.itpro.fr), j'analysais la performance d'une réplication instantanée et introduisais les étapes personnalisées. Le deuxième article, « Personnalisez votre réplication instantanée à  la main », janvier 2003, (ou sur www.itpro.fr), détaillait l'implémentation manuelle complète de ces étapes. Dans cet article de conclusion, voyons comment réaliser une personnalisation rapide, fiable et reproductible en utilisant SQL-DMO (SQL Distributed Management Objects) pour automatiser le processus de personnalisation.

Introduction à  la mise en oeuvre de DRDA

Il y a une décennie, IBM a présenté DRDA (Distributed Relational Database Architecture) comme moyen d’accès à des données relationnelles entre des systèmes multiples.En octobre 1998, la propriété de DRDA est passée d’IBM à l’Open Group (http://www.opengroup.org), un consortium basé au Royaume-Uni d’éditeurs de logiciels. On peut donc désormais considérer cette architecture comme le standard pour les bases de données distribuées.

Faciliter les consultations des bases de données en réseau

Je suis toujours en quête d’outils susceptibles de simplifier mon travail d’administrateur système. Ils sont parfois offerts par un fournisseur tierce partie, mais d’autres fois je dois les créer. Ce sont souvent des scripts qui s’exécutent à partir de la ligne de commande – sans fioritures, mais efficaces.Il est important d’apprendre le scripting administratif à cause des limitations de nombreux outils d’administration de type Windows : le scripting procure la personnalisation qui manque souvent aux solutions standard.