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.
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.
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.
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.
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.
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.
