Validation du document

Transcription

1 DBA Intranet / Module de livraison de scripts SQL Version Date 24/02/2010 Rédacteur Statut Hervé FAUVET / Bruno GUEDJ N/A Validation du document Indiquer ici les relecteurs et valideurs du document : Relecture Date Remarques Validation Date Remarques Suivi des modifications Ce tableau permet de suivre l évolution du document : Version Date Nom Modifications /02/10 Hervé FAUVET Création document /04/10 Hervé FAUVET Ajout des règles d utilisation /07/10 HFA et BGU Ajout règles de parsing /06/11 BGU Ajout règles de rejet grant/revoke MSQ compte Windows /04/12 BGU Passage DBStation Intranet_SQL_delivery 1 / 16

2 Table des Matières 1. PRESENTATION UTILISATION DU MODULE REGLES D UTILISATION Règles de nommage des fichiers : Parsing de rejet : Parsing de rejet pour Sybase ASE Parsing de rejet pour Sybase IQ Parsing de rejet pour Oracle Parsing de rejet pour SQL Server Parsing de rejet pour MySQL Conseils sur l écriture et le formalisme des ordres SQL : Conseils pour Sybase ASE Conseils pour Sybase IQ Conseils pour Oracle Conseils pour SQL Server Conseils pour MySQL Règles liées à l'ouverture des livraisons à la MOE: Intranet_SQL_delivery 2 / 16

3 1. Présentation Ce document présente la procédure d utilisation du module SQL delivery de livraison de scripts SQL vers les bases de données. Ce module est accessible via une interface Intranet. Il propose aux équipes MOEs de livrer des scripts SQL sur un de leurs environnements SGBD hors Production. Chaque livraison constitue un lot de livraison, qui sera ensuite appliqué sur un environnement SGBD de qualification (en pré-production) et sur le SGBD de production. Les scripts des lots de livraison feront l'objet d'un parsing de rejet systématique lors du 1 er chargement via l'interface du module SQL delivery. Ce parsing détectera la présence de séquences de mots clés interdits strictement et conduisant à un blocage lors de la création du lot. Les scripts des lots de livraison feront ensuite l'objet d'un parsing sémantique des ordres SQL contenus, afin d'identifier si le lot pourra être livré uniquement par les DBAs ou par la MOE. Les ordres SQL autorisés à la MOE sont décrits plus précisément dans la section 3 de ce document. Avec cet outil, le schéma classique de livraison de scripts SQL vers les SGBD se déroulera donc comme suit : 1) DEVELOPPEMENT : L équipe MOE est propriétaire de sa base de données et peut y apporter tout changement. 2) RECETTE : Via l interface du module SQL delivery présentée l équipe MOE livre un ou plusieurs scripts SQL et les applique sur le SGBD de Recette. Chaque livraison constitue un lot indivisible. Un numéro de livraison sera généré pour le lot de scripts SQL appliqués et le lot fait l objet d un parsing qui définit s il pourra être appliqué, par les DBAs uniquement ou la MOE, lors des étapes suivantes. 3) PRE-PRODUCTION : L équipe MOE demande à l équipe DBA d appliquer le ou les numéros de livraison souhaités sur le SGBD de Pre-production (si le lot est marqué comme non exécutable par la MOE). Si le lot est défini comme exécutable par la MOE lors du parsing sémantique de l étape précédente, la MOE pourra appliquer librement la livraison via l interface du module SQL delivery. 4) PRODUCTION : L équipe MOE : o Demande à l équipe DBA (si le lot est marqué comme non exécutable par la MOE) d appliquer le ou les numéros de livraison souhaités sur le SGBD de Production. Intranet_SQL_delivery 3 / 16

4 o Livraisons de scripts SQL Déclare la mise en production et la réalise via l interface du module SQL delivery. L utilisation nécessite un navigateur WEB et que l on soit authentifié sur l intranet DBA (soit en utilisant un login nominatif soit en étant identifié sur l annuaire LDAP de l entreprise si configuré). Il est à noter que lors de la création des chemins de livraison, il est possible d intégrer l exécution de scripts pré et post livraison sur une étape donnée. Une demande devra être faite auprès des DBAs afin d exprimer précisément le besoin. (ex : création de synonyme publiques, grant..) Intranet_SQL_delivery 4 / 16

5 2. Utilisation du module Afin d utiliser le module, connectez-vous à l intranet DBA en ouvrant votre navigateur sur l URL correspondant à DBStation : Intranet_SQL_delivery 5 / 16

6 Cliquez ensuite dans le menu de gauche sur le lien «Modules» puis «SQL delivery» Vous arrivez sur cette page : Intranet_SQL_delivery 6 / 16

7 Afin de réaliser une livraison, cliquez sur le bouton «SQL delivery» puis sur «Request a delivery». Une nouvelle page apparait alors, vous proposant les applications et les chemins de livraisons auxquels vous avez droit. Un chemin correspond au circuit de livraison vers une base ou schéma applicatif. Vous pouvez voir les chemins et étapes de livraison pour lesquelles vous avez la permission de livrer des scripts SQL. La première étape permet la création d un lot de livraison. Un lot de livraison est un ou plusieurs scripts SQL à appliquer de façon groupée et indivisible. Après création d un lot de livraison sur votre 1 er environnement SGBD, un numéro unique lui est associé. Ce numéro unique permettra d identifier ce lot et de demander à l équipe DBA son application sur les autres environnements SGBDs de l application. L application sur les autres environnements SGBDs oblige au respect du chemin déclaré dans le circuit de livraison de l outil. Le bon pourra donc être appliqué en Production, seulement si appliqué auparavant en Pré- Production. De même, il pourra être appliqué en Pré-Production, seulement si appliqué auparavant en Recette. Intranet_SQL_delivery 7 / 16

8 La création d un lot de livraison se fait en cliquant sur la première étape du chemin. L écran suivant apparait alors. Vous pouvez charger ici votre ou vos scripts SQL et saisir un label à votre livraison. Intranet_SQL_delivery 8 / 16

9 En cliquant sur «Uploader», vous arrivez à l écran suivant : Cet écran permet de choisir l ordre d exécution des scripts SQL lors de la livraison. Cliquer sur «Validate order» pour passer à l écran suivant. ATTENTION, il se peut que, lors du parsing de rejet des scripts SQL, la livraison soit rejetée car ne respectant pas les règles définies en fin de ce document. Dans ce cas, aucun numéro de livraison n'est généré et les scripts concernés devront être modifiés par la MOE en vue d'une relivraison permettant la création du lot. Intranet_SQL_delivery 9 / 16

10 Cette page permet de choisir les date et horaires d exécution de la livraison en modifiant les deux champs à votre disposition. Une fois validé, le lancement aura lieu à l heure demandé (modulo le temps de cycle du spooler de job). A partir de là, vous pouvez suivre votre livraison en cliquant sur l icône dans «Delivery requests log». Vous y trouverez l option «abort», symbolisée par une bombe, vous permettant d interrompre votre demande avant son lancement. Cette option n est plus permise une fois la livraison lancée par le spooler. En cas de détection d ordres SQL non autorisés à la MOE au niveau de l étape de parsing sémantique sur l'un des fichiers au moins du lot, la livraison est marquée comme étant exécutable uniquement par les DBAs (message en rouge dans la copie d écran ci-dessous). Le temps d exécution global est également affiché pour information dans le cadre «Target informations». Intranet_SQL_delivery 10 / 16

11 Vous recevrez un mail à la fin de l exécution de la livraison précisant le statut de cette dernière (SUCCESS/ERROR/WARNING). Si la livraison contient du code exécutable uniquement par les DBAs, le log contenu dans le mail contiendra les portions de code correspondantes. En cas d échec dans la livraison (statut ERROR) : - la livraison pourra être soit corrigée / validée manuellement uniquement par l équipe DBA. - Une relivraison du (des) script(s) ayant généré les erreurs pourra être demandée par le demandeur vers l équipe DBA avant la validation finale du lot de livraison. ATTENTION : une livraison marquée en erreur ne pourra pas être appliquée sur les environnements SGBD suivants. L équipe DBA ou la MOE pourront assurer ensuite la livraison d un bon de livraison numéroté sur un environnement SGBD avant Production (en qualification/pré-production) et sur le SGBD de Production. La même interface sera utilisée pour réaliser ces livraisons en suivant les étapes suivantes. Intranet_SQL_delivery 11 / 16

12 Intranet_SQL_delivery 12 / 16 Livraisons de scripts SQL

13 En cliquant sur la deuxième étape du chemin, l écran suivant apparait. Il permet de choisir les livraisons disponibles pour l étape choisie. En cliquant sur la livraison désirée, l écran de choix de lancement apparait comme pour la création du lot de livraison. Il faut noter que les scripts d'un lot de livraison refont systématiquement l'objet du parsing sémantique à chaque étape de livraison et pour chaque exécution/réexécution du lot. Une modification du script à l'étape suivante pourra donc conduire le lot à être marqué comme exécutable uniquement par les DBAs. Intranet_SQL_delivery 13 / 16

14 3. Règles d utilisation L outil permet la livraison de scripts SQL sur les bases de données et ne gère en aucun cas le versionning, l historisation des scripts ou code SQL. Cette partie reste à la charge de l équipe de développement. L outil de livraison utilise les clients natifs disponibles sous UNIX afin de réaliser les livraisons : isql pour Sybase ASE, dbisql via jconnect pour Sybase IQ, sqlplus pour Oracle et freetds pour SQL Server (pas de client natif sous UNIX pour SQL Server). Une attention toute particulière sera portée au format des fichiers. En effet, certains logiciels utilise un format de fichier qu il est impossible de lire sous UNIX. Nous recommandons de ne pas mettre d accent dans le contenu des fichiers, afin d éviter les erreurs pouvant survenir avec les clients UNIX. Afin que l outil fonctionne correctement, quelques règles doivent être respectées : 3.1 Règles de nommage des fichiers : - fichier au format texte - ni accent, ni espace dans le nom des fichiers 3.2 Parsing de rejet : Les scripts feront l'objet lors du 1 er chargement d'un parsing défini comme suit et conduisant au blocage de création du lot de livraison : Parsing de rejet pour Sybase ASE - ne pas mettre de «use <base>» dans le fichier - ne pas mettre de «setuser <num_user>» dans le fichier - ne pas préciser le propriétaire des objets Parsing de rejet pour Sybase IQ - ne pas mettre de «setuser <num_user>» dans le fichier - ne pas préciser le propriétaire des objets Parsing de rejet pour Oracle - supprimer tout ordre «spool», «whenever sqlerror», «whenever oserror» - ne pas préciser le propriétaire des objets. Intranet_SQL_delivery 14 / 16

15 3.2.4 Parsing de rejet pour SQL Server - ne pas mettre de «use <base>» dans le fichier - ne pas préciser le propriétaire des objets - ne pas utiliser de grant/revoke en direct sur des comptes Windows sans passer par une exécution SQL dynamique encapsulée dans la fonction exec. Ex: grant select on [dbo].[tabname] to [Servername Domainname]\Username exec('grant select on [dbo].[tabname] to [Servername Domainname]\Username') Parsing de rejet pour MySQL - ne pas mettre de «use <base>» dans le fichier 3.3 Conseils sur l écriture et le formalisme des ordres SQL : Les règles suivantes de bonne pratique du codage devront être respectées : - un objet (création, modification) ou une transaction par fichier - mettre les doits associés aux objets nécessaires (grant et revoke) Certaines règles sont établies afin de faciliter la reprise en cas d échec. En effet, l outil s arrête quand un script est en erreur. La reprise se fait en recommençant la livraison à partir de ce script. La correction peut être apportée en contactant l équipe DBA qui pourra modifier le script dans la livraison et la relancer Conseils pour Sybase ASE - mettre un «go» à la fin de chaque instruction ou bloc Transact-SQL => le «go» doit être impérativement en début de ligne pour être interprété - utilisation de «if exists» lors de la création d objet Conseils pour Sybase IQ - mettre un «go» (Transact-SQL) ou «;» (watcom) à la fin de chaque instruction ou bloc => le «go» doit être impérativement en début de ligne pour être interprété - utilisation de «if exists» lors de la création d objet Conseils pour Oracle - Préciser le nom du tablespace lors de la création de segment (table, index, lob ) - mettre un «;» ou «/» après chaque instruction. Attention toutefois à ne pas cumuler les deux! - mettre un «/» à la fin des blocs PL/SQL - faire un bloc PL/SQL pour la suppression ou le test d'existence des objets Conseils pour SQL Server - mettre un «go» ou un «;» à la fin de chaque instruction ou bloc Transact-SQL Intranet_SQL_delivery 15 / 16

16 => le «go» doit être impérativement en début de ligne pour être interprété - utilisation de «if exists» lors de la création d objet. - pas d instruction DDL à l intérieur d une transaction (begin transaction) - pas d instruction «:ON ERROR EXIT» Conseils pour MySQL - mettre un «;» à la fin de chaque instruction ou bloc SQL 3.4 Règles liées à l'ouverture des livraisons à la MOE: Dans le cadre de l ouverture afin que la MOE puisse livrer jusqu en production sans la nécessité de passer par un DBA, les scripts feront l'objet d'un parsing sémantique après création du lot de livraison et à chaque exécution. Voici les règles supplémentaires à respecter (procedure, function, trigger, package, view, grant, revoke) pour bénéficier de cette fonctionnalité de l'outil : - écriture des ordres de DDL ( CREATE FUNCTION, CREATE PROCEDURE.) sur une seule ligne. Exemple : create procedure test -- important, sinon la livraison devra être faite par un DBA as begin insert.... end go - pas de DML dans les scripts hormis ceux contenu dans le code de l objet (procedure, trigger, function) - pour les grant et revoke, deux possibiltés : o ne mettre qu un seul droit à la fois. Exemple : grant select on tabletest to usertest o respecter les ordres suivants : Exemple : grant select, insert, update, delete on tabletest to usertest grant insert, update, delete on tabletest to usertest Intranet_SQL_delivery 16 / 16