SQL Server 2000 : vers les sommets

Imaginez que vous pouvez construire la maison de vos rêves. Pas de problème de budget, mais vous voulez emménager le plus vite possible. Dans ce cas, il vous faudra choisir entre avoir la perfection avant d'emménager et prendre possession de la maison le plus vite possible. Vous prendrez probablement du temps pour concevoir les fondations et les pièces essentielles, quitte à  ajouter une aile ou à  aménager les combles par la suite. Le processus d'évolution de SQL Server ressemble un peu à  la construction de cette maison. Il y a plusieurs années, Microsoft a réuni plusieurs des meilleurs spécialistes mondiaux des bases de données (de Microsoft et d'ailleurs) et leur a demandé de créer la base de données de leurs rêves. On peut considérer SQL Server 7.0 comme les fondations de ce projet.

Le code de SQL Server 7.0 comportait des évolutions majeures par rapport au code de base mais les DBA et les développeurs ne pouvaient pas voir ou utiliser de nombreuses améliorations. Microsoft SQL Server 7.0 comportait de nombreuses améliorations visibles (telles que les services OLAP), mais la plupart des efforts de reengineering se situait au niveau de la page ou du stockage. J'ai découvert SQL Server 2000 à  la conférence SQL Server Most Valuable Professional (MVP) de Microsoft en octobre dernier.

Les premiers briefings portaient principalement sur l'architecture interne et je suis reparti avec un tuyau important : SQL Server 2000 s'appuie sur les fondations de SQL Server 7.0 et rénove une partie de la plomberie et du réseau électrique. En fait, à  bien des égards, SQL Server 2000 c'est la maison terminée, la grande extension et les salles de projection privées dont vous avez toujours révées.

Lire l'article

Utiliser Microsoft Repository

par Patrick Cross et Saeed Rahimi
Appuyez-vous sur la technologie des référentiels de données pour offrir aux utilisateurs les meilleures sources d'informations stratégiques possibles Ces quelques dernières années, les meilleures pratiques en matière d'entreposage de données (data warehousing) impliquent l'utilisation d'un référentiel pour stocker des informations sur les données contenues dans l'entrepôt. Les informations du référentiel permettent à  l'utilisateur de mesurer l'impact des modifications, de suivre et de gérer les problèmes, et de mieux appréhender les données qu'ils utilisent pour prendre des décisions stratégiques. Microsoft Repository est un élément important de la stratégie Microsoft en matière de data warehousing. Avec les exemples suivants, vous comprendrez et utiliserez le référentiel de façon plus efficace.

Lire l'article

SQL Server 7.0 Réplication personnalisée

par John D. Lambert
Les procédures de transfert-delta peuvent vous apporter le meilleur de la réplication sans les coûts associés SQL Server 7.0 rend la réplication plus simple que jamais mais, pour maximiser votre expertise, envisagez toutes les possibilités. On peut utiliser les assistants de réplication, DTS (Data Transformation Services), l'interface SQL-DMO (SQL Distributed Management Objects) et même du code binaire.
Toutefois, si vous êtes déjà  un utilisateur chevronné de T-SQL, pensez à  apprendre à  utiliser des procédures cataloguées personnalisées pour copier les données. Dans le présent article, je tente d'expliquer comment et dans quelles circonstances utiliser cette méthode.

Lire l'article

Réplication bidirectionnelle avec SQL Server 7.0

par Baya Pavliashvili
Les éditeurs convertis en abonnés et les abonnés convertis à  leur tour en éditeurs
Les fonctions avancées de réplication de SQL Server permettent de synchroniser les données de plusieurs bases de données, que celles-ci résident sur le même serveur ou non. Mais pourquoi pas simplement sauvegarder les bases de données et les restaurer ensuite sur un autre serveur, ou utiliser DTS (Data Transformation Services) pour transférer les tables et données ? Si on travaille sur des bases de données accessibles uniquement en lecture, ces techniques conviennent parfaitement. Mais qu'en est-il si on a une base de données transactionnelle (OLTP) de grande taille (100 Go ou plus) gérant une centaine de transactions ou plus par minute ? Ou alors, que faire si on a plus de 1.000 utilisateurs exécutant des instructions Select, Insert, Update et Delete au moins 8 heures par jour ? Dans ce contexte, effectuer des sauvegardes suivies de restaurations toutes les 10 minutes (ce qui aurait pour effet de verrouiller les tables et déclencher des appels d'utilisateurs irrités) est inacceptable. En outre, l'utilisation de DTS ou de bcp (bulk copy program) pour transférer autant d'informations à  chaque fois que l'on souhaite synchroniser des bases de données n'est pas viable ; le transfert nécessiterait beaucoup trop de temps.

Même si la réplication n'accélère pas le transfert des données, elle permet cependant, d'effectuer ce dernier d'un serveur à  un autre en une seule opération, puis de répercuter les modifications sur les autres bases de données. En d'autres termes, la réplication peut représenter la solution idéale pour transférer des données si on recherche un juste milieu entre la propagation des données sur différentes machines et la disponibilité de ces mêmes données.

SQL Server 7.0 passe à  la vitesse supérieure en matière de réplication et de facilité d'emploi

SQL Server 6.0 a apporté le support de la réplication, et SQL Server 6.5 a rajouté des améliorations mineures. Pour sa part, SQL Server 7.0 passe à  la vitesse supérieure en matière de réplication et de facilité d'emploi. En effet, SQL Server 7.0 va bien au delà  d'une photographie instantanée des données et de la réplication transactionnelle standard pour supporter la réplication bidirectionnelle (ou un abonnement avec mise à  jour instantanée) et la réplication par fusion. Cette version permet également de répliquer des données de et vers des plates-formes non SQL. De plus, SQL Server 7.0 automatise toutes les tâches de réplication, permettant ainsi aux administrateurs de configurer et d'administrer la réplication à  l'aide d'assistants, sans écrire une seule procédure cataloguée. A travers les assistants de réplication, il est même possible de paramétrer SQL Server de manière à  écrire des tâches de nettoyage et d'informer les administrateurs des éventuelles erreurs par courrier électronique ou pager. Passons en revue les assistants de SQL Server 7.0 en vue de configurer un exemple de solution de réplication avec mise à  jour immédiate. Examinons ensuite, l'action de SQL Server en coulisses pour implémenter cette solution et pour finir, testons la solution proposée.

Lire l'article

Indexer pour optimiser les performances des tris

par Dusan Petrovic et Christian Unterreitmeier
La définition d'index sur les colonnes de tri peut améliorer les performances de manière exceptionnelle
Un index approprié peut considérablement améliorer les performances de tri de SQL Server.
Par exemple, la définition d'un index clusterisé sur une colonne de tri contraint la base de données à  stocker les enregistrements sous forme triée, ce qui permet d'extraire les données sans avoir à  réaliser de tri supplémentaire. Vous noterez que SQL Server 7.0 et les versions antérieures permettent de créer des index uniquement en ordre croissant.
Par conséquent, si votre requête nécessite des données dans un ordre décroissant, il faudra certainement effectuer un tri supplémentaire et utiliser des tables de travail internes pour générer des données dans l'ordre approprié.
Cependant, SQL Server 2000 permet de créer des index aussi bien dans un ordre croissant que décroissant.

SQL Server 2000 permet de créer des index aussi bien dans un ordre croissant que décroissant.

SQL Server 7.0 effectue une opération de tri lorsqu'on utilise la clause ORDER BY. L'optimiseur de requêtes de SQL Server est également susceptible d'utiliser une opération de tri pour traiter une requête utilisant les clauses GROUP BY, DISTINCT ou UNION. En revanche, on peut utiliser l'indicateur d'index FAST pour éviter le tri des données.
Cela indique à  l'optimiseur de requêtes de SQL Server qu'il doit utiliser un index non clusterisé correspondant à  la clause ORDER BY, éliminant ainsi la nécessité du tri. Observons comment SQL Server gère les clauses GROUP BY, DISTINCT et UNION pour trier les données, puis analysons comment les différentes techniques d'indexation peuvent améliorer les performances des requêtes nécessitant des données triées.

Lire l'article

Windows 2000 et SQL Server

par Michael Otey
Cinquième version majeure du système d'exploitation Windows NT, Windows 2000 (W2K) comprend de nombreuses fonctions avancées lui permettant de concurrencer de très près les systèmes UNIX, dont la réputation n'est plus à  faire en termes de service de fichiers, d'applications et de bases de données sur le marché des entreprises. Les améliorations apportées à  W2K en matière de réseau et de facilité d'emploi, en font une meilleure plate-forme pour SQL Server que NT 4.0.

Lire l'article

XML et SQL Server 2000

par Paul Burke
Facilitez-vous le commerce électronique et l'interopérabilité grâce au standard Internet d'échange d'informations

Remarque : Les auteurs ont basé leurs articles SQL Server 2000 sur des versions antérieures à  la Bêta 2. Aussi, il se peut que vous remarquiez quelques différences entre la Bêta 2 et le comportement ou les interfaces décrits dans cet article. En particulier, veuillez noter que la fonction vues indexées ne sera disponible que dans SQL Server 2000 Enterprise Edition. Toutefois, on peut installer Entreprise Edition sur un serveur NT 4 ou Windows 2000 (W2K). On n'est pas obligé d'utiliser NT 4.0 Enterprise ou W2K Advanced Server.

L'une des fonctionnalités les plus attendues de SQL Server 2000, le support de XML, est également l'une des plus floues en termes de valeur pratique immédiate. Personne n'a échappé au battage médiatique concernant ce langage, qui constituerait une passerelle entre tous les langages, et presque tous les systèmes de gestion de bases de données relationnelles (SGBDR) affirment désormais prendre en charge XML. Mais où, quand et pourquoi utiliser XML ?

XML permet de publier des types de données indépendamment des plates-formes, facilitant ainsi l'interopérabilité et le commerce électronique

XML, un standard Internet d'échange d'informations, permet de publier des types de données indépendamment des plates-formes, facilitant ainsi l'interopérabilité et le commerce électronique. XML sépare également les données des informations de présentation à  l'intérieur des pages Web ; on dispose ainsi d'un moyen standard pour définir et échanger des données entre applications et bases de données. (L'encadré "XML, le standard à  la mode", décortique les avantages qu'il y a à  utiliser XML pour séparer les données de leur présentation).

En tant que langage de définition de pages, le principal intérêt de XML vient soit de l'acceptation générale d'un langage particulier, défini dans XML, soit de l'acceptation générale de XML et de la disponibilité des utilitaires, d'outils et de l'infrastructure permettant de prendre en charge son utilisation. Même si XML comporte plusieurs excellents langages définis (tels que BizTalk, DSML [Directory Services Markup Language], et SOAP [Simple Object Access Protocol]), ce n'est pas la panacée pour tout le monde, surtout si on travaille dans un environnement Microsoft pur et dur, et qu'on développe des applications Windows 32 bits. Pour le transfert de données via un LAN, les ensembles de résultats ADO représentent le choix évident. Cependant, à  l'heure de l'Internet, rares sont les entreprises qui travaillent en circuit fermé. Et même à  l'intérieur des entreprises, il n'est pas rare de trouver différents types de serveurs, plates-formes ou langages.

Bien que SQL Server 2000 soit la première version de SQL Server à  proposer le support de XML, la fonction de prévisualisation XML de Microsoft fonctionne avec les versions 7.0 et 6.5. (on peut télécharger cette fonction de prévisualisation depuis le site Web SQL Server de Microsoft, à  l'adresse suivante : http://msdn.microsoft.com/workshop/xml/articles/xmlsql/). On peut également intégrer le support de XML dans SQL Server 7.0, 6.x et 4.2 en créant des procédures cataloguées étendues et des procédures cataloguées standard, quoique les procédures cataloguées standard puissent faire baisser les performances pour des ensembles de données de grande taille et de structure complexe. En outre, certaines fonctionnalités de SQL Server 7.0, telles que la recherche documentaire sur texte intégral, permettent de stocker du code XML comme du texte. Quelles sont alors les fonctions qui rendent SQL Server 2000 officiellement compatible XML ?

En général, on peut demander deux sortes de XML à  une base de données : le XML statique, stocké dans la base de données, et le XML dynamique, généré par les données présentes dans la base de données. Même la première version d

Lire l'article

Comment tout savoir sur SQL Server 2000

La nouvelle version atteint de nouveaux sommets Remarque : Les auteurs ont basé leurs articles SQL Server 2000 sur des versions antérieures à  la Bêta 2. Aussi, il se peut que vous remarquiez quelques différences entre la Bêta 2 et le comportement ou les interfaces décrits dans cet article. En particulier, veuillez noter que la fonction vues indexées ne sera disponible que dans SQL Server 2000 Enterprise Edition. Toutefois, on peut installer Entreprise Edition sur un serveur NT 4 ou Windows 2000 (W2K). On n'est pas obligé d'utiliser NT 4.0 Enterprise ou W2K Advanced Server.

Imaginez que vous ayez la possibilité de construire la maison de vos rêves, dans laquelle vous projetez d'élever vos enfants au cours des 20 prochaines années. L'argent n'est pas un problème, mais vous voulez emménager le plus tôt possible.

Dans ce cas, vous allez être obligé de faire des concessions, et de choisir entre avoir une maison parfaitement aménagée avant d'y habiter et pouvoir y emménager le plus tôt possible. Vous allez passer du temps à  concevoir soigneusement les pièces principales de la maison, sachant que vous pourrez toujours terminer le sous-sol ou rajouter une grande terrasse après avoir emménagé. Comparons ce processus à  la construction de SQL Server.

Il y a plusieurs années, Microsoft a regroupé les meilleurs spécialistes de la conception des bases de données à  travers le monde (internes et externes à  Microsoft) et leur a demandé de bâtir la base de données de leurs rêves. Considérez SQL Server 7.0 comme le résultat fondamental de ces efforts. SQL Server 7.0 est une réécriture importante du code de base, mais les administrateurs de bases données et les développeurs ne pouvaient pas voir ni toucher beaucoup de ces améliorations. En effet, SQL Server 7.0 apporte une kyrielle de nouvelles fonctionnalités importantes (comme les services OLAP). Mais une grande partie du réingéneering du noyau se situe au niveau de la gestion des pages et de la mémoire. Pour la première fois en Octobre 1999, j'ai vu SQL Server 2000 lors de la conférence MVP (Most Valuable Professional) de Microsoft.
Les premiers séminaires couvraient l'architecture interne des moteurs relationnels et de la mémoire, et je suis reparti avec le sentiment très fort que SQL Server 2000 s'appuie sur les fondations de SQL Server 7.0 et y rajoute "la plomberie et l'électricité". A bien des égards, SQL Server 2000 ressemble à  ce sous-sol terminé, cette énorme terrasse et ce studio de projection personnel dont vous avez toujours rêvé.

Il peut désormais rivaliser d'égal à  égal avec n'importe quelle plate-forme de base de données concurrentes

Lire l'article

Améliorez les performances base de données avec l’assistant d’optimisation des index

par Itzik Ben-Gan
En utilisant des index appropriés, les requêtes deviennent plus performantes qu'elles ne l'ont jamais été Avez-vous créé des index optimisés pour votre base de données ? Avez-vous pensé à  utiliser les meilleurs index de tables clusterisés ? Avez-vous déterminé quels index peuvent améliorer les performances des requêtes ? Le choix du meilleur index clusterisé pour une table base de données principale constitue l'un des problèmes les plus ardus que rencontrent les administrateurs de bases de données.
Toutefois, le choix des meilleurs index non clusterisés n'est pas non plus très aisé. En effet, cela impose de prendre en considération la distribution statistique des données, les différentes techniques utilisées par l'optimiseur de requêtes pour concevoir un plan d'exécution efficace, ainsi que le nombre de sélections et de modifications effectuées par les utilisateurs sur la base de données pour ne pas créer d'index superflus.

Les développeurs SQL Server 7.0 disposent déjà  de SQL Profiler, un outil inestimable permettant de suivre les requêtes

Ne serait-il pas idéal de disposer d'un outil capable d'analyser les requêtes effectuées sur sa base de données et de recommander les index à  créer ? Et bien coup de chance. Les développeurs SQL Server 7.0 disposent déjà  de SQL Profiler, un outil inestimable permettant de suivre les requêtes effectuées sur une base de données. On peut enregistrer le résultat de Profiler dans un fichier, une table ou un script SQL. On peut ensuite analyser ce résultat à  l'aide d'un autre outil de SQL Server 7.0, l'assistant d'optimisation d'index ou Index Tuning Wizard (ITW), lequel recommande les index à  concevoir.

Pour s'assurer que l'ITW donne des indications efficaces, il faut assurer un suivi des requêtes pendant une période d'activité type sur le système (et non une période d'activité exceptionnellement intense ou faible ni une période où se produisent des activités exceptionnelles). Il faut également décider pendant combien de temps Profiler doit suivre les requêtes. On peut par exemple avoir une représentation caractéristique de l'activité du système, en ne faisant une trace avec Profiler que durant quelques heures. Ou alors, il faudra effectuer un suivi sur quelques jours ou plus pour capturer les variations d'activité en cours de journée ou sur plusieurs jours.

Lire l'article