Introduction à l'administration de bases de données - 4.administrationbdpart21 (PDF)

I- Introduction à l'administration de bases de données I.1- Qu’est-ce qu’un administrateur de base de données (DBA) ? Un administrateur de base de données, souvent connu sous l'acronyme DBA (Data Base Administrator) est chargé de la création, la maintenance, l’optimisation et la sécurité des b...

I- Introduction à l'administration de bases de données I.1- Qu’est-ce qu’un administrateur de base de données (DBA) ? Un administrateur de base de données, souvent connu sous l'acronyme DBA (Data Base Administrator) est chargé de la création, la maintenance, l’optimisation et la sécurité des bases de données d'une organisation. Les administrateurs de bases de données travaillent dans différents types d'industries, y compris dans les entreprises de conception logicielles, notamment depuis l’essor du SAAS (Qu'est-ce qu'un SaaS ? Le Software as a Service, est un service basé sur le cloud où vous accédez à une application directement via un navigateur internet.) et des technologies de cloud computing et de services connexes, les compagnies d'assurance, les banques et les hôpitaux. Le DBA est un membre essentiel de l'équipe informatique. I.2- Quelles sont les compétences nécessaires pour devenir un bon administrateur de base de données Le poste exige une formation technique et une expertise dans le système de base de données utilisé par l'organisation. Il doit également posséder certaines compétences telles que :  Être capable de résoudre des problèmes et avoir de bonnes capacités d'analyse  Aptitudes à la communication, au travail d'équipe et à la négociation  Connaissance des principaux langages de manipulation de données et des principes de conception des bases de données  La capacité de travailler dans des délais serrés sous pression  Flexibilité et adaptabilité  La volonté de se tenir au courant de l'évolution des nouvelles technologies  Une compréhension de la législation en matière d'information, telle que la loi sur la protection des données. I.3- Les missions d’un administrateur de base de données Les administrateurs de bases de données, s'assurent que les différents collaborateurs peuvent facilement utiliser la base de données pour trouver les informations dont ils ont besoin et que le système fonctionne comme il se doit. Les administrateurs de bases de données collaborent parfois avec l'équipe de direction d'une organisation pour comprendre les besoins en données de l'entreprise et planifier les objectifs de la base de données. Les administrateurs de bases de données planifient souvent des mesures de sécurité, s'assurant que les données sont protégées contre tout accès non autorisé. De nombreuses bases de données contiennent des renseignements personnels ou financiers, ce qui place la sécurité de la base au cœur des enjeux de l’entreprise. Les administrateurs de bases de données sont responsables de la sauvegarde des systèmes en cas de panne de courant ou autre sinistre. Ils assurent également de l'intégrité de la base de données, garantissant que les données qui y sont stockées proviennent de sources fiables. Travailler avec des bases de données exige une compréhension des systèmes complexes, dans lesquels une erreur mineure peut causer des problèmes majeurs. Par exemple, si les renseignements de carte de crédit des clients sont mal organisés, cela peut avoir pour conséquence qu’une personne soit facturée pour un achat qu’elle n’a pas effectué. Les administrateurs de bases de données utilisent des logiciels pour donner un sens à l'information, l'organiser. L'information est ensuite stockée dans les bases de données que ces experts administrent, testent et maintiennent. En cas de problèmes avec une base de données, les administrateurs doivent être en mesure de les diagnostiquer et de les corriger. Complétez vos recherches avec ces sujets : Les technologies émergentes et l’automatisation imprègnent tous les aspects de notre travail et de notre vie d’aujourd’hui. La véritable opportunité de ces technologies, qui incluent l’intelligence artificielle (IA), le machine learning, l’Internet des Objets (IoT) et les interfacent humaines, est de nous permettre d’adopter l’innovation à une échelle jamais vue auparavant. Ces technologies nous aident à réimaginer ce qu’il est possible de faire au travail et dans la vie : des voitures à la médecine personnalisée à l’agriculture de précision et aux villes intelligentes qui changent notre façon de vivre notre monde. I.4- Tâches d'administration de base de données Les tâches d'administration de base de données relatives aux bases de données IMS sont répertoriées dans cette rubrique. Participation à des revues de design Les examens de la conception sont une série de réunions officielles auxquelles vous participez et au cours desquelles la conception et la mise en oeuvre de la base de données sont examinées. Les examens de la conception sont une tâche permanente lors de la conception et de la mise en oeuvre d'un système de base de données. Elles sont également conservées lorsque de nouvelles applications sont ajoutées à un système existant. Analyse des exigences en matière de données Une fois que les utilisateurs de votre installation ont identifié leurs exigences en matière de traitement des données, vous construisez des structures de données. Ces structures indiquent quelles données seront dans votre base de données et comment elles seront organisées. Cette tâche précède la conception réelle de la base de données. Conception de votre base de données Une fois les structures de données identifiées, l'étape suivante consiste à concevoir votre base de données. La conception de la base de données implique: Choix du mode d'organisation physique de vos données Choix des options de traitement IMS à utiliser Prise d'une série de décisions sur la conception qui déterminent les performances de votre base de données et l'utilisation de l'espace disponible Développement d'une base de données de test Avant que les applications qui utiliseront votre base de données ne passent à l'état de production, elles doivent être testées. Selon la forme de vos données existantes, vous pouvez utiliser une ou plusieurs aides à la conception de base de données IMS pour concevoir, créer, charger et tester votre base de données de test. Implémentation de la conception de votre base de données Une fois votre base de données conçue, implémentez la conception en décrivant à IMS les caractéristiques de la base de données et la manière dont les programmes d'application utiliseront la base de données. Si votre système IMS est activé pour gérer les blocs de contrôle d'application à l'aide du catalogue, vous pouvez utiliser IMS Enterprise Suite Explorer for Development pour émettre des instructions SQL qui décrivent les bases de données et la façon dont les applications les utilisent. Toutefois, si votre système IMS utilise une bibliothèque ACB, cette tâche consiste à coder des descriptions de base de données (DBD) et des blocs de spécification de programme (PSB), qui sont tous deux une série de macro- instructions. Une autre partie de l'implémentation de la conception de la base de données consiste à déterminer s'il faut prégénérer des blocs de contrôle d'application (ACB) de la base de données ou générer les ACB de manière dynamique. Chargement de votre base de données Une fois les caractéristiques de la base de données définies, écrivez un programme de chargement initial pour placer vos données dans la base de données. Une fois que vous avez chargé la base de données, des programmes d'application peuvent être exécutés sur celle-ci. Surveillance de votre base de données Lorsque la base de données est en cours d'exécution, surveillez régulièrement ses performances. Divers outils permettant de surveiller le système IMS sont disponibles. Optimisation de votre base de données Optimisez votre base de données lorsque les performances sont dégradées ou que l'utilisation du stockage externe n'est pas optimale. La surveillance de routine vous aide à déterminer à quel moment le système doit être optimisé et quel type d'optimisation doit être effectué. A l'instar de la surveillance, la tâche d'optimisation de la base de données est en cours. Modification de votre base de données Au fur et à mesure que de nouvelles applications sont développées ou que les besoins de vos utilisateurs changent, vous devrez peut-être apporter des modifications à votre base de données. Par exemple, vous pouvez modifier l'organisation de la base de données, les hiérarchies de la base de données (ou les segments et les zones qu'elle contient) et vous pouvez ajouter ou supprimer une ou plusieurs partitions. A l'instar de la surveillance et de l'optimisation, la tâche de modification de la base de données est en cours. Récupération de votre base de données La récupération de base de données implique la restauration d'une base de données dans sa condition d'origine après qu'elle a été rendue non valide par un incident. La tâche de développement des procédures de reprise et d'exécution de la reprise est importante. Toutefois, comme il est difficile de séparer la récupération des données de la récupération du système, la tâche de récupération est traitée séparément dans IMS version 15.3 Operations and Automation. Vous pouvez utiliser le contrôle de récupération de base de données (DBRC) pour prendre en charge la récupération de vos bases de données. Si vos bases de données sont enregistrées dans le fichier RECON, DBRC prend le contrôle lors de l'exécution de ces utilitaires IMS : Vous devez vous assurer que toutes les reprises de base de données utilisent les utilitaires IMS en cours, plutôt que ceux des éditions précédentes. Un IMS (IP Multimedia Subsystem) est une architecture permettant de fournir des services de communication de nouvelle génération sur l'IP (Internet Protocol). Il permet de créer, de contrôler et de modifier des applications indépendamment du réseau ou de la plateforme sur lesquels elles fonctionnent. Etablissement de la sécurité Vous pouvez empêcher des personnes non autorisées d'accéder aux données de votre base de données à l'aide de blocs de communication de programme (PCB). Avec les PCB, vous pouvez contrôler la quantité de base de données qu'un  utilisateur donné peut voir et ce qu'il peut faire avec ces données. En outre, vous pouvez prendre des mesures pour empêcher les programmes non IMS d'accéder à votre base de données. Mise en place de normes et de procédures Il est important d'établir des normes et des procédures pour le développement des applications et des bases de données. Cela est particulièrement vrai dans un environnement comportant plusieurs applications. Si vous avez des instructions et des normes, vous gagnez du temps dans le développement d'application et évitez les problèmes ultérieurs tels que les conventions de dénomination incohérentes ou les normes de programmation. I.5- Concepts et terminologie des bases de données Cette rubrique décrit les termes et concepts que vous devez comprendre pour effectuer des tâches d'administration de base de données IMS. Pour comprendre cette rubrique, vous devez savoir ce qu'est un appel DL/I et comment le coder. Vous devez comprendre les codes de fonction et les arguments de recherche de segment (SSA) dans les appels DL/I et savoir ce que signifie lorsqu'un appel est qualifié ou non qualifié (expliqué dans IMS Version 15.3 Application Programming). I.5.1- Mode de stockage des données dans une base de données Les données d'une base de données sont regroupées dans une série d' enregistrements de base de données. Chaque enregistrement de base de données est composé de groupes de données plus petits appelés segments. Un segment est le plus petit élément de données que IMS peut stocker. Les segments, à leur tour, sont constitués d'une ou de plusieurs zones. La figure suivante montre un enregistrement dans une base de données de l'école. Chacune des cases correspond à un segment ou à un groupe distinct de données dans l'enregistrement de la base de données. Les segments de l'enregistrement de base de données contiennent les informations suivantes: COURSE Nom du cours INSTR Le nom de l'enseignant du cours REPORT Un rapport sur les besoins de l'enseignant à la fin du cours étudiant Les noms des étudiants dans le cours Catégorie La note qu'un étudiant a reçue dans le cours Espace La salle dans laquelle le cours est enseigné Figure : Types de segment dans l'enregistrement de base de données de l'école Les segments d'un enregistrement de base de données existent dans une hiérarchie. Une hiérarchie est l'ordre dans lequel les segments sont organisés. L'ordre implique quelque chose. La base de données de l'école stocke des données sur les cours qui sont donnés. Le segment COURSE se trouve en haut de la hiérarchie. Les autres types de données dans les segments de l'enregistrement de la base de données ne seraient pas utiles s'il n'y avait pas de COURSE.  Segment racine Un seul segment racine existe dans un enregistrement de base de données. Tous les autres segments de l'enregistrement de base de données sont appelés s egments dépendants. Dans l'exemple présenté dans Comment les données sont stockées dans une base de données, le segment COURSE est le segment racine. Les segments INSTR, REPORT, ÉTUDE, GRADE et PLACE sont les segments dépendants. L'existence de segments dépendants dépend de l'existence d'un segment racine. Par exemple, sans le segment racine COURSE, il n'y aurait aucune raison d'avoir un segment PLACE indiquant dans quelle salle le cours a eu lieu. Le troisième niveau de segments dépendants, REPORT et GRADE, est soumis à l'existence de segments de second niveau INSTR et ÉTUDE. Par exemple, sans le segment de deuxième niveau ÉTUDE, il n'y aurait aucune raison d'avoir un segment GRADE indiquant la note que l'étudiant a reçue dans le cours.  Segment parent et enfant Un autre ensemble de mots utilisé pour faire référence à la façon dont les segments sont liés les uns aux autres dans une hiérarchie est le segment parent et le segment enfant. Un segment parent est un segment qui a un segment dépendant en dessous dans la hiérarchie. Dans la figure illustrée dans Comment les données sont stockées dans une base de données, COURSE est le parent de INSTR et INSTR est le parent de REPORT. Un segment enfant est un segment dépendant d'un autre segment situé au-dessus de lui dans la hiérarchie. REPORT est l'enfant de INSTR et INSTR est l'enfant de COURSE. Notez que INSTR est à la fois un segment parent dans sa relation avec REPORT et un segment enfant dans sa relation avec COURSE.  Type de segment et occurrence Les termes type de segment et occurrence de segment font la distinction entre un type de segment dans la base de données et une instance de segment spécifique. Cela contraste avec les termes racine, dépendant, parent et enfant, qui décrivent la relation entre les segments. La base de données indiquée dans Comment les données sont stockées dans une base de données est en fait la conception de la base de données. Il affiche les types de segment de la base de données. Relation entre les segments affiche l'enregistrement de base de données réel avec les occurrences de segment. Une occurrence de segment est un segment spécifique unique. Les mathématiques sont une occurrence unique du type de segment COURSE. Baker et Coe sont des occurrences multiples du type de segment ÉTUDE.  Relation entre les segments Un terme final pour décrire les segments est twin segment. Le jumeau (racine, dépendant, parent et enfant) décrit une relation entre les segments. Les segments jumeaux sont des occurrences multiples du même type de segment sous un parent unique. Dans la figure suivante, les segments Baker et Coe sont des jumeaux. Ils ont le même parent (Math) et sont du même type de segment (ÉTUDE). Pass et Inc ne sont pas des jumeaux. Bien que Pass et Inc soient du même type de segment (GRADE), ils n'ont pas le même parent. Pass est le segment enfant de Baker, et Inc est le segment enfant de Coe. Figure : Segmenter les occurrences dans un enregistrement de base de données d'école La rubrique suivante décrit la hiérarchie plus en détail. Les rubriques suivantes décrivent les objets d'une base de données, leur composition et les règles régissant leur existence et leur utilisation. Ces objets sont les suivants :  Enregistrement de la base de données  Segments d'un enregistrement de base de données  Les zones d'un segment  Hiérarchie dans un enregistrement de base de données Une base de données est composée d'une série d'enregistrements de base de données. Les enregistrements contiennent des segments et les segments sont organisés dans une hiérarchie dans l'enregistrement de base de données.  Séquence de numérotation dans une hiérarchie: de haut en bas Lorsqu'un enregistrement de base de données est stocké dans la base de données, l'organisation hiérarchique des segments dans l'enregistrement de base de données est l'ordre dans lequel les segments sont stockés. En commençant par le haut d'un enregistrement de base de données (au niveau du segment racine), les segments sont stockés dans la base de données dans l'ordre indiqué par les numéros de la figure suivante. La séquence va du haut de la hiérarchie au bas du premier chemin (le plus à gauche) ou de la branche de la hiérarchie. Lorsque le bas de la base de données est atteint, la séquence est de gauche à droite. Lorsque tous les segments ont été stockés dans ce chemin de la hiérarchie, le séquencement commence dans le chemin suivant vers la droite, en allant de haut en bas puis de gauche à droite. (Dans la deuxième partie de la hiérarchie, il n'y a rien à aller à droite.) La séquence dans laquelle les segments sont stockés est généralement appelée “de haut en bas, de gauche à droite.” La figure suivante illustre le séquencement des types de segment pour la base de données scolaire présentée dans la rubrique Comment les données sont stockées dans une base de données. La séquence des types de segment est stockée dans l'ordre suivant: 1. COURSE (de haut en bas) 2. INSTR 3. REPORT 4. ÉTUDE (de gauche à droite) 5. GRADE (de haut en bas) 6. PLACE (de gauche à droite) Figure 1 : Séquence hiérarchique des types de segment pour une base de données d'école La figure suivante montre les occurrences de segment pour l'enregistrement de la base de données de l'école, comme indiqué dans Relation entre les segments. E tant donné qu'il existe plusieurs occurrences de types de segment, les segments sont lus "de l'avant vers l'arrière" en plus de "du haut vers le bas, de la gauche vers la droite". Les occurrences de segment de la base de données de l'école sont stockées dans l'ordre suivant : 1. Mathématiques (de haut en bas) 2. James 3. ReportA 4. ReportB (avant à arrière) 5. Baker (de gauche à droite) 6. Passer (de haut en bas) 7. Coe (avant à arrière) 8. Inc (de haut en bas) 9. Room2 (de gauche à droite) Figure 2. Séquence hiérarchique des occurrences de segment pour la base de données de l'école Notez que la séquence de numérotation est toujours initialement de haut en bas. En bas de la hiérarchie, cependant, observez qu'il y a deux occurrences du segment REPORT. Etant donné que vous êtes en bas de la hiérarchie, les deux occurrences de segment sont sélectionnées avant que vous ne vous déplaciez vers la droite dans ce chemin de la hiérarchie. Les deux rapports concernent le segment d'instructeur James ; par conséquent, il est logique de les conserver ensemble dans la base de données. Dans le deuxième chemin de la hiérarchie, il y a également deux occurrences de segment dans le segment étudiant. Vous n'êtes pas en bas du chemin hiérarchique tant que vous n'avez pas atteint le passage du segment de cotation. Par conséquent, le séquencement n'est pas “interrompu” par les deux occurrences des segments d'étudiants Baker et Coe. Cela a un sens parce que vous maintenez l'étudiant et la classe Baker et Pass ensemble. Veuillez noter que la note de l'élève Coe n'est pas considérée comme une autre occurrence de Baker. Coe et Inc deviennent un chemin distinct dans la hiérarchie. Ce n'est que lorsque vous atteignez le bas d'un chemin hiérarchique que le séquencement “de haut en bas, de gauche à droite” est interrompu pour prendre en compte plusieurs occurrences de segment. Vous pouvez faire référence à l'organisation dans la hiérarchie “de haut en bas, de face en arrière, de gauche à droite”, mais “de face en arrière” ne se produit qu'en bas de la hiérarchie. Plusieurs occurrences d'un segment à n'importe quel autre niveau sont séquencées en tant que chemins distincts dans la hiérarchie. Comme noté précédemment, cette numérotation des segments représente la séquence dans laquelle les segments sont stockés dans la base de données. Si un programme d'application demande tous les segments d'un enregistrement de base de données dans une séquence hiérarchique ou émet des appels Get- Next (GN), il s'agit de l'ordre dans lequel les segments sont présentés au programme d'application. Séquence de numérotation dans une hiérarchie: mouvement et position Les termes mouvement et position sont utilisés pour parler de la façon dont les segments sont accessibles lorsqu'un programme d'application émet un appel. Ils sont utilisés pour décrire la séquence de numérotation dans une hiérarchie. Lorsqu'on parle de mouvement à travers la hiérarchie, cela signifie toujours se déplacer dans la séquence impliquée par le schéma de numérotation. Le mouvement peut être vers l'avant ou vers l'arrière. Lorsqu'il s'agit de la position dans la hiérarchie, cela signifie qu'elle est située (positionnée) sur un segment spécifique. Un segment est le plus petit élément de données que IMS peut stocker. Si un programme d'application émet un appel Get-Unique (GU) pour le segment étudiant BAKER (voir Figure ), la position actuelle est immédiatement après l'occurrence du segment BAKER. Si un programme d'application émet ensuite un appel GN non qualifié, IMS avance dans la base de données et renvoie l'occurrence de segment PASS. Types de bases de données IMS IMS permet de définir de nombreux types de base de données différents. Vous définissez le type de base de données qui correspond le mieux aux exigences de traitement de votre application. Vous devez savoir que chaque base de données IMS possède sa propre méthode d'accès, car IMS s'exécute sous le contrôle du système d'exploitation z/OS®. Le système d'exploitation ne sait pas ce qu'est un segment car il traite les enregistrements logiques et non les segments. Les méthodes d'accès IMS manipulent donc les segments dans un enregistrement de base de données. Lorsqu'un enregistrement logique doit être lu, les méthodes d'accès au système d'exploitation (ou IMS) sont utilisées. Le tableau suivant répertorie les types de base de données IMS que vous pouvez définir, les méthodes d'accès IMS qu'ils utilisent et les méthodes d'accès au système d'exploitation que vous pouvez utiliser avec eux. Bien que chaque type de base de données varie légèrement dans sa méthode d'accès, ils utilisent tous des enregistrements de base de données. IMS ou méthodes d'accès au Type de base de Nom complet du type système d'exploitation pouvant données IMS de base de données être utilisées Base de données DEDB 1 Base de données DEDB gestionnaire de supports Méthode d'accès GSAM QSAM/BSAM ou VSAM séquentiel généralisé méthode d"accès direct Méthode d'accès direct VSAM ou OSAM hiérarchique hiérarchique méthode d"accès direct Méthode d'accès direct VSAM ou OSAM indexé hiérarchique indexé hiérarchique Méthode d'accès MOIS séquentiel indexé VSAM hiérarchique méthode d"accès Méthode d'accès BSAM ou QSAM séquentiel hiérarchique séquentiel hiérarchique Base de données de la Base de données de la N/A mémoire principale 2 mémoire principale Méthode d'accès direct PHDAM VSAM ou OSAM hiérarchique partitionné Méthode d'accès direct PHIDAM indexé hiérarchique VSAM ou OSAM partitionné index secondaire Index secondaire VSAM partitionné partitionné méthode d"accès Méthode d'accès séquentiel hiérarchique séquentiel hiérarchique BSAM ou QSAM simple simple méthode d"accès Méthode d'accès séquentiel indexé séquentiel indexé VSAM hiérarchique simple hiérarchique simple Tableau. Types de bases de données IMS et leurs z/OS Remarques sur le tableau:  1. Pour DBCTL, disponible uniquement pour les BMP 2. Non applicable à DBCTL Les bases de données répertoriées dans le tableau ci-dessus sont divisées en deux catégories: les types de base de données Full-Function et les types de base de données Fast Path. La base de données DEDB et la base de données de la mémoire principale sont les deux seuls types de base de données Fast Path. Toutes les autres bases de données du tableau ci-dessus sont considérées comme des types de base de données à fonction complète. I.5.2- Enregistrement de la base de données Une base de données se compose d'une série d'enregistrements de base de données et un enregistrement de base de données se compose d'une série de segments. Une autre chose à comprendre est qu'une base de données spécifique ne peut contenir qu'un seul type d'enregistrement de base de données. Dans la base de données de l'école, par exemple, vous pouvez placer autant d'enregistrements scolaires que vous le souhaitez. Cependant, vous n'avez pas pu créer un autre type d'enregistrement de base de données, tel que l'enregistrement de base de données médicale illustré dans la figure suivante, et le placer dans la base de données de l'école. Figure 1 : Exemple d'enregistrement de base de données médicale La seule autre chose à comprendre est qu'un enregistrement de base de données spécifique, lorsqu'il est stocké dans la base de données, n'a pas besoin de contenir tous les types de segment que vous avez initialement conçus. Pour exister dans une base de données, un enregistrement de base de données ne doit contenir qu'une occurrence du segment racine. Dans la base de données de l'école, les quatre enregistrements indiqués dans la figure suivante peuvent être stockés. Figure. Exemple d'enregistrements pouvant être stockés dans la base de données de l'école Toutefois, aucun segment ne peut être stocké à moins que son parent ne soit également stocké. Par exemple, vous ne pouvez pas stocker les enregistrements présentés dans la figure suivante. Figure 3 Enregistrements qui ne peuvent pas être stockés dans la base de données de l'école Les occurrences de l'un des types de segment peuvent ensuite être ajoutées ou supprimées de la base de données. Le segment Un enregistrement de base de données se compose d'un ou de plusieurs segments et le segment est le plus petit élément de données qu' IMS peut stocker. Voici quelques faits supplémentaires que vous devez connaître sur les segments:  Un enregistrement de base de données peut contenir jusqu'à 255 types de segment. L'espace que vous allouez à la base de données limite le nombre d'occurrences de segment.  Vous déterminez la longueur d'un segment ; toutefois, un segment ne peut pas être supérieur à la longueur d'enregistrement physique de l'unité sur laquelle il est stocké.  La longueur des segments est spécifiée par type de segment. Un type de segment peut être variable ou de longueur fixe. Les segments se composent de deux parties (un préfixe et les données), sauf lors de l'utilisation d'une base de données SHSAM ou SHISAM. Dans les bases de données SHSAM et SHISAM, le segment se compose uniquement des données. Dans une base de données GSAM, les segments n'existent pas. La figure suivante illustre le format d'un segment de longueur fixe. Figure : Format des segments de longueur fixe La figure suivante illustre le format d'un segment de longueur variable. Figure. Format des segments de longueur variable IMS utilise la partie préfixe du segment pour “gérer” le segment. La partie préfixe d'un segment comprend le code de segment, l'octet de suppression et, dans certaines bases de données, un pointeur et une zone de compteur. Les programmes d'application ne “voient” pas la partie préfixe d'un segment. La partie données d'un segment contient vos données, organisées en une ou plusieurs zones. Code segment IMS a besoin d'un moyen d'identifier chaque type de segment stocké dans une base de données. Il utilise la zone de code de segment à cette fin. Lors du chargement d'un type de segment, IMS lui affecte un identificateur unique (entier compris entre 1 et 255). IMS affecte des numéros dans l'ordre croissant, en commençant par le type de segment racine (numéro 1) et en passant par tous les types de segment dépendants dans l'ordre hiérarchique. Supprimer l'octet Lorsqu'un programme d'application supprime un segment d'une base de données, l'espace qu'il occupe peut ou non être immédiatement disponible pour être réutilisé. Lorsqu'un programme d'application supprime un segment d'une base de données, l'espace qu'il occupe peut ou non être immédiatement disponible pour être réutilisé. La suppression d'un segment est décrite dans les discussions sur les différents types de base de données. Pour l'instant, sachez que IMS utilise cet octet de préfixe pour suivre le statut d'un segment supprimé. Zone de pointeur et de compteur La zone de pointeur et de compteur existe dans les bases de données HDAM, PHDAM, HIDAM et PHIDAM et, dans certains cas particuliers, dans les bases de données HISAM. La zone de pointeur et de compteur peut contenir deux types d'informations:  Les informations de pointeur sont constituées d'une ou plusieurs adresses de segments vers lesquels pointe un segment.  Les informations de compteur sont utilisées lorsque des relations logiques, fonction facultative d'IMS, sont définies. La longueur de la zone de pointeur et de compteur dépend du nombre d'adresses qu'un segment contient et de l'utilisation ou non des relations logiques. Partie de données La partie données d'un segment contient un ou plusieurs éléments de données. Les données sont traitées et contrairement à la partie préfixe du segment, vue par un programme d'application. Le programme d'application accède aux segments d'une base de données en utilisant le nom du type de segment. Si un programme d'application doit référencer une partie d'un segment, un nom de zone peut être défini dans IMS pour cette partie du segment. Les noms de zone sont utilisés dans les arguments de recherche de segment (SSA) pour qualifier les appels. Un programme d'application peut voir des données même si vous ne les définissez pas en tant que zone. Mais un programme d'application ne peut pas qualifier un SSA sur les données à moins qu'il ne soit défini en tant que zone. Le nombre maximal de zones pouvant être définies pour une base de données est 1000. Notez que 1000 fait référence à des types de zones dans une base de données, et non à des occurrences. Le nombre d'occurrences des zones dans une base de données est limité uniquement par la quantité de stockage que vous avez définie pour votre base de données. Les trois types de zone de la portion de données Vous pouvez définir trois types de zone dans la partie données d'un segment: une zone de séquence, des zones de données et, pour les segments de longueur variable, une zone de taille indiquant la longueur du segment. Les deux premiers types de zone contiennent vos données et un programme d'application peut utiliser les deux pour qualifier ses appels. Cependant, la zone de séquence a d'autres utilisations que celle de contenir vos données. Vous pouvez utiliser une zone de séquence, souvent appelée clé, pour conserver les occurrences d'un type de segment dans la séquence de clés sous un parent donné. Par exemple, dans l'enregistrement de base de données illustré dans la figure suivante, il existe trois occurrences de segment du segment ÉTUDE, et le segment ÉTUDE comporte trois éléments de données. Figure : Trois occurrences de segment et trois éléments de données du segment ÉTUDE Supposons que vous ayez besoin que le segment ÉTUDE, lorsqu'il est stocké dans la base de données, soit dans l'ordre alphabétique par nom d'étudiant. Si vous définissez une zone dans les données NAME en tant que zone de séquence unique , IMS stocke les occurrences des segments de l'étude par ordre alphabétique. La figure suivante montre trois occurrences du segment ÉTUDE par ordre alphabétique. Figure. Exemple de segments ÉTUDE stockés dans l'ordre alphabétique Lorsque vous définissez une zone de séquence dans un segment racine d'une base de données HISAM, HDAM, PHDAM, HIDAM ou PHIDAM, un programme d'application peut l'utiliser pour accéder à un segment racine spécifique, et donc à un enregistrement de base de données spécifique. En utilisant une zone de séquence, un programme d'application n'a pas besoin de rechercher la base de données de manière séquentielle pour trouver un enregistrement de base de données spécifique, mais peut extraire les enregistrements de manière séquentielle (pour les bases de données HISAM, HIDAM et PHIDAM). Vous pouvez également utiliser une zone de séquence d'une autre manière lors de l'utilisation des fonctions facultatives IMS des relations logiques ou de l'indexation secondaire. Les informations importantes à connaître sur les zones de séquence sont les suivantes :  Il n'est pas toujours nécessaire de définir une zone de séquence. Ces informations décrivent les cas où une zone de séquence est nécessaire.  La valeur de la zone de séquence peut être définie comme unique ou non unique.  Les données ou la valeur de la zone de séquence sont appelées “clé” du segment. I.5.6- Transaction En informatique, et particulièrement dans les bases de données, une transaction, telle qu'une réservation, un achat ou un paiement, est mise en œuvre via une suite d'opérations qui font passer la base de données d'un état A — antérieur à la transaction — à un état B postérieur 1 et des mécanismes.. Une transaction en SQL est une séquence d’opérations exécutées sous la forme d’une seule unité logique de travail. Ces opérations peuvent inclure la lecture, l’écriture, la mise à jour ou la suppression de données. Les transactions garantissent l’intégrité et la cohérence des données en adhérant aux propriétés ACID : atomicité, cohérence, isolation et durabilité. Principes clés 1. Atomicité : Garantit que toutes les opérations d’une transaction sont menées à bien. En cas d’échec d’une opération, l’intégralité de la transaction est annulée et aucune modification n’est apportée à la base de données. 2. Cohérence : garantit qu’une transaction fera passer la base de données d’un état valide à un autre, en conservant toutes les règles prédéfinies, telles que les contraintes et les déclencheurs. 3. Isolation : garantit que les transactions sont isolées les unes des autres, ce qui empêche les transactions simultanées d’interférer les unes avec les autres. 4. Pérennité : Une fois qu’une transaction est validée, ses modifications sont permanentes, même en cas de défaillance du système12. I.5.7- Journalisation Qu’est-ce que la journalisation ? C’est l’enregistrement dans des « fichiers journaux » ou (« logs ») des activités des utilisateurs, des anomalies et des événements liés à la sécurité. C’est un élément primordial pour assurer la sécurité des traitements, obligation posée à l’article 5 du RGPD. Article 5: Principes relatifs au traitement des données à caractère personnel - RGPD.COM (ref https://rgpd.com/fr/apercu/chapitre-2-principes/article-5-principes- relatifs-au-traitement-des-donnees-a-caractere-personnel/). II- Gestion des utilisateurs et des permissions Afin d'augmenter la sécurité de la base de données, il peut être très intéressant de mettre en place une gestion des mots de passe comme le nombre maximal de tentatives de connexion à la base, le temps de verrouillage d'un compte, etc.Il peut parfois aussi être intéressant de limiter les ressources système allouées à un utilisateur afin d'éviter une surcharge inutile du serveur. Oracle nous propose une solution efficace et pratique pour mettre en place ce type d'action : les PROFILS. I. Un PROFIL est un ensemble de limitations système. Une fois qu'un PROFIL a été assigné à un utilisateur, celui-ci ne pourra plus dépasser les limitations imposées. La première chose à vérifier et de savoir si vous disposez du privilège système CREATE PROFILE. Si c'est le cas, il va falloir décider quelles limitations vous souhaitez mettre en place. Vous avez deux types de limitations :  les limitations du mot de passe ;  les limitations des ressources système. II.1- Les limitations système II.1.1- Les limitations du mot de passe Les limitations liées au mot de passe vous offrent un certain nombre d'options très intéressantes vous permettant d'augmenter la sécurité de vos mots de passe. Voici la liste des différentes options disponibles : Option Description Ce paramètre permet de définir le nombre maximal de tentatives de connexion. Si le nombre de connexions donné par le paramètre FAILED_LOGIN_ATTEMPTS FAILED_LOGIN_ATTEMPTS est atteint le compte sera alors verrouillé pendant une période donnée par le paramètre PASSWORD_LOCK_TIME. Ce paramètre permet de définir la durée d'utilisation du même mot de passe. Ce paramètre devra être PASSWORD_LIFE_TIME défini en jours. Une fois la date limite d'utilisation, Oracle demandera alors automatiquement à l'utilisateur de bien vouloir changer son mot de passe. Ce paramètre défini en nombre de jours permet de définir le délai entre deux utilisations du même mot de passe. Par exemple si celui-ci vaut 30 et que votre mot de passe actuel est toto. Il vous faudra attendre 30 jours à compter de la date de votre changement de PASSWORD_REUSE_TIME mot de passe avant de pouvoir à nouveau utiliser toto comme mot de passe. Si vous donnez une valeur numérique au paramètre PASSWORD_REUSE_TIME vous devrez alors donner la valeur UNLIMITED au paramètre PASSWORD_REUSE_MAX. PASSWORD_REUSE_MAX Ce paramètre permet de définir le nombre de  réutilisations du même mot de passe (consécutive ou non). Si vous donnez une valeur numérique au paramètre PASSWORD_REUSE_MAX vous devrez alors donner la valeur UNLIMITED au paramètre PASSWORD_REUSE_TIME. Ce paramètre permettra de définir la durée de verrouillage du compte utilisateur après avoir bloqué le compte avec le paramètre FAILED_LOGIN_ATTEMPTS. Le compte sera alors automatiquement déverrouillé lorsque le temps défini par ce paramètre sera atteint. Ce paramètre sera PASSWORD_LOCK_TIME défini en jours (vous pouvez aussi spécifier un nombre de minutes ou heure, par exemple 30 minutes donnera 30/1440) ou pourra avoir la valeur UNLIMITED (pour un verrouillage définitif et donc une action d'un administrateur pour débloquer le compte). Ce paramètre permet de définir en jours le temps de grâce qui vous sera alloué pour changer votre mot de passe. Par exemple vous avez défini le paramètre PASSWORD_LIFE_TIME à 30 ce qui signifie que l'utilisateur devra changer son mot de passe tout les 30 jours. Cependant si celui-ci décide pour une raison ou une autre de ne pas changer son mot de passe à la PASSWORD_GRACE_TIME fin de cette période Oracle bloquera son compte automatiquement au bout de trois demandes. L'intérêt de ce paramètre est d'ajouter une période de grâce pendant laquelle l'utilisateur sera en mesure de ne pas changer son mot de passe. Cela revient à donner un délai supplémentaire à l'utilisateur pour changer son mot de passe. PASSWORD_VERIFY_FUNCTION Ce paramètre devra contenir le nom d'une fonction PL/SQL qui servira à vérifier les mots de passe saisis. Vous pouvez utiliser celle fournie par Oracle (script utlpwdmg.sql). La fonction fournie en argument devra avoir cette définition : (username varchar2, password varchar2, old_password varchar2) RETURN boolean  Si vous ne souhaitez pas utiliser de fonction de vérification, utilisez la valeur NULL. Attention  Si le paramètre PASSWORD_REUSE_TIME a été initialisé avec une valeur numérique, alors le paramètre PASSWORD_REUSE_MAX devra être à UNLIMITED et inversement.  Si les deux paramètres PASSWORD_REUSE_TIME et PASSWORD_REUSE_MAX possèdent la valeur UNLIMITED, alors Oracle n'utilisera aucune de ces deux limitations de mot de passe.  Si le paramètre PASSWORD_REUSE_MAX possède la valeur DEFAULT et que le paramètre PASSWORD_REUSE_TIME est à UNLIMITED, alors Oracle utilisera le paramètre PASSWORD_REUSE_MAX avec la valeur définie dans le profil par défaut.  Si le paramètre PASSWORD_REUSE_TIME est à DEFAULT et PASSWORD_REUSE_MAX est à UNLIMITED, alors Oracle utilisera le paramètre PASSWORD_REUSE_TIME avec la valeur définie dans le profil DEFAULT.  Si les deux paramètres PASSWORD_REUSE_TIME et PASSWORD_REUSE_MAX sont à DEFAULT, alors Oracle utilisera les valeurs définies dans le profil DEFAULT. La valeur DEFAULT est une valeur particulière, lorsque vous assignerez la valeur DEFAULT à une limitation alors Oracle ira récupérer la valeur de la limitation dans le profil DEFAULT. II.1.2- Les limitations des ressources système Afin de mettre en place les limitations système vous allez devoir mettre le paramètre RESOURCE_LIMIT à true, car Oracle va devoir générer des statistiques supplémentaires afin de pouvoir utiliser les valeurs des limitations. Voici la liste des limitations que vous pourrez mettre en place. Option Description Ce paramètre va vous permettre de définir le nombre de SESSIONS_PER_USER sessions maximum qu'un utilisateur pourra ouvrir. CPU_PER_SESSION Ce paramètre va vous permettre de définir le temps de processeur maximum en centièmes de secondes qu'une  session pourra utiliser. Ce paramètre va vous permettre de définir le temps de processeur maximum en centièmes de secondes qu'un CPU_PER_CALL « appel serveur » pourra utiliser. On appellera « appel serveur » un passage de requête, une exécution de requête ou la récupération d'une requête (FETCH). Ce paramètre va vous permettre de définir le temps en minutes pour la durée de connexion maximale d'une CONNECT_TIME session. À la fin du temps imparti, la session sera automatiquement déconnectée. Ce paramètre va vous permettre de définir le temps en minutes pour la durée d'inactivité maximale d'une session. IDLE_TIME À la fin du temps imparti, la session sera automatiquement déconnectée. Ce paramètre va vous permettre de définir le nombre LOGICAL_READS_PER_SESSION maximal de blocs lus durant une session. On parlera ici des blocs lus sur le disque et dans la mémoire. Ce paramètre va vous permettre de définir le nombre LOGICAL_READS_PER_CALL maximal de blocs lus durant un « appel serveur ». On parlera ici des blocs lus sur le disque et dans la mémoire. Ce paramètre va vous permettre de définir le coût total des limitations autorisées pour une session. Oracle calcule le coût total de toutes les ressources à partir du poids attribué aux paramètres CPU_PER_SESSION, COMPOSITE LIMIT CONNECT_TIME,LOGICAL_READS_PER_SESSION, et PRIVATE_SGA. Vous pourrez changer le poids associé à chaque limitation système avec la commande ALTER RESOURCE COST. Ce paramètre va vous permettre de définir la taille en PRIVATE_SGA Kbytes ou MBytes que pourra utiliser une session. I-B. Mise en place d'un La méthode pour mettre en place est très simple :  établir les limitations de mot de passe et les limitations système ;  créer le profil ;   attribuer le profil aux utilisateurs qui devront être limités. La syntaxe de création d'un profil est très simple. Voici un exemple : CREATE PROFILE app_user LIMIT SESSIONS_PER_USER UNLIMITED CPU_PER_SESSION UNLIMITED CPU_PER_CALL 3000 CONNECT_TIME 45 LOGICAL_READS_PER_SESSION DEFAULT LOGICAL_READS_PER_CALL 1000 PRIVATE_SGA 15K COMPOSITE_LIMIT 5000000; Il est tout à fait possible de combiner les deux types de limitations. Par défaut un utilisateur se voit assigner le profil DEFAULT lors de sa création. Si vous souhaitez lui assigner un nouveau profil, cela sera possible soit lors de la création soit avec la commande ALTER USER. ALTER USER scott PROFILE app_user; I-C. Syntaxe complète de l'ordre CREATE PROFILE Voici la syntaxe complète d'un ordre CREATE PROFILE : Voici la description de l'ensemble resource_parameters : Voici la description de l'ensemble password_parameters : Voici l'explication des quelques nouveaux mots clés: profile : nom du futur profil ; UNLIMITED : valeur infinie pour la limitation ; DEFAULT : la valeur de la limitation sera alors issue du même paramètre dans le profil DEFAULT ; Integer : valeur numérique pour la limitation. Avant de pouvoir modifier des limitations de ressources système, vous devez disposer du privilège système ALTER PROFILE et vous devrez disposer des privilèges ALTER PROFILE et ALTER USER pour modifier des limitations de mot de passe. Ensuite il faut savoir que si vous modifiez une limitation les autres limitations en cours ne seront pas modifiées. Une fois la limitation modifiée seules les nouvelles sessions se verront assigner cette nouvelle limitation. La syntaxe en elle-même est quasiment identique à la syntaxe de CREATE PROFILE. Attention : Vous ne pouvez pas retirer une limitation du profil DEFAULT, vous pourrez juste la faire passer à la valeur UNLIMITED. Voici un exemple de modification d'un profil : ALTER PROFILE app_user LIMIT FAILED_LOGIN_ATTEMPTS 5 PASSWORD_LOCK_TIME 1; Dans cet exemple nous avons changé le nombre de tentatives de connexion ratées avant que le compte de l'utilisateur ne soit verrouillé. Nous avons aussi modifié la durée de blocage du compte qui passe maintenant à un jour. Voici la syntaxe complète d'un ordre ALTER PROFILE : Voici la description de l'ensemble resource_parameters : Voici la description de l'ensemble password_parameters : Voici l'explication des quelques nouveaux mots clés profile : nom du profil à modifier ; UNLIMITED : valeur infinie pour la limitation ; DEFAULT : la valeur de la limitation sera alors issue du même paramètre dans le profil DEFAULT ; integer : valeur numérique pour la limitation. Pour supprimer un profil vous devez disposer du privilège DROP PROFILE. Il existe deux cas de figure possibles. Le premier cas le plus simple consiste à supprimer un profil qui n'a été assigné à personne. Vous pourrez donc le supprimer sans action supplémentaire. Cependant si ce profil a été assigné à un utilisateur vous devrez alors utiliser l'option CASCADE qui demandera à Oracle de supprimer le profil et d'assigner le profil DEFAULT à tous les utilisateurs qui possédaient le profil qui vient d'être supprimé. Par exemple : DROP PROFILE app_user CASCADE; Ici tous les utilisateurs qui disposaient du profil app_user se verront automatiquement assigner le profil DEFAULT. Attention : Vous ne pourrez pas supprimer le profil DEFAULT. Voici la syntaxe complète d'un ordre DROP PROFILE : Voici l'explication des quelques nouveaux mots clés : profile : nom du profil à supprimer ; CASCADE : cette option vous permettra de supprimer le profil à tous les utilisateurs qui disposaient de ce profil et demandera au serveur de leur assigner le profil DEFAULT. II.2- limitation des commande SQL ( Role-Based Access Control in SQL : RBAC) GRANT statement Use the GRANT statement to give privileges to a specific user or role, or to all users, to perform actions on database objects. You can also use the GRANT statement to grant a role to a user, to PUBLIC, or to another role. The following types of privileges can be granted:  Delete data from a specific table.  Insert data into a specific table.  Create a foreign key reference to the named table or to a subset of columns from a table.  Select data from a table, view, or a subset of columns in a table.  Create a trigger on a table.  Update data in a table or in a subset of columns in a table.  Run a specified function or procedure.  Use a sequence generator or a user-defined type. GRANT statement, You can grant privileges on an object if you are the owner of the object or the database owner. See the CREATE statement for the database object that you want to grant privileges on for more information. The syntax that you use for the GRANT statement depends on whether you are granting privileges to a schema object or granting a role. For more information on using the GRANT statement, see "Using SQL standard authorization" in the Java DB Developer's Guide. Syntax for tables GRANT privilege-type ON [TABLE] { table-Name | view-Name } TO grantees Syntax for routines GRANT EXECUTE ON { FUNCTION | PROCEDURE } routine-designator TO grantees Syntax for sequence generators GRANT USAGE ON SEQUENCE [ schemaName. ] SQL92Identifier TO grantees In order to use a sequence generator, you must have the USAGE privilege on it. This privilege can be granted to users and to roles. See CREATE SEQUENCE statement for more information. The sequence name is composed of an optional schemaName and a SQL92Identifier. If a schemaName is not provided, the current schema is the default schema. If a qualified sequence name is specified, the schema name cannot begin with SYS. Syntax for user-defined types GRANT USAGE ON TYPE [ schemaName. ] SQL92Identifier TO grantees In order to use a user-defined type, you must have the USAGE privilege on it. This privilege can be granted to users and to roles. See CREATE TYPE statement for more information. The type name is composed of an optional schemaName and a SQL92Identifier. If a schemaName is not provided, the current schema is the default schema. If a qualified type name is specified, the schema name cannot begin with SYS. Syntax for roles GRANT roleName [ {, roleName }* ] TO grantees Before you can grant a role to a user or to another role, you must create the role using the CREATE ROLE statement. Only the database owner can grant a role. A role A contains another role B if role B is granted to role A, or is contained in a role C granted to role A. Privileges granted to a contained role are inherited by the containing roles. So the set of privileges identified by role A is the union of the privileges granted to role A and the privileges granted to any contained roles of role A. privilege-types ALL PRIVILEGES | privilege-list privilege-list table-privilege {, table-privilege }* table-privilege DELETE | INSERT | REFERENCES [column list] | SELECT [column list] | TRIGGER | UPDATE [column list] column list  ( column-identifier {, column-identifier}* ) Use the ALL PRIVILEGES privilege type to grant all of the privileges to the user or role for the specified table. You can also grant one or more table privileges by specifying a privilege-list. Use the DELETE privilege type to grant permission to delete rows from the specified table. Use the INSERT privilege type to grant permission to insert rows into the specified table. Use the REFERENCES privilege type to grant permission to create a foreign key reference to the specified table. If a column list is specified with the REFERENCES privilege, the permission is valid on only the foreign key reference to the specified columns. Use the SELECT privilege type to grant permission to perform SELECT statements or SelectExpressions on a table or view. If a column list is specified with the SELECT privilege, the permission is valid on only those columns. If no column list is specified, then the privilege is valid on all of the columns in the table. For queries that do not select a specific column from the tables involved in a SELECT statement or SelectExpression (for example, queries that use COUNT(*)), the user must have at least one column-level SELECT privilege or table-level SELECT privilege. Use the TRIGGER privilege type to grant permission to create a trigger on the specified table. Use the UPDATE privilege type to grant permission to use the UPDATE statement on the specified table. If a column list is specified, the permission applies only to the specified columns. To update a row using a statement that includes a WHERE clause, you must have the SELECT privilege on the columns in the row that you want to update. grantees { AuthorizationIdentifier | roleName | PUBLIC } [, { AuthorizationIdentifier | roleName | PUBLIC } ] * You can grant privileges or roles to specific users or roles or to all users. Use the keyword PUBLIC to specify all users. When PUBLIC is specified, the privileges or roles affect all current and future users. The privileges granted to PUBLIC and to individual users or roles are independent privileges. For example, a SELECT privilege on table t is granted to both PUBLIC and to the authorization ID harry. The SELECT privilege is later revoked from the authorization ID harry, but Harry can access the table t through the PUBLIC privilege. Either the object owner or the database owner can grant privileges to a user or to a role. Only the database owner can grant a role to a user or to another role. routine-designator { function-name | procedure-name } Examples To grant the SELECT privilege on table t to the authorization IDs maria and harry, use the following syntax: GRANT SELECT ON TABLE t TO maria,harry To grant the UPDATE and TRIGGER privileges on table t to the authorization IDs anita and zhi, use the following syntax: GRANT UPDATE, TRIGGER ON TABLE t TO anita,zhi To grant the SELECT privilege on table s.v to all users, use the following syntax: GRANT SELECT ON TABLE s.v to PUBLIC To grant the EXECUTE privilege on procedure p to the authorization ID george, use the following syntax: GRANT EXECUTE ON PROCEDURE p TO george To grant the role purchases_reader_role to the authorization IDs george and maria, use the following syntax: GRANT purchases_reader_role TO george,maria To grant the SELECT privilege on table t to the role purchases_reader_role, use the following syntax: GRANT SELECT ON TABLE t TO purchases_reader_role To grant the USAGE privilege on the sequence generator order_id to the role sales_role, use the following syntax: GRANT USAGE ON SEQUENCE order_id TO sales_role; To grant the USAGE privilege on the user-defined type price to the role finance_role, use the following syntax: GRANT USAGE ON TYPE price TO finance_role; REVOKE statement Use the REVOKE statement to remove privileges from a specific user or role, or from all users, to perform actions on database objects. You can also use the REVOKE statement to revoke a role from a user, from PUBLIC, or from another role. The following types of privileges can be revoked:  Delete data from a specific table.  Insert data into a specific table.  Create a foreign key reference to the named table or to a subset of columns from a table.  Select data from a table, view, or a subset of columns in a table.  Create a trigger on a table.  Update data in a table or in a subset of columns in a table.  Run a specified routine (function or procedure).  Use a sequence generator or a user-defined type. The derby.database.sqlAuthorization property must be set to true before you can use the GRANT statement or the REVOKE statement. The derby.database.sqlAuthorization property enables SQL Authorization mode. You can revoke privileges for an object if you are the owner of the object or the database owner. The syntax that you use for the REVOKE statement depends on whether you are revoking privileges to a schema object or revoking a role. For more information on using the REVOKE statement, see "Using SQL standard authorization" in the Java DB Developer's Guide. Syntax for tables REVOKE privilege-type ON [ TABLE ] { table-Name | view-Name } FROM grantees Revoking a privilege without specifying a column list revokes the privilege for all of the columns in the table. Syntax for routines REVOKE EXECUTE ON { FUNCTION | PROCEDURE } routine-designator FROM grantees RESTRICT You must use the RESTRICT clause on REVOKE statements for routines. The RESTRICT clause specifies that the EXECUTE privilege cannot be revoked if the specified routine is used in a view, trigger, or constraint, and the privilege is being revoked from the owner of the view, trigger, or constraint. Syntax for sequence generators REVOKE USAGE ON SEQUENCE [ schemaName. ] SQL92Identifier FROM grantees RESTRICT In order to use a sequence generator, you must have the USAGE privilege on it. This privilege can be revoked from users and roles. Only RESTRICTed revokes are allowed. This means that the REVOKE statement cannot make a view, trigger, or constraint unusable by its owner. The USAGE privilege cannot be revoked from the schema owner. See CREATE SEQUENCE statement for more information. The sequence name is composed of an optional schemaName and a SQL92Identifier. If a schemaName is not provided, the current schema is the default schema. If a qualified sequence name is specified, the schema name cannot begin with SYS. Syntax for user-defined types REVOKE USAGE ON TYPE [ schemaName. ] SQL92Identifier FROM grantees RESTRICT In order to use a user-defined type, you must have the USAGE privilege on it. This privilege can be revoked from users and roles. Only RESTRICTed revokes are allowed. This means that the REVOKE statement cannot make a view, trigger, or constraint unusable by its owner. The USAGE privilege cannot be revoked from the schema owner. See CREATE TYPE statement for more information. The type name is composed of an optional schemaName and a SQL92Identifier. If a schemaName is not provided, the current schema is the default schema. If a qualified type name is specified, the schema name cannot begin with SYS. Syntax for roles REVOKE roleName [ {, roleName }* ] FROM grantees Only the database owner can revoke a role. privilege-types ALL PRIVILEGES | privilege-list privilege-list table-privilege {, table-privilege }* table-privilege  DELETE | INSERT | REFERENCES [column list] | SELECT [column list] | TRIGGER | UPDATE [column list] column list ( column-identifier {, column-identifier}* ) Use the ALL PRIVILEGES privilege type to revoke all of the privileges from the user or role for the specified table. You can also revoke one or more table privileges by specifying a privilege-list. Use the DELETE privilege type to revoke permission to delete rows from the specified table. Use the INSERT privilege type to revoke permission to insert rows into the specified table. Use the REFERENCES privilege type to revoke permission to create a foreign key reference to the specified table. If a column list is specified with the REFERENCES privilege, the permission is revoked on only the foreign key reference to the specified columns. Use the SELECT privilege type to revoke permission to perform SELECT statements on a table or view. If a column list is specified with the SELECT privilege, the permission is revoked on only those columns. If no column list is specified, then the privilege is valid on all of the columns in the table. Use the TRIGGER privilege type to revoke permission to create a trigger on the specified table. Use the UPDATE privilege type to revoke permission to use the UPDATE statement on the specified table. If a column list is specified, the privilege is revoked only on the specified columns. grantees { AuthorizationIdentifier | roleName | PUBLIC } [,{ AuthorizationIdentifier | roleName | PUBLIC } ] * You can revoke the privileges from specific users or roles or from all users. Use the keyword PUBLIC to specify all users. The privileges revoked from PUBLIC and from individual users or roles are independent privileges. For example, a SELECT privilege on table t is granted to both PUBLIC and to the authorization ID harry. The SELECT privilege is later revoked from the authorization ID harry, but the authorization ID harry can access the table t through the PUBLIC privilege. You can revoke a role from a role, from a user, or from PUBLIC. Restriction: You cannot revoke the privileges of the owner of an object. routine-designator { qualified-name [ signature ] } sequenceName [ schemaName. ] SQL92Identifier If schemaName is not provided, the current schema is the default schema. If a qualified sequence name is specified, the schema name cannot begin with SYS. Prepared statements and open result sets/cursors Checking for privileges happens at statement execution time, so prepared statements are still usable after a revoke action. If sufficient privileges are still available for the session, prepared statements will be executed, and for queries, a result set will be returned. Once a result set has been returned to the application (by executing a prepared statement or by direct execution), it will remain accessible even if privileges or roles are revoked in a way that would cause another execution of the same statement to fail. Cascading object dependencies For views, triggers, and constraints, if the privilege on which the object depends on is revoked, the object is automatically dropped. Derby does not try to determine if you have other privileges that can replace the privileges that are being revoked. For more information, see "Using SQL standard authorization" and "Privileges on views, triggers, and constraints" in the Java DB Developer's Guide. Limitations The following limitations apply to the REVOKE statement: Table-level privileges All of the table-level privilege types for a specified grantee and table ID are stored in one row in the SYSTABLEPERMS system table. For example,  when user2 is granted the SELECT and DELETE privileges on table user1.t1, a row is added to the SYSTABLEPERMS table. The GRANTEE field contains user2 and the TABLEID contains user1.t1. The SELECTPRIV and DELETEPRIV fields are set to Y. The remaining privilege type fields are set to N. When a grantee creates an object that relies on one of the privilege types, the Derby engine tracks the dependency of the object on the specific row in the SYSTABLEPERMS table. For example, user2 creates the view v1 by using the statement SELECT * FROM user1.t1, the dependency manager tracks the dependency of view v1 on the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1). The dependency manager knows only that the view is dependent on a privilege type in that specific row, but does not track exactly which privilege type the view is dependent on. When a REVOKE statement for a table-level privilege is issued for a grantee and table ID, all of the objects that are dependent on the grantee and table ID are dropped. For example, if user1 revokes the DELETE privilege on table t1 from user2, the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1) is modified by the REVOKE statement. The dependency manager sends a revoke invalidation message to the view user2.v1 and the view is dropped even though the view is not dependent on the DELETE privilege for GRANTEE(user2), TABLEID(user1.t1). Column-level privileges Only one type of privilege for a specified grantee and table ID are stored in one row in the SYSCOLPERMS system table. For example, when user2 is granted the SELECT privilege on table user1.t1 for columns c12 and c13, a row is added to the SYSCOLPERMS. The GRANTEE field contains user2, the TABLEID contains user1.t1, the TYPE field contains S, and the COLUMNS field contains c12, c13. When a grantee creates an object that relies on the privilege type and the subset of columns in a table ID, the Derby engine tracks the dependency of the object on the specific row in the SYSCOLPERMS table. For example, user2 creates the view v1 by using the statement SELECT c11 FROM user1.t1, the dependency manager tracks the dependency of view v1 on the row in SYSCOLPERMS for GRANTEE(user2), TABLEID(user1.t1), TYPE(S). The dependency manager knows that the  view is dependent on the SELECT privilege type, but does not track exactly which columns the view is dependent on. When a REVOKE statement for a column-level privilege is issued for a grantee, table ID, and type, all of the objects that are dependent on the grantee, table ID, and type are dropped. For example, if user1 revokes the SELECT privilege on column c12 on table user1.t1 from user2, the row in SYSCOLPERMS for GRANTEE(user2), TABLEID(user1.t1), TYPE(S) is modified by the REVOKE statement. The dependency manager sends a revoke invalidation message to the view user2.v1 and the view is dropped even though the view is not dependent on the column c12 for GRANTEE(user2), TABLEID(user1.t1), TYPE(S). Roles Derby tracks any dependencies on the definer's current role for views, constraints, and triggers. If privileges were obtainable only via the current role when the object in question was defined, that object depends on the current role. The object will be dropped if the role is revoked from the defining user or from PUBLIC, as the case may be. Also, if a contained role of the current role in such cases is revoked, dependent objects will be dropped. Note that dropping may be too pessimistic. This is because Derby does not currently make an attempt to recheck if the necessary privileges are still available in such cases. Revoke examples To revoke the SELECT privilege on table t from the authorization IDs maria and harry, use the following syntax: REVOKE SELECT ON TABLE t FROM maria,harry To revoke the UPDATE and TRIGGER privileges on table t from the authorization IDs anita and zhi, use the following syntax: REVOKE UPDATE, TRIGGER ON TABLE t FROM anita,zhi To revoke the SELECT privilege on table s.v from all users, use the following syntax: REVOKE SELECT ON TABLE s.v FROM PUBLIC To revoke the UPDATE privilege on columns c1 and c2 of table s.v from all users, use the following syntax: REVOKE UPDATE (c1,c2) ON TABLE s.v FROM PUBLIC To revoke the EXECUTE privilege on procedure p from the authorization ID george, use the following syntax: REVOKE EXECUTE ON PROCEDURE p FROM george RESTRICT To revoke the role purchases_reader_role from the authorization IDs george and maria, use the following syntax: REVOKE purchases_reader_role FROM george,maria To revoke the SELECT privilege on table t from the role purchases_reader_role, use the following syntax: REVOKE SELECT ON TABLE t FROM purchases_reader_role To revoke the USAGE privilege on the sequence generator order_id from the role sales_role, use the following syntax: REVOKE USAGE ON SEQUENCE order_id FROM sales_role; To revoke the USAGE privilege on the user-defined type price from the role finance_role, use the following syntax: REVOKE USAGE ON TYPE price FROM finance_role; SYSTABLEPERMS system table The SYSTABLEPERMS table stores the table permissions that have been granted but not revoked. All of the permissions for one (GRANTEE, TABLEID, GRANTOR) combination are specified in a single row in the SYSTABLEPERMS table. The keys for the SYSTABLEPERMS table are:  Primary key (GRANTEE, TABLEID, GRANTOR)  Unique key (TABLEPERMSID)  Foreign key (TABLEID references SYS.SYSTABLES) The following table shows the contents of the SYSTABLEPERMS system table. Table 1. SYSTABLEPERMS system table Column Name Type Length Nullable Contents TABLEPERMSID CHAR 36 false Used by the dependency manager to track the dependency of a view, trigger, or constraint  Table 1. SYSTABLEPERMS system table Column Name Type Length Nullable Contents on the table level permissions GRANTEE VARCHAR 128 false The authorization ID of the user or role to which the privilege is granted GRANTOR VARCHAR 128 false The authorization ID of the user who granted the privilege. Privileges can be granted only by the object owner TABLEID CHAR 36 false The unique identifier for the table on which the permissions have been granted SELECTPRIV CHAR 1 false Specifies if the SELECT permission is granted. The valid values are: 'y' (non-grantable privilege) 'Y' (grantable privilege) 'N' (no privilege) DELETEPRIV CHAR 1 false Specifies if the DELETE permission is granted. The valid values are: 'y' (non-grantable privilege) 'Y' (grantable privilege) 'N' (no privilege) INSERTPRIV CHAR 1 False Specifies if the INSERT permission is granted. The valid values are: 'y' (non-grantable privilege) 'Y' (grantable  Table 1. SYSTABLEPERMS system table Column Name Type Length Nullable Contents privilege) 'N' (no privilege) UPDATEPRIV CHAR 1 False Specifies if the UPDATE permission is granted. The valid values are: 'y' (non-grantable privilege) 'Y' (grantable privilege) 'N' (no privilege) REFERENCESPRIV CHAR 1 false Specifies if the REFERENCE permission is granted. The valid values are: 'y' (non-grantable privilege) 'Y' (grantable privilege) 'N' (no privilege) TRIGGERPRIV CHAR 1 false Specifies if the TRIGGER permission is granted. The valid values are: 'y' (non-grantable privilege) 'Y' (grantable privilege) 'N' (no privilege) Connexion administrateur dédiée SQL Server (DAC) La connexion administrateur dédiée (DAC) peut vous aider à sortir d'une situation délicate. Elle a été conçue pour vous aider à vous connecter à SQL Server et à exécuter des requêtes de base en cas de problèmes de performances critiques. Elle fonctionne en indiquant à SQL Server de réserver un thread spécifiquement pour le traitement de vos requêtes en cas d'urgence. Bien qu'elle vous réserve une connexion, il ne s'agit que d'un seul thread, il n'y a pas de parallélisme ici, en fait, vous recevrez une erreur. En règle générale, ce qui se produit et où cela peut aider, c'est lorsque votre serveur SQL réclame des ressources, mais qu'aucune n'est disponible. D'après mon expérience, cela est lié à des requêtes de longue durée qui ne sont pas optimisées pour les données que l'utilisateur final souhaite renvoyer ou à votre serveur SQL qui n'autorise pas de nouvelles connexions. Avec le DAC, vous êtes désormais en mesure de trouver la requête de longue durée et de fermer cette session ou de résoudre le problème. Sécurisation Limitez l’accès à distance Par défaut, MySQL écoute les connexions sur le port 3306 à partir de n’importe quel hôte. Cela peut laisser votre port MySQL ouvert aux attaques. Une meilleure approche consiste à autoriser uniquement les connexions à partir d’hôtes de confiance qui doivent accéder à MySQL. Voici quelques façons de limiter l’accès à distance : Lier à des adresses IP spécifiques Dans votre fichier de configuration MySQL (my.cnf), spécifiez des directives bind- address pour restreindre l’écoute à une ou plusieurs adresses IP sur votre réseau privé : bind-address=192.168.1.101 bind-address=127.0.0.1 Cela fera en sorte que MySQL n’écoute que sur les adresses IP définies. Autoriser l’accès uniquement via VPN Si vos clients à distance se connectent via VPN, vous pouvez configurer MySQL pour autoriser uniquement les connexions à partir du sous-réseau IP du tunnel VPN. Utilisez des pare-feu Les règles de pare-feu fournissent une autre couche de contrôle sur l’accès à distance. Avec iptables sur Linux, par exemple, vous ne pouvez autoriser les connexions que depuis des adresses IP spécifiées. L’essentiel est de limiter les connexions aux seules adresses IP client de confiance qui nécessitent réellement l’accès MySQL. 3. Utilisez des connexions sécurisées Par défaut, MySQL transmet les données de manière non sécurisée en texte brut. Pour chiffrer les connexions, vous devez activer Transport Layer Security (TLS). Il existe quelques façons de mettre en œuvre TLS : Appliquer TLS pour des utilisateurs spécifiques Dans MySQL, accordez l’autorisation à un compte d’utilisateur de se connecter via TLS : mysql> GRANT USAGE ON *.* TO 'mysqluser'@'192.168.1.101' REQUIRE SSL; Cela exige que l’utilisateur spécifié se connecte à l’aide du chiffrement TLS. Activer TLS sur le serveur MySQL Pour rendre TLS obligatoire pour l’ensemble du serveur MySQL, modifiez votre configuration MySQL : [mysqld] ssl-ca=/chemin/vers/ca.pem ssl-cert=/chemin/vers/certificat-serveur.pem ssl-key=/chemin/vers/clé-serveur.pem require_secure_transport=ON Redémarrez MySQL, et toutes les connexions client utiliseront désormais TLS. Utiliser le tunneling SSH Une autre option consiste à tunneliser votre connexion MySQL via SSH, ce qui chiffre tout le trafic. Par exemple : $ ssh -L 3307:127.0.0.1:3306 [email protected] -N -f Vous pouvez ensuite vous connecter localement au tunnel sur le port 3307. 4. Améliorez la sécurité de l’authentification L’utilisation des seuls mots de passe pour l’authentification MySQL présente quelques faiblesses. Des plugins d’authentification supplémentaires peuvent encore mieux verrouiller l’accès : Exiger l’authentification à deux facteurs Activez le plugin MFA pour les comptes : mysql> CREATE USER 'jeffrey'@'192.168.1.101' IDENTIFIED WITH authentication_ldap_simple AS 'secretPassword'; mysql> ALTER USER 'jeffrey'@'192.168.1.101' REQUIRE TWO_FACTOR AUTHENTICATION VIA one_time_password; La connexion nécessitera désormais à la fois un mot de passe et un code à usage unique.