Actu SQL sem 48

SSRS et MOSS 2007 : La puissance déployée – Partie 1

Dans « Intégration des informations : SSRS et MOSS 2007 » (https://www.itpro.fr, Club Abonnés), je présentais toute la richesse de l’environnement d’intégration des informations disponible avecMicrosoft Office SharePoint Server (MOSS) 2007 Enterprise Edition.
Après l’examen de l’architecture technique qui repousse encore les limites du reporting, l’article présentait les phases d’installation et de configuration des composants nécessaires à l’intégration de SSRS et de MOSS. La deuxième partie explique maintenant comment accomplir certaines tâches SSRS familières, notamment le déploiement, la configuration de la sécurité et la gestion des propriétés, dans le nouvel environnement MOSS.

Vous allez également apprendre à mettre en oeuvre les nouvelles fonctionnalités de reporting compatibles avec MOSS, par exemple le contrôle de versions, les workflow, les alertes et les stratégies de gestion des informations, mais aussi à utiliser les fonctions d’intégration des informations. En tirant parti de l’intégration de SSRS et de MOSS, non seulement les utilisateurs peuvent trouver, exploiter et partager plus facilement des informations dans toute l’entreprise, mais la gestion des rapports et les tâches d’implémentation de la sécurité s’en trouveront également simplifiées.

 

Une Programmation Efficace pour SQL Server 2005

Avant de commencer l'exécution d'une requête, d'un lot, d'une procédure stockée, d'un déclencheur, d'une instruction préparée ou d'une instruction SQL dynamique sur un SQL Server, le lot est compilé et un plan d’exécution est généré. Le plan est ensuite exécuté pour produire un effet ou des résultats.

Les plans compilés sont enregistrés dans une portion de la mémoire du serveur SQL nommée cache de plan. Le cache de plan est exploré en vue de réutilisations possibles. Si on réutilise un plan pour un lot, on peut éviter les coûts de compilation ou recompilation. Les plans sont mis en cache dans l'éventualité de leurs réutilisations. Si un plan n’est pas mis en cache, la probabilité qu’il soit réutilisé est nulle. Dans cet article, nous décrirons quelques bonnes pratiques de programmation pour l'utilisation efficace du cache de plan.

Actu SQL semaine 5

actu SQL Server semaine 47

SQL Server : les tendances pour 2008

Tels des Nostradamus de notre temps, les responsables informatiques et administrateurs SQL Server ont besoin de se projeter dans l’avenir pour garantir la pérennité à court et long termes des investissements d’aujourd’hui dans les technologies et les infrastructures.
L’année 2008 s’annonce riche en événements pour la communauté SQL Server. Nous avons donc pensé que quelques prédictions et pronostics, assortis des conseils avisés de quelques experts, vous aideront à choisir la meilleure route possible vers les dernières évolutions technologiques et les nouvelles versions de produits dignes d’intérêt.

La démocratisation de la performance de l’entreprise avec PerformancePoint Server 2007

Le système d’information est devenu depuis quelques années un point central pour la croissance des entreprises. Dans un premier temps ces systèmes ont permis de collecter et de traiter l’information tout en optimisant son stockage. Puis dans un second temps, grâce à l’évolution de la puissance des machines, de la capacité disques grandissante, ces données ont pu être croisées et agrégées à des fins analytiques.Nous voyons aujourd’hui fleurir de nombreux projets autour des problématiques « VLDB » (Very Large Data Base). Le traitement de données de masse n’est plus une barrière au grand bénéfice des projets axés sur la Business Intelligence.

Microsoft Web Plateform Installer

La firme de Redmond vient de sortir la version 1.0 de Microsoft Web Plateform Installer, un outil permettant d’installer et d’optimiser sa plateforme Web.

Ce petit logiciel permet d’installer et de mettre à jour  IIS, Visual Web Developer 2008 Express Edition, SQL Server 2008 Express Edition et le framework .NET.

Actu SQL Semaine 46

Actu SQL – semaine 3

Service Broker

Service Broker offre la possibilité de travailler en mode asynchrone avec une SQL Server en proposant un service de messagerie fiable entre les instances.

SQL Server : l’aide à  la migration – partie 2

Deuxième partie de l'article portant sur SSMA, un outil qui facilite SQL Server.

Actu SQL sem 45

SQL Assistant 4.0

SoftTree Technologies vient d’annoncer la sortie de SQL Assistant 4.0.

Ce nouveau produit permet de vérifier et d’améliorer la qualité et la précision du code grâce à des outils d’aide à la programmation.

Un accès sécurisé aux données des rapports

Dans les secteurs de la santé et de la finance, où les applications de base de données traitent fréquemment des informations confidentielles, le recours à l’authentification et au cryptage pour sécuriser l’accès aux données est devenu une pratique courante.
En effet, pour les entreprises soumises à des réglementations spécifiques telles que la loi américaine sur la portabilité et la responsabilité d’assurance médicale HIPAA (Health Insurance Portability and Accountability Act), la sécurisation des données des systèmes de reporting constitue une nécessité absolue. En revanche, dans de nombreux autres secteurs, la sécurité des systèmes de reporting et des bases de données auxquelles ils accèdent reste une priorité secondaire sur les listes de tâches des concepteurs et administrateurs de systèmes, en raison de sa complexité apparente.

Pourtant, ce type de travail n’a nul besoin d’être difficile, en particulier si vous utilisez SQL Server Reporting Services (SSRS) comme système de reporting. Fourni avec Windows Server 2003 ou Windows 2000. Voyons comment configurer SSRS afin de sécuriser l’accès à vos données.

Actu SQL semaine 2

Microsoft SQL Server 2008 RTM

Le générateur de rapports de Microsoft SQL Server 2008 est à présent disponible en version RTM. 

Sa nouvelle interface orientée « utilisateur final », affiche un look à la Office 2007.

SQL Server : l’aide à  la migration – partie 1

Cet article porte sur SSMA, un outil qui facilite SQL Server.

Ecriture d’un cube sous forme de script dans XMLA

Optimisation des bases de données MS SQL Server : les requêtes

En théorie, quelle que soit la façon d'écrire une requête, le SGBDR doit être capable de trouver le moyen le plus efficace de traiter la demande, grâce à l'optimiseur. Mais parce qu'il y a loin de la théorie à la pratique, différentes écritures et différents styles de résolution, alliés à la qualité de l'indexation peuvent donner des temps d'exécution très variés.
C'est pourquoi la maîtrise de la conception de requêtes est un des points clefs de la performance d'une base de données bien conçue. Voyons quels en sont les principes basiques.
Dans un cours que je donne aux Arts & Métiers, je montre comment une bonne indexation alliée à la qualité de l'écriture des requêtes, peut faire varier dans une proportion de plus de 300 le temps d'exécution d'une requête. Je commence l'exercice par une demande simple : écrire une requête SQL permettant de répondre à une question basique, mais en prenant soin d'exprimer différentes solutions, même les plus bizarres.

Outre la solution simpliste, certains y arrivent par une union, d'autres avec des sous requêtes, d'autres encore avec des jeux de CASE... L'exécution brute de toutes ces solutions, donne un coût d'exécution allant du simple au triple. La pose d'un premier index trivial ne donne rien, par manque de sélectivité. Après élimination de cette première tentative, la pose d'un nouvel index montre que les requêtes les plus coûteuses au départ deviennent les plus rapides, alors que celles qui étaient les moins coûteuses à l'origine n'ont rien gagné. Un nouvel essai d'indexation remet toutes les requêtes au même rang qu'au départ, chacune gagnant dans la même proportion et plus que l'indexation précédente.

Enfin, la dernière tentative d'indexation étant la bonne, toutes les requêtes bénéficient d'un gain important, mais certaines bien plus que d'autres. Le clou est enfoncé lorsque l'on choisit de dénormaliser avec une vue. Là, le gain devient gigantesque. Il est voisin de 13 000. Mais il ne prend pas en compte l'effort supplémentaire à faire pour les mises à jour (INSERT, UPDATE, DELETE...).

Cet exercice nous apprend trois choses :
• différentes écritures d'une même requête ne donneront pas forcément les mêmes performances, bien que dans l’absolu, ce devrait être le cas [1]
• rien ne sert de poser un index s'il ne sert pas la requête
• une même requête écrite de différentes manières ne bénéficiera pas des mêmes gains lorsque l’on pose un index J’ajouterai que tout ceci évolue en fonction de la volumétrie des données et des données mêmes !

Tant est si bien qu’il est difficile de trouver de prime abord ce qu’est l’écriture d’une bonne requête. Affirmons cependant qu’une bonne requête est une requête qui sait tirer partie du moteur de requête pour le forcer à calculer un plan de requête dont les étapes sont les plus courtes à traiter.

[1] En fait, nous croyons souvent et naïvement que certaines écritures de requêtes sont identiques. Mais nous oublions souvent l’influence du marqueur NULL, dont le comportement particulier dans différents prédicats oblige le moteur SQL à des constructions parfois fort différentes.