none
Autres points SQL Server 2005 RRS feed

  • Question

  • Bonjour Christian,

    Si cela ne vous ennuie pas, j'aimerais approfondir quelques petits points d'ombre:

    1) - Dans le cas d'une haute disponibilité, il est donc possible (si l'on ne souhaite pas s'équiper, au vrai sens du terme, d'un cluster) de passer par une structure plus souple. En l'occurence, il faut trois serveurs: le principal, la relève et le témoin. A nouveau les avis sont partagés sur ce fameux témoin:

    - Doit-on utiliser une machine identique (par rapport aux serveurs de production) et quelle(s) version(s) peuvent-être utilisées (standard, entreprise, express) et avec le même type de licence ?

    2) - Dans le cadre de la réplication, il est dit, pour le service SQL Agent qu'il faut qu'il soit intégré dans le groupe local "administrateurs" pour bénéficier des privilèges administratifs nécessaires pour les tâches de réplications. Il ne doit donc pas être démarré avec les comptes "local system" ou "network". Or, Microsoft souligne le fait qu'il est préférable d'utiliser un seul compte de service pour démarrer l'ensemble des services SQL Server 2005, ce qui revient à dire que le compte de service MSSQLServer 2005 et celui de l'agent sont tous les 2 membres du groupe Administrateurs local. N'est-ce pas un peu dangereux ?

    3) - Le service Broker est un gestionnaire de file d'attente, destiné certainement à remplacer l'ancêtre MSMQ. J'ai bien réussi à configurer les différentes étapes et les services, envoyer les messages et gérer les files d'attentes. Un petit doute: le DBA ou le développeur ne va passer son temps à regarder si les messages sont bon ou pas. Je suppose que c'est à l'application de prendre en charge cette surveillance et qu'il faut coder quelque part le bon échange entre applications.

    - Comment fait-on justement pour que les applications dialoguent correctement, le service Broker doit-il être pilote par les applications ou l'inverse ? par l'intermédiaire d'un WebService ?

    4) - Le CLR et le TSQL: j'ai interrogé quelques personnes sur le NET et les avis sont encore une fois très partagés sur l'utilité de passer sur le CLR ou pas. Comme vous travaillez dans une société sérieuse à la pointe de la technologie dans ce domaine, je préfère avoir votre opinion.

    Je comprends que le CLR et . NET facilite le travail du développeur, mais je pense que le développement VB, CSharp, ASPx au travers du CLR ne va s'appliquer que pour développer des procédures complexes, des fonctions de la "mort", des transformations pour lesquelles les scripts ne peuvent plus rien.

    A moins que je dise une bêtise, le CLR ne sera pas utilisé pour refaire un "select * from". Le TSQL, d'après certains, ne serait intéressant que pour manipuler du gros volume de données et les traditionnelles requêtes, ce qui laisse penser que le CLR et le code managé sera employé pour les faibles volumes de données.

    - Quand doit-on réellement employé le code managé et le CLR et/ou le TSQL ?

    5) - Il a été dit que les procédure stockées étendues (xp_) ne serait plus maintenues dans SQL 2005. Or, je m'aperçois avec satisfaction, qu'elles existent toujours (du moins certaines). Sont-elles toutes présentes comme dans la version 2000 ou perdues, voire transformées et comment faire pour avoir l'équivalence ... avec le CLR ??

    6) - Le SQL DMO a été remplacé par le SQL SMO. Peut-on simplement reprendre les scripts DMO pour les rendre compatibles avec SMO ou faut-il recommercer à 0 avec SMO ?

    Merci de m'avoir lu et d'avance merci pour votre aide

    Cordialement,

    Nonogad

    jeudi 24 août 2006 15:55

Réponses

  • Re-Bonjour

    1) Express possible comme dit dans l'autres post

    Au niveau des machines, la charge sur le serveur Witness est faible, donc un simple serveur avec un peu de mémoire et disque suffira (penser quand même à la redondance du matériel, RAID, etc.)

    2) Le compte LocalSystem est administrateur local de la machine, il possède même un peu plus de droits de que les admin, par contre si l'on part du principe qu'il vaut mieux dans le cadre d'une réplication un compte du domaine, ce n'est pas un très bon choix.
    Le compte NetworkService (tout comme LocalService) n'est pas administrateur local de la machine par défaut, je ne conseillerais pas de le rendre administrateur local, mais il est possible de lui attribuer des droits suffisant nécessaires à l'execution de l'Agent SQL.

    Personnellement j'applique une stratégie simple pour mes comptes de services, si l'on a une domaine :
    - MSSQLSERVER : Compte invité du domaine, configuré via Configuration Manager
    - SQL Server Agent : Compte invité du domaine, administrateur local du serveur, sysadmin pour la connexion au serveur SQL, configuré via Configuration Manager

    Le fait de passer par Configuration Manager donne les droits nécessaires aux comptes en local sur le serveur.
    Pour l'agent, le fait d'être administrateur local est recommandé, mais n'est pas obligatoire (sauf pour des serveur msx, etc.)

    Est il nécessaire d'utiliser le même compte pour les 2 j'en doute d'autant qu'effectivement les impératifs de sécurité, ne vont pas du tout dans ce sens là.

    3) J'ai aussi répondu un peu dans l'autre post

    A nouveau le service broker ne sert qu'à faire des choses spécifiques à la base de données, tel que lancer des traitements asynchrones entre serveurs ou sur le même serveur, choses quasi impossible jusqu'à présent.

    4) J'ai aussi répondu un peu dans l'autre post

    Effectivement le CLR n'est pas là pour remplacer le T-SQL, il sert surtout à étendre les fonctionnalités du moteur, quelques exemples de choses possibles :

    - Transformation XSLT
    - Connexion à un WebService
    - Exportation de données en fichier
    - Utilisation de calcul scientifiques
    - Agrégats sur des chaînes de caractères

    Cette listes n'est aucunement limitative...

    Attention par contre je ne parlerait pas de développement aspnet, étant donnée qu'ici le but est d'étendre le moteur SQL, et pas de faire des choses déjà possible ailleurs.

    5) Les procédures stockées étendues sont problématiques du fait qu'elle s'executent dans le contexte du serveur et donc engendrent des problèmes de sécurité et de fiabilité (surtout celle qui aurait été mals conçus). Elles peuvent entre autres arrêter l'execution du moteur, provoquer des problèmes de fuite mémoire, etc. Elles reposent sur une API disponible en C et C++ qui n'a plus été maintenue depuis SQL Server 7 (si je dis une bétise, merci de corriger), cependant il été clair qu'il était impossible de supprimer une telle fonctionnalité sans proposer une alternative, ce qui est le cas avec le CLR.

    Elles sont donc encore supportées, mais vont sans doute peu à peu disparaitrent au profis du CLR au d'autres fonctions natives du moteur.
    A noter que c'est le cas aussi d'autres fonctionnalités du moteur, tel que les tables systèmes peu à peu converties en vues ou fonctions systèmes et des commandes DBCC peu à peu transformées en commande SQL pures (et même standardisées ISO pour certaines) pour les plus utilisées.

    6) La passage de DMO à SMO est de 2 ordres, passer du modèle COM à .net, et changements pour supporter les fonctionnalités supportées dans SQL Server 2005.
    SMO fonctionnera sans problème avec SQL Server 2000 et 2005 (il supporte SQL Server 7 dans une moindre mesure). Tout comme DMO fonctionnera avec SQL Server 7 et 2000, mais posera problème avec 2005 à cause de notions tels que les schémas.
    Le modèle objet diffère et la technologie aussi (même si l'on peut faire du SMO sur une technologie COM et du DMO dans l'autre sens), je pense donc qu'une telle migration imposera une réécriture au moins partielle.

    Voilà, s'il reste des points obscure, n'hésitez pas.

    Cordialement,

    Christian Robert - Winwise
    http://blogs.developpeur.org/christian

    vendredi 25 août 2006 08:18