Tous les actualités SQL Server de la semaine du 04 au 10 Juin 2007

La prochaine réunion du Groupe des Utilisateurs Francophones de SQL Server aura lieu le 7 juin 2007 au Centre de Séminaires Microsoft, rue de l’Université de 15h30 à 18h30. Au cours de cette réunion, plusieurs sujets seront abordés :–    SQL Server sur le terrain –    Les produits d’administration et d’optimisation IDERA pour SQL Server–    Analysis […]

Double-Take Reporting Center

Double-Take Software améliore sa solution Double-Take avec le nouveau Double-Take Reporting Center et la prise en charge étendue des applications SQL Server et Microsoft Exchange par sa console DTAM (Double-Take Application Manager).
 

Double-Take Reporting Center fournit aux administrateurs un environnement logique leur permettant de gérer les stratégies de protection des données selon cinq axes.

Requêtes récursives avec SQL SERVER 2005

Tout le monde à déjà eu affaire au moins une fois dans sa vie à la récursion. Lorsque j'étais enfant, mes parents et moi vivions dans un immeuble parisien ou figuraient dans le hall deux glaces se faisant face. Lorsque je passais entre ces deux miroirs, mon image se reflétait à l'infini et j'étais assez fier de palper le concept de récursion sur ma personne ! C'est cela la récursion : un processus capable de se reproduire aussi longtemps que nécessaire.Mais en termes "mécaniques" nous ne pouvons accepter une récursion infinie. Dans le monde réel, nous avons besoin que le processus s'arrête parce que notre monde apparaît fermé. Woody Alen, parlant de l'infini du temps, disait "l'éternité c'est long, surtout vers la fin..." !

En informatique la récursion est une technique particulière, capable dans certains cas de traiter avec élégance des problèmes complexes : quelques lignes suffisent à effectuer un travail parfois considérable. Mais la récursion induit certains effets pervers : les ressources pour effectuer le traitement sont maximisées par le fait que chaque appel réentrant du processus nécessite l'ouverture d'un environnement de travail complet ce qui possède un coût généralement très élevé en mémoire. Heureusement, un mathématicien dont je ne me rappelle plus le nom, a découvert que tout processus récursif pouvait s'écrire de manière itérative, à condition de disposer d'une "pile"

Mais notre propos est de parler de la récursivité dans le langage de requête SQL et en particulier de ce que fait SQL Server 2005 au regard de la norme SQL:1999.

Les outils de gestion de SQL SERVER 2005

SQL Server 2005 propose un ensemble entièrement nouveau d’outils de gestion pour les administrateurs de bases de données (DBA) et les développeurs. Avec l’ajout de certains services dans la version 2005, la gestion des services prend de l’importance pour les DBA. Le nouvel outil SQL Server Management Studio vient remplacer la console SQL Server 2000 Enterprise et l’Analyseur de requêtes (Query Analyzer). Il faut également s’intéresser à deux outils de gestion : SQL Server Configuration Manager et l’outil Surface Area Configuration. Cet article aborde dans un premier temps ces deux outils avant d’examiner plus avant SQL Server Management Studio.Il convient de noter que SQL Server 2005 est entré dans la dernière phase bêta avec une série de CTP (Community Technology Previews). Il s’agit en fait des versions bêta intermédiaires précédant immédiatement la version définitive et certains changements mineurs peuvent donc encore intervenir dans cette période. Les informations présentées dans cet article s’appuient sur la très complète CTP d’avril.

actualités SQL Server semaine 02

Alors que de nombreux éditeurs vantent les mérites de l’identification par empreintes digitales, la commission nationale de l’informatique et des libertés (la CNIL) vient de sortir un guide « d’usage » sur cette technologie. Le but de ce document destiné aux entreprises et aux employés, est « de rappeler les risques liés à cette technologie, […]

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 […]

Actualité SQL server magazine- sem51

Quest Software a annoncé le lancement d’un programme, de bêta test de LiteSpeed 5.0, son logiciel de sauvegarde et de restauration des bases SQL Server. Ce programme est ouvert aux sociétés clientes des solutions Quest Software ainsi qu’aux sociétés équipées de SQL Server, désirant y participer. Les nouvelles fonctions de LiteSpeed 5, seront mises en […]

L’extraction à  la volée

Analysis Services a modifié le regard des entreprises sur leurs données. Bien qu’OLAP existait assurément avant que Microsoft ne propose Analysis Services avec SQL Server, le géant de Redmond l’a mis à la portée des entreprises de toutes tailles.Celles-ci peuvent désormais analyser leurs données afin de prendre des décisions plus rapidement, à partir d’informations plus pertinentes. Analysis Services inclut une fonctionnalité appelée « extraction » (ou drillthrough en anglais) qui, une fois activée par les concepteurs de cubes, fournit à l’analyste un moyen d’exploration partant des données du cube pour aller jusque dans les tables relationnelles sous-jacentes. Cette approche permet d’examiner les enregistrements sur lesquels reposent les données visibles dans le cube. Par exemple, si l’enregistrement de cube indique qu’un client a acheté pour 10 000 dollars d’un produit spécifique, vous pouvez effectuer une extraction sur cet enregistrement afin de savoir si le client a passé une seule commande d’un montant de 10 000 dollars ou 10 000 commandes d’un dollar chacune.

L’extraction fonctionne bien dans la majorité des cas, mais elle présente un défaut. Vous ne pouvez pas modifier une requête d’extraction à la volée. Le créateur du cube configure la requête une seule fois pour le cube et celle-ci devient statique. Si vous devez passer des paramètres dans la requête d’extraction, vous ne pouvez pas employer Analysis Services seul. En revanche, vous pouvez créer un rapport d’extraction dans Reporting Services, puis utiliser une action au niveau cellule dans Analysis Services pour appeler le rapport et passer les paramètres appropriés. Cette option est particulièrement utile pour passer un niveau parmi plusieurs d’une dimension en tant que paramètre à une requête d’extraction, sans connaître à l’avance le niveau concerné. Un rapport d’extraction fonctionne également lorsque vous effectuez des comptages et si le champ sur lequel porte l’opération dans la table de faits peut contenir des valeurs NULL.

Créez votre propre bibliothèque de code

Les développeurs de base de données ADO.NET utilisent fréquemment les chaînes T-SQL afin de récupérer des données pour leurs applications. Si leur connaissance de la conception d’une base de données et/ou du langage T-SQL est insuffisante, le processus de création des chaînes pour leurs applications peut aboutir à des conceptions d’accès aux données inefficaces, voire à des ensembles de résultats présentant des valeurs erronées.Dans ce type de situation, la réutilisation du code T-SQL dans des objets de base de données tels que des procédures stockées et des fonctions définies par l’utilisateur (UDF) présente des avantages particuliers. Cette approche peut contribuer à simplifier la tâche d’accès aux données et sécuriser le schéma d’une base de données. Un développeur ou DBA confirmé peut préparer une bibliothèque de code T-SQL qui sera ensuite réutilisée par des développeurs débutants ou un peu aguerris pour de nombreuses tâches courantes d’accès aux données. Le développeur ou DBA peut en outre exiger que les applications client se connectent via des comptes de sécurité qui ont le droit d’appeler les procédures stockées et fonctions UDF de la bibliothèque, mais pas nécessairement les objets sous-jacents.

Dans cet article, nous allons étudier les techniques pour le traitement des procédures stockées et des fonctions UDF avec ADO.NET et Visual Basic .NET. Pour ce faire, nous allons utiliser deux exemples d’applications s’appuyant sur les tables Categories et Products de la base de données exemple Northwind. Vous pouvez réaliser une jointure entre ces deux tables sur les valeurs de la colonne CategoryID. Il est possible d’adapter les exemples de code présentés ici afin des les appliquer à toute paire de tables jointes sur une ou plusieurs paires de valeurs de colonne. Les exemples de code T-SQL sont également utiles à un autre titre : ils exposent les techniques pouvant servir à améliorer la réutilisabilité du code.

Ces techniques incluent l’utilisation de paramètres d’entrée, de paramètres de sortie et de valeurs d’état de retour avec des procédures stockées, ainsi que la mise en oeuvre de valeurs scalaires et de valeurs de type table retournées par les fonctions UDF. En apprenant ces techniques et en les appliquant dans vos applications, vous décuplerez la réutilisabilité du code T-SQL dans vos procédures stockées et fonctions UDF. (Vous pouvez cependant appliquer les techniques Visual Basic .NET présentées dans cet article avec n’importe quel langage .NET qui met en oeuvre la programmation ADO.NET, tel que C#).

CLR : un potentiel à  découvrir

Dans l’article « SQL Server : retour vers le futur » (www.itpro.fr), j’explique que les données sont au coeur de la majorité des systèmes informatiques modernes et que SQL Server 2005 va estomper les frontières traditionnelles du modèle d’applications multiniveaux. L’un des facteurs clé du changement de notre vision des niveaux d’une architecture informatique est l’inclusion du Common Language Runtime (CLR) dans SQL Server 2005.Cette fonctionnalité est l’une des plus commentées du nouveau produit et les avis positifs ou négatifs à son sujet sont très marqués, allant des utilisateurs qui souhaitent la désactiver ad vitam aeternam aux utilisateurs qui veulent l’employer à toutes les sauces. Les réactions à l’intégration du CLR dans SQL Server 2005 sont intéressantes. Alors qu’un membre de l’équipe de développement SQL Server effectuait une présentation sur l’intégration du CLR, une personne de l’assistance s’est levée et a crié « T-SQL est-il mort ? ». Cette question nous a incité à mettre en place une session spécifique intitulée « Non, T-SQL n’est pas mort ! ». A l’inverse, j’ai eu une conversation avec un programmeur ASP qui venait de découvrir l’intégration du CLR SQL Server et a déclaré d’emblée qu’il constituerait un emplacement remarquable pour stocker tous les assemblys .NET destinés à son site Web.

SSIS et la sécurité

Comme toutes les autres fonctionnalités présentes dans SQL Server 2005 Integration Services (SSIS), les nouveautés du produit touchant à la sécurité diffèrent sensiblement de leurs homologues dans DTS. SSIS continue d’employer des mots de passe et crypte les données sensibles, mais l’approche a profondément changé et se traduit par une simplification de l’exécution, de la protection, de la planification et de la modification des lots automatisés.Les fonctionnalités de sécurité de SSIS se répartissent en cinq catégories fonctionnelles : le cryptage, pour la sécurité des lots ou de parties d’entre eux ; la protection des données sensibles, pour l’identification et la protection des mots de passe et autres données critiques ; les rôles SQL Server, pour le contrôle de l’accès aux lots stockés dans SQL Server ; la signature numérique du code, pour garantir qu’un lot n’a pas changé ; et, enfin, l’intégration des sous-systèmes de l’Agent SQL Server, pour le stockage et l’exécution sécurisée des lots. Le présent article examine en détail ces nouvelles fonctionnalités de sécurité et propose des conseils sur les modalités et les circonstances de leur mise en oeuvre. A cette occasion, j’aimerais remercier tout spécialement Sergei Ivanov, le développeur de l’équipe Integration Services qui a écrit ces fonctionnalités, pour ses réponses à toutes mes questions et pour s’être assuré que je comprenais parfaitement les moindres détails.

Tous les actualités SQL Server de la semaine du 18 au 24 Juin 2007

Le prochain SQL Server connu sous le nom de Katmai est annoncé pour 2008 par Microsoft. Il est de plus disponible en CTP sur le site Connect de Microsoft : https://connect.microsoft.com/SQLServer . Les fonctionnalités seront ajoutées au fur et à mesure dans les CTP jusqu’à la sortie définitive prévue pour 2008. Plus d’informations sur Katmai

Nouveaux Produits SQL Server – Semaine 50 – 2006

Les nouveaux produits SQL Server de la semaine du 11 au 17 Décembre 2006.

Liste de contrôle CLR

par Gert Drapers. Mise en ligne: 30 Décembre 2006. Parution SQL Magazine : Juin 2005

Le Common Language Runtime (CLR) de SQL Server 2005 est une extension essentielle du modèle de programmation côté moteur du SGBD. Il vous permet d’étendre la fonctionnalité du moteur de base de données avec des fonctions scalaires, des fonctions de type table (TVF), des procédures, des déclencheurs, des agrégats et des types de données définis par l’utilisateur (UDT). Avant de commencer à employer le CLR, vous devez évaluer les raisons et les moyens d’utiliser les extensions basées sur le CLR dans SQL Server. Pour bien débuter, contrôlez les points suivants.

Liste de contrôle ADO.NET

par Michael Otey. Mise en ligne : 13 Décembre 2006. Publication SQL Magazine : Juin 2006

ADO.NET, le middleware pour l’accès aux bases de données, est au coeur de toute application de base de données .NET. Par conséquent, son utilisation appropriée constitue le facteur déterminant pour l’écriture d’applications de base de données hautement performantes. En contrôlant les huit points suivants, vous contribuerez à optimiser les performances de vos applications ADO.NET.

SQL Server Actualités – Semaine 48 – 2006

Les actualités SQL Server de la semaine du 27 Novembre au 3 Décembre 2006

Double-Take Application Manager

Double-Take Application Manager, qui supporte à la fois les environnements SQL Server et Exchange Server, gère la protection des applications à partir d’une interface d’administration centralisée, ce qui élève le degré d’automatisation et augmente la simplicité de configuration. 

La protection des données est ainsi améliorée, la reprise sur sinistre accélérée et le niveau de disponibilité des applications accru pour les utilisateurs de plates-formes Windows dont les systèmes critiques reposent sur SQL Server et Exchange Server.

Liste de contrôle T-SQL

par Itzik Ben-Gan. Mise en ligne : 29 Novembre 2006, Parution SQL Magazine : Juin 2005

T-SQL est le langage principal pour l’accès aux données côté serveur et la manipulation de celles-ci dans SQL Server. L’application des meilleures pratiques vous aidera à exploiter au mieux ses possibilités. En vous appuyant sur la liste de contrôle suivante, vous serez certain d’avoir un code T-SQL performant et convivial en termes de maintenance.- Utilisez des solutions basées sur des ensembles. Ce type de solution est généralement plus rapide, plus simple et moins longue que des solutions à base de curseur. Les solutions basées sur des ensembles permettent à l’optimiseur SQL Server d’évaluer plusieurs plans d’exécution et de choisir le plus performant au lieu d’imposer une approche particulière. Les curseurs nécessitent beaucoup de temps de traitement et il vaut donc mieux les éviter dans la mesure du possible. Les solutions itératives sont appropriées dans quelques cas et il est important de les identifier au lieu d’envisager d’emblée ce type d’approche.

- Ecrivez plusieurs solutions. Ne vous contentez pas de la première solution qui marche. Elaborez systématiquement plusieurs solutions, comparez leurs performances, leur simplicité et leur évolutivité, puis choisissez celle qui répond le mieux à vos besoins.

- Privilégiez le code conforme ANSI. Utilisez autant que possible du code conforme à la norme ANSI. L’écriture de code standard présente de nombreux avantages : elle facilite le portage, pas seulement entre plates-formes de base de données, mais aussi vers de futures versions de SQL Server. De même, la signification du code standard est claire, à la différence de certaines constructions propriétaires, telles que *= ou =* pour des jointures externes. Envisagez d’employer du code non standard uniquement lorsque T-SQL fait appel à une fonction propriétaire extrêmement avantageuse en termes de performances ou une fonctionnalité qui n’a pas d’alternative standard.

- Employez les procédures stockées. Privilégiez cette approche au lieu de mettre en oeuvre toute la logique dans l’application. Les procédures stockées permettent de partager la logique applicative et fournissent un procédé d’encapsulation, de sorte que vous pouvez réviser leur implémentation sans affecter l’application tant que l’interface de la procédure reste inchangée. Les procédures stockées constituent un très bon outil pour contrôler la sécurité et l’intégrité des données, pour réduire le trafic réseau en évitant de multiples allers et retours entre le client et le serveur, et pour réutiliser les plans d’exécution.

- Spécifiez des noms de colonne dans la liste SELECT de votre requête. Spécifiez systématiquement une liste de colonnes explicite ; évitez le symbole * dans la liste SELECT de vos requêtes et expressions de table (par ex. vues, tables dérivées, fonctions inline). En indiquant uniquement les noms des colonnes nécessaires, vous laissez à l’optimiseur le soin d’envisager des index de couverture. Et vous n’avez pas de souci à vous faire en cas de changement du schéma des objets sous-jacents.

- Ne supposez jamais qu’il existe un ordre physique des données. Une erreur courante commise par les programmeurs T-SQL débutants est de s’appuyer sur un certain ordre physique des données. Souvenez-vous que ce langage repose sur le modèle relationnel, lequel est à son tour basé sur la théorie des ensembles. Une table (ensemble) n’a pas d’ordre prédéterminé de ses lignes. Lorsque vous devez trier les donnée

Liste de contrôle des sauvegardes de journaux

par Kalen Delaney. Mise en ligne : 29 Novembre 2006, Parution SQL Magazine : Juin 2005

La sauvegarde de votre journal des transactions permet d’avoir un historique de tous les changements apportés à une base de données SQL Server, afin que vous puissiez restaurer cette dernière ultérieurement, si la situation l’exige. La liste suivante vous aidera à avoir en mémoire les fonctions clé des sauvegardes de journaux afin de les employer au mieux.- Utilisez le modèle de récupération complète ou journalisée en bloc. Si votre base de données applique le modèle de récupération simple, vous ne pouvez pas sauvegarder les journaux car SQL Server tronque votre journal régulièrement.

- Stockez votre journal des transactions sur un lecteur miroir. Même si vos fichiers de données sont endommagés et si la base de données est inutilisable, vous pouvez sauvegarder le journal des transactions si les fichiers journaux et le fichier de données principal sont disponibles. Utilisez un niveau RAID qui garantit la redondance, à savoir 1 ou 10, et vous serez en mesure de sauvegarder toutes les transactions jusqu’au point de défaillance, puis de les réappliquer vers la base de données restaurée.

 - Surveillez la taille du journal. Bien que la planification soigneuse de cette valeur soit vitale, ne partez pas du principe que la taille du journal n’excédera pas celle constatée pendant les tests. Utilisez les alertes de l’Agent SQL Server pour surveiller les compteurs de l’Analyseur de performances (Performance Monitor) servant à suivre la taille du fichier et dès que le journal franchit un seuil défini par vos soins, l’Agent SQL Server peut accomplir des actions prédéterminées telles que l’exécution d’un script d’augmentation de la taille du journal, l’envoi d’un e-mail à votre attention ou la réduction de la taille du fichier.

- Rappelez-vous que les sauvegardes de journal ne se chevauchent pas. Dans SQL Server 2000 et 7.0, chaque sauvegarde de journal contient toutes les transactions depuis la sauvegarde du journal précédente, de sorte qu’une transaction de longue durée peut s’étendre sur plusieurs sauvegardes. Par conséquent, lorsque vous restaurez des sauvegardes de journaux, n’utilisez pas l’option WITH RECOVER tant que vous n’avez pas appliqué le dernier journal. Des sauvegardes ultérieures peuvent contenir la suite de transactions présentes dans la sauvegarde de journal courante.

- Sachez faire la différence entre le terme « troncature » et « réduction de la taille ». La sauvegarde du journal exécute une opération de troncature, ce qui permet à des parties de celui-ci d’être disponibles pour être remplacées par de nouveaux enregistrements. Cela n’affecte pas la taille physique du fichier journal. Seule l’opération de réduction de la taille a une incidence sur celle-ci.

- Planifiez soigneusement la fréquence des sauvegardes de journal. Il n’existe pas de réponse standard et vous devrez systématiquement effectuer des compromis. Plus vos sauvegardes seront fréquentes, plus elles seront nombreuses à gérer et à restaurer, mais moins vous perdrez de transactions en cas de défaillance du système.

- La taille du journal ne reflète pas forcément la taille de la sauvegarde. Si votre base de données applique le modèle de récupération journalisée en bloc, les sauvegardes de journaux incluent toutes les données affectées par les opérations en bloc, de sorte que les sauvegardes en question peuvent représenter plusieurs fois la taille du fichier journal.

- Conservez des sauvegardes de jou

Actu SQL – Semaine 15 : Business Intelligence / EMC développe l’interopérabilité / Service Client Collaboratif

Les actualités SQL Server de la semaine du 09 au 15 Avril 2007

- Business Intelligence avec SQL Server 2005
- EMC développe l’interopérabilité et les possibilités de ses infrastructures pour la plate-forme Microsoft
- Service Client Collaboratif