Traductionsamedi 18 juin 2016
QUESTION D'ENTRETIEN AVEC ORACLE DATA GUARD - RÉPONSE
Qu’est-ce que la protection des données ?
Data Guard fournit un ensemble complet de services qui créent, maintiennent, gèrent et surveillent une ou plusieurs bases de données de secours pour permettre aux bases de données Oracle de production de survivre aux sinistres et aux corruptions de données. Data Guard conserve ces bases de données de secours en tant que copies de la base de données de production. Data Guard peut être utilisé avec des techniques traditionnelles de sauvegarde, de restauration et de cluster pour fournir un niveau élevé de protection et de disponibilité des données.
Quels sont les avantages d’utiliser Oracle Data Guard ?
Voici les différents avantages liés à l'utilisation de la fonctionnalité Oracle Data Guard dans votre environnement.
Quels sont les modes de protection dans Dataguard ?
Modes de protection Data Guard
Cette section décrit les modes de protection Data Guard.
Dans ces descriptions, une base de données de secours synchronisée est censée être une base de données qui répond aux exigences minimales du mode de protection des données configuré et qui ne présente pas d'intervalle de restauration.
Disponibilité maximale
Ce mode de protection offre le plus haut niveau de protection des données possible sans compromettre la disponibilité d'une base de données principale. Les transactions ne sont pas validées tant que toutes les données de restauration nécessaires à la récupération de ces transactions n'ont pas été écrites dans le journal de restauration en ligne et dans au moins une base de données de secours synchronisée. Si la base de données principale ne peut pas écrire son flux de restauration dans au moins une base de données de secours synchronisée, elle fonctionne comme si elle était en mode de performances maximales pour préserver la disponibilité de la base de données principale jusqu'à ce qu'elle soit à nouveau capable d'écrire son flux de restauration dans une base de données de secours synchronisée.
Ce mode garantit qu'aucune perte de données ne se produira en cas de panne de la base de données principale, mais uniquement si une seconde panne n'empêche pas l'envoi d'un ensemble complet de données de rétablissement depuis la base de données principale vers au moins une base de données de secours.
Performances maximales
Ce mode de protection offre le plus haut niveau de protection des données possible sans affecter les performances d'une base de données principale. Ceci est accompli en autorisant la validation des transactions dès que toutes les données de rétablissement générées par ces transactions ont été écrites dans le journal en ligne. Les données de rétablissement sont également écrites dans une ou plusieurs bases de données de secours, mais cela se fait de manière asynchrone en ce qui concerne l'engagement des transactions, de sorte que les performances de la base de données principale ne sont pas affectées par les retards d'écriture des données de rétablissement dans la ou les bases de données de secours.
Ce mode de protection offre une protection des données légèrement inférieure à celle du mode de disponibilité maximale et a un impact minimal sur les performances de la base de données principale.
Il s'agit du mode de protection par défaut.
Protection maximale
Ce mode de protection garantit qu'aucune perte de données ne se produit en cas de panne d'une base de données principale. Pour fournir ce niveau de protection, les données de restauration nécessaires à la récupération d'une transaction doivent être écrites à la fois dans le journal de restauration en ligne et dans au moins une base de données de secours synchronisée avant la validation de la transaction. Pour garantir qu'aucune perte de données ne se produise, la base de données principale s'arrêtera, plutôt que de continuer à traiter les transactions, si elle ne peut pas écrire son flux de rétablissement dans au moins une base de données de secours synchronisée.
Étant donné que ce mode de protection des données donne la priorité à la protection des données plutôt qu'à la disponibilité de la base de données principale, Oracle recommande d'utiliser au moins deux bases de données de secours pour protéger une base de données principale qui s'exécute en mode de protection maximale afin d'éviter qu'une seule défaillance de la base de données de secours n'entraîne l'arrêt de la base de données principale. .
Quelle est la différence entre la base de données de secours physique et la base de données de secours logique ?
Le processus Data Guard Apply dans la base de données de veille peut appliquer directement les informations de restauration et dans ce cas, il sera appelé veille physique.
OU Il peut appliquer SQL et dans ce cas il sera appelé veille logique.
Physique de secours :
dans ce cas, la base de données de secours est une réplique physique exacte, bloc par bloc, de la base de données principale.
Les vecteurs de modification reçus par le processus RFS sont directement appliqués à la base de données de secours à l'aide de la récupération de support. Ainsi, ici, le processus d'application lit les blocs de données, assemble les modifications de rétablissement à partir des mappages, puis applique directement les modifications de rétablissement aux blocs de données.
La veille physique est le meilleur choix pour la reprise après sinistre (DR) en raison de sa simplicité, de sa transparence, de ses hautes performances et de sa bonne protection des données.
Veille logique :
dans ce cas, la base de données de secours utilise la méthode SQL Apply pour « exploiter » la restauration en la convertissant en enregistrements de modifications logiques, puis en créant
des transactions SQL et en appliquant SQL à la base de données de secours.
Comme ce processus de relecture de la charge de travail est plus complexe que le processus de mise en veille physique, il nécessite plus de mémoire, de processeur et d'E/S.
Un bon avantage ici est qu'une base de données de secours logique peut être ouverte en lecture-écriture pendant que SQL Apply est actif, ce qui signifie que vous pouvez mettre à jour (créer/insérer/supprimer, etc.) des tables et des schémas locaux dans la base de données de secours logique.
Expliquer l'architecture Dataguard L'
architecture Data Guard intègre les éléments suivants :
• Base de données primaire : une base de données de production utilisée pour créer des bases de données de secours. Les journaux d'archives de la base de données principale sont transférés et appliqués aux bases de données de secours. Chaque base de données de secours ne peut être associée qu'à une seule base de données principale, mais une seule base de données principale peut être associée à plusieurs bases de données de secours.
• Base de données de secours : une réplique de la base de données principale.
• Services de transport de journaux : contrôlez le transfert automatique des fichiers de journalisation d'archive de la base de données principale vers une ou plusieurs destinations de secours.
• Configuration réseau : la base de données principale est connectée à une ou plusieurs bases de données de secours à l'aide d'Oracle Net.
• Services d'application de journaux - Appliquez les journaux redo archivés à la base de données de secours. Le processus de récupération géré (MRP) effectue en fait le travail de maintenance et d'application des journaux redo archivés.
• Services de gestion des rôles - Contrôlez le changement des rôles de base de données de primaire à redondant. Les services incluent le basculement, le basculement et le basculement.
• Data Guard Broker - Contrôle la création et la surveillance de Data Guard. Il est livré avec une interface graphique et une interface de ligne de commande.
Base de données primaire :
Une configuration Data Guard contient une base de données de production, également appelée base de données principale, qui fonctionne dans le rôle principal. Il s'agit de la base de données à laquelle accède la plupart de vos applications.
Base de données de secours :
une base de données de secours est une copie transactionnellement cohérente de la base de données principale. À l'aide d'une copie de sauvegarde de la base de données principale, vous pouvez créer jusqu'à neuf bases de données de secours et les incorporer dans une configuration Data Guard. Une fois créée, Data Guard gère automatiquement chaque base de données de secours en transmettant les données de restauration à partir de la base de données principale, puis en appliquant la restauration à la base de données de secours.
Les types de bases de données de secours sont les suivants :
Base de données de secours physique :
fournit une copie physiquement identique de la base de données principale, avec des structures de base de données sur disque identiques à la base de données principale bloc par bloc. Le schéma de la base de données, y compris les index, est le même. Une base de données de secours physique est maintenue synchronisée avec la base de données principale, via Redo Apply, qui récupère les données de restauration reçues de la base de données principale et applique la restauration à la base de données de secours physique.
Base de données de secours logique :
contient les mêmes informations logiques que la base de données de production, bien que l'organisation physique et la structure des données puissent être différentes. La base de données de secours logique est synchronisée avec la base de données primaire via SQL Apply, qui transforme les données du rétablissement reçu de la base de données primaire en instructions SQL, puis exécute les instructions SQL sur la base de données de secours.
Quelles sont les étapes pour créer une base de données de secours physique ?
1.Effectuer une sauvegarde complète à chaud de la base de données primaire
2. Activer la journalisation forcée dans la base de données
3. Préparer le fichier de paramètres pour la base de données primaire
4. Activer l'archivage
5.Créer un fichier de contrôle de secours
6.Transférer la sauvegarde complète, init.ora, le fichier de contrôle de secours vers nœud de secours.
7.Modifiez le fichier init.ora sur le nœud de veille.
8.Restaurer la base de données
9.Récupérer la base de données de secours
10.Mettre la base de données de secours en mode de récupération gérée
Quels sont les PARAMÈTRES DATAGUARD dans Oracle ?
Définir les paramètres d'initialisation de la base de données principale
------------------------------------------------------- -
Sur la base de données principale, vous définissez les paramètres d'initialisation qui contrôlent les services de rétablissement de transport pendant que la base de données joue le rôle principal. Vous devez ajouter des paramètres supplémentaires qui contrôlent la réception des services de rétablissement des données et d'application des journaux lorsque la base de données principale passe au rôle de secours.
DB_NAME=chicago
DB_UNIQUE_NAME=chicago
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
CONTROL_FILES='/arch1/chicago/control1.ctl', '/arch2/chicago/control2.ctl'
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/chicago/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_2=
'SERVICE=boston LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_ STATE_2=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
LOG_ARCHIVE_FORMAT=% t_%s_%r.arc
LOG_ARCHIVE_MAX_PROCESSES=30
Base de données primaire : Paramètres d'initialisation du rôle de secours
FAL_SERVER=boston
FAL_CLIENT=chicago
DB_FILE_NAME_CONVERT='boston','chicago'
LOG_FILE_NAME_CONVERT= '/arch1/boston/','/arch1/chicago/', '/arch2/boston/','/arch2/chicago/'
STANDBY_FILE_MANAGEMENT=AUTO
Préparer un fichier de paramètres d'initialisation pour la base de données de secours
----------------------- ------------------------------------------
Créer un fichier de paramètres d'initialisation de texte (PFILE ) à partir du fichier de paramètres du serveur (SPFILE) utilisé par la base de données primaire ; un fichier de paramètres d'initialisation de texte peut être copié vers l'emplacement de veille et modifié. Par exemple :
CREATE PFILE='/tmp/initboston.ora' FROM SPFILE;
Modification des paramètres d'initialisation d'une base de données physique de secours.
DB_NAME=chicago
DB_UNIQUE_NAME=boston
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
CONTROL_FILES='/arch1/boston/control1.ctl', '/arch2/boston/control2.ctl'
DB_FILE_NAME_CONVERT='chicago','boston'
LOG_FILE_NAME_CONVERT = '/arch1/chicago/','/arch1/boston/','/arch2/chicago/','/arch2/boston/'
LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1 /boston/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2= 'SERVICE=chicago LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
REM OTE_LOGIN_PASSWORDFILE=EXCLUSIVE
STANDBY_FILE_MANAGEMENT=AUTO
FAL_SERVER=chicago
FAL_CLIENT= boston
Quels sont les services requis sur la base de données principale et de secours ?
Les services requis sur la base de données principale sont les suivants :
• Log Writer Process (LGWR) : collecte les informations de restauration et met à jour les journaux de restauration en ligne. Il peut également créer des journaux de rétablissement archivés localement et transmettre les rétablissements en ligne aux bases de données de secours.
• Processus d'archivage (ARCn) : un ou plusieurs processus d'archivage effectuent des copies des journaux redo en ligne, soit localement, soit à distance pour les bases de données de secours.
• Serveur de récupération du journal d'archive (FAL)- Demandes de services pour les journaux redo d'archives provenant de clients FAL exécutés sur plusieurs bases de données de secours. Plusieurs serveurs FAL peuvent être exécutés sur une base de données principale, un pour chaque requête FAL. .
Les services requis sur la base de données de secours sont les suivants :
• Client Fetch Archive Log (FAL) : extrait les fichiers de journalisation archivés du site principal. Lance le transfert des journaux redo archivés lorsqu'il détecte une séquence d'intervalles.
• Serveur de fichiers distant (RFS) : reçoit les journaux redo archivés et/ou en veille de la base de données principale.
• Processus d'archivage (ARCn) : archive les journaux redo de secours appliqués par le processus de récupération gérée (MRP).
• Processus de récupération géré (MRP) : applique les informations de journalisation de l'archive à la base de données de secours.
Qu’est-ce que RTS (Redo Transport Services) dans Dataguard ?
Il contrôle le transfert automatisé des données de restauration de la base de données de production vers une ou plusieurs destinations d'archivage. Les services de transport de restauration effectuent les tâches suivantes :
a) Transmettre les données de restauration du système principal aux systèmes de secours dans la configuration.
b) Gérer le processus de résolution de toute lacune dans les fichiers de journalisation archivés en raison d'une panne de réseau.
c) Détectez automatiquement les fichiers de journalisation archivés manquants ou corrompus sur un système de secours et récupérez automatiquement les fichiers de journalisation archivés de remplacement à partir de la
base de données principale ou d'une autre base de données de secours.
Qu'est-ce qu'une base de données de secours d'instantanés ?
Oracle 11g introduit la base de données Snapshot Standby qui est essentiellement une base de données de secours pouvant être mise à jour et créée à partir d'une base de données de secours physique.
Nous pouvons convertir une base de données physique de secours en une base de données de secours instantanée, effectuer une sorte de test sur une base de données qui est une copie en lecture et en écriture de la base de données principale ou de production actuelle, puis enfin la rétablir à son état antérieur en tant que base de données physique de secours.
Lorsque la base de données de secours d'instantanés est ouverte en mode lecture-écriture, la restauration est reçue de la base de données principale, mais n'est pas appliquée.
Après l'avoir reconvertie en base de données physique de secours, elle est resynchronisée avec la base de données principale en appliquant les données de rétablissement accumulées qui ont été précédemment expédiées depuis la base de données principale mais non appliquées.
Grâce à un instantané en veille, nous sommes en mesure d'effectuer des tests d'applications en temps réel en utilisant des données de production en temps quasi réel. Très souvent, nous sommes amenés à réaliser des clones de production à des fins de tests. Mais en utilisant des bases de données de secours d'instantanés, nous pouvons répondre aux mêmes exigences en économisant l'effort, le temps, les ressources et l'espace disque.
Une base de données de secours d'instantané est une base de données de secours entièrement actualisable qui est créée en convertissant une base de données de secours physique en une base de données de secours d'instantané.
Comme une base de données de secours physique ou logique, une base de données de secours instantanée reçoit et archive les données de restauration d'une base de données principale. Contrairement à une base de données de secours physique ou logique, une base de données de secours instantanée n'applique pas les données de rétablissement qu'elle reçoit. Les données de rétablissement reçues par une base de données de secours d'instantané ne sont pas appliquées jusqu'à ce que la base de données de secours d'instantané soit reconvertie en base de données de secours physique, après avoir d'abord supprimé toutes les mises à jour locales effectuées sur la base de données de secours d'instantané.
Quelle est l'utilisation du paramètre DB_FILE_NAME_CONVERT dans la configuration d'Oracle Data Guard ?
Le paramètre DB_FILE_NAME_CONVERT est utilisé dans la configuration d'Oracle Data Guard dans les bases de données de secours. Le paramètre DB_FILE_NAME_CONVERT est utilisé pour mettre à jour l'emplacement des fichiers de données dans la base de données de secours. Ces paramètres sont utilisés lorsque vous utilisez une structure de répertoires différente dans la base de données de secours par rapport à l'emplacement des fichiers de données de la base de données principale.
Quelle est l'utilisation du paramètre LOG_FILE_NAME_CONVERT dans la configuration d'Oracle Data Guard ?
Le paramètre LOG_FILE_NAME_CONVERT est utilisé dans la configuration d'Oracle Data Guard dans les bases de données de secours. Le paramètre LOG_FILE_NAME_CONVERT est utilisé pour mettre à jour l'emplacement des fichiers de journalisation dans la base de données de secours. Ces paramètres sont utilisés lorsque vous utilisez une structure de répertoires différente dans la base de données de secours par rapport à l'emplacement du fichier de journalisation de la base de données principale.
Votre base de données de secours était hors de portée en raison d'un problème de réseau. Comment allez-vous le synchroniser à nouveau avec la base de données principale ?
Data Guard resynchronise automatiquement le réseau de secours après des pannes de réseau ou de secours à l'aide des données de restauration archivées sur le serveur principal.
Quelle est la différence entre les méthodes de rétablissement de transport SYNC et ASYNC ? Transport synchrone (SYNC) Également connu sous le nom de méthode de rétablissement du transport « sans perte de données ». Voici comment cela fonctionne : 1) Log Network Server (LNS) lit les informations de restauration à partir du tampon de restauration dans SGA de la base de données PRIMARY 2) Log Network Server (LNS) transmet la restauration à Oracle Net Services pour transmission à la base de données STANDBY 3) Fichier distant(RFS) enregistre les informations de rétablissement transmises par le LNS dans la base de données STANDBY 4) Le serveur de fichiers distant (RFS) les écrit dans un fichier séquentiel appelé fichier de journalisation de secours (SRL) dans la base de données STANDBY 5) Le serveur de fichiers distant (RFS) ) transmet un accusé de réception au processus LNS sur la base de données principale. 6) Log Network Server (LNS) informe le LGWR que la transmission est terminée sur la base de données principale. 7) Log Writer (LGWR) accuse réception de la validation auprès de l'utilisateur. Transport asynchrone (ASYNC) Contrairement à SYNC, le transport asynchrone (ASYNC) élimine la nécessité pour le LGWR d'attendre l'accusé de réception du LNS. Cela supprime l'impact sur les performances de la base de données principale, quelle que soit la distance entre les emplacements principal et de secours. Ainsi, si le LNS n'est pas en mesure de suivre le rythme et que le tampon de journal est recyclé avant que le rétablissement puisse être transmis au serveur de secours, le LNS passe automatiquement à la lecture et à l'envoi à partir des journaux de rétablissement en ligne. Une fois que le LNS est rattrapé, il revient automatiquement à la lecture et à l'envoi directement à partir du tampon de journal. Voici comment cela fonctionne : 1) Log Network Server (LNS) lit les informations de restauration à partir du tampon de restauration dans SGA de la base de données PRIMAIRE.
2) Log Network Server (LNS) transmet la restauration à Oracle Net Services pour transmission à la base de données STANDBY
3) Le serveur de fichiers distant (RFS) enregistre les informations de restauration transmises par le LNS dans la base de données STANDBY
4) Le serveur de fichiers distant (RFS) l'écrit vers un fichier séquentiel appelé fichier de journalisation de secours (SRL) dans la base de données STANDBY,
donc les étapes 5, 6 et 7 décrites ci-dessus pour SYNC ne sont pas applicables ici.
Le seul inconvénient d’ASYNC est le risque accru de perte de données. Supposons qu'un échec détruise la base de données principale avant que tout délai de transport ne soit réduit à zéro, cela signifie que toutes les transactions validées qui faisaient partie du délai de transport seront perdues. Il est donc fortement conseillé de disposer de suffisamment de bande passante réseau pour gérer
les taux de génération de restauration de pointe lors de l'utilisation de la méthode ASYNC.
Quel est l'impact du transport synchrone (SYNC) sur les performances de la base de données principale ?
SYNC garantit la protection de chaque transaction que la base de données reconnaît comme ayant été validée, mais en même temps LGWR doit attendre la confirmation que les données sont protégées en veille avant de pouvoir passer à la transaction suivante. Cela peut avoir un impact sur les performances de la base de données principale et cela dépend de facteurs tels que
Qu'est-ce que la résolution automatique des écarts de Data Guard ?
Votre base de données utilise la méthode de transport ASYNC et la charge de l'instance est à son maximum. Le LNS est incapable de suivre le rythme et le tampon de journal est recyclé avant que le rétablissement puisse être transmis au serveur de secours. Le LNS passe automatiquement à la lecture et à l'envoi à partir des journaux de rétablissement en ligne. Une fois que le LNS est rattrapé, il revient automatiquement à la lecture et à l'envoi directement à partir du tampon de journal.
Désormais, dans certains cas, il peut y avoir deux commutateurs de journal ou plus avant que le LNS n'ait terminé l'envoi des informations de restauration à partir des fichiers de journalisation en ligne et, entre-temps, si de tels fichiers de journalisation en ligne requis ont été archivés, ces informations de restauration seront transmises via l'intervalle de Data Guard. processus de résolution « Résolution automatique des écarts ».
OU
Dans d'autres cas, lorsque votre réseau ou la base de données de secours est en panne et que votre système principal est un système occupé, donc avant que la connexion entre le principal et la base de données de secours ne soit restaurée, un espace important dans le fichier journal se formera.
La résolution automatique des écarts prendra en charge de tels scénarios en suivant le plan d'action ci-dessous :
1) Le processus ARCH sur la base de données principale ping en continu la base de données de secours pendant la panne pour déterminer son état.
2) Dès que la veille est restaurée, le processus ping ARCH interroge le fichier de contrôle de veille (via son processus RFS) pour déterminer le dernier fichier journal complet que la veille a reçu de la base de données principale.
3) Data Guard détermine quels fichiers journaux sont nécessaires pour resynchroniser la base de données de secours et commence immédiatement à les transmettre à l'aide de processus ARCH supplémentaires.
4) Le processus LNS de la base de données principale tentera également et réussira à établir une connexion à la base de données de secours et commencera à transmettre la restauration actuelle. Ainsi, tous les fichiers ARCH sont d'abord appliqués, puis le journal redo actuel.
L'architecture Data Guard permet de résoudre rapidement les lacunes à l'aide de plusieurs processus ARCH en arrière-plan.
Comment fonctionne le processus Data Guard Apply si les bases de données primaire et secondaire impliquent Oracle RAC ?
Si la base de données principale est RAC mais que la base de données de secours est non-RAC :
chaque instance Oracle RAC principale envoie son propre thread de rétablissement qui est fusionné par le processus d'application Data Guard au niveau de la base de données de secours et appliqué dans l'ordre SCN à la base de données de secours.
Si les bases de données principale et de secours sont RAC :
si la base de données de secours est également une base de données Oracle RAC, une seule instance (l'instance d'application) fusionnera et appliquera les modifications à la base de données de secours. Si l'instance d'application échoue pour une raison quelconque, le processus d'application basculera automatiquement vers une instance survivante dans la base de données de secours Oracle RAC lors de l'utilisation du courtier Data Guard.
Qu'est-ce que l'option Active Data Guard (Oracle Database 11g Enterprise Edition) ?
Pour la base de données physique de secours, avant la version 11g, la base de données devait être dans l'état de montage lorsque la récupération du support était active, ce qui signifie que vous ne pouviez pas interroger la base de données de secours pendant l'étape de récupération du support car il n'y avait pas de vue cohérente en lecture.
Les fonctionnalités d'Active Data Guard 11g résolvent le problème de cohérence de lecture en utilisant un SCN « requête ». Le processus de récupération de support sur la base de données de secours fera avancer la requête SCN une fois que toutes les modifications d'une transaction auront été appliquées. La requête SCN apparaîtra à l'utilisateur sous la forme de la colonne CURRENT_SCN dans la vue V$DATABASE sur la base de données de secours. Ainsi, les utilisateurs en lecture seule ne pourront voir les données que jusqu'au SCN de la requête, garantissant ainsi la même cohérence de lecture que la base de données principale.
Cela permet à une base de données physique de secours d'être ouverte en lecture seule pendant que la récupération de support est active, ce qui la rend utile pour effectuer des charges de travail en lecture seule.
De plus, si vous avez besoin d'un accès en lecture-écriture à la base de données de secours, vous pouvez utiliser la méthode SQL Apply de dataguard.
Quels sont les paramètres de base de données importants liés à la prévention de la corruption de Data Guard ?
Sur la base de données principale :
a) DB_ULTRA_SAFE
Les valeurs peuvent être DATA_AND_INDEX ou DATA_ONLY. La définition de DB_ULTRA_SAFE sur la base de données principale définira également automatiquement DB_ LOST_WRITE_PROTECT=TYPICAL sur la base de données principale.
Dans Oracle Database 11g Release 2 (11.2), la base de données principale tente automatiquement de réparer le bloc corrompu en temps réel en récupérant une bonne version du même bloc à partir d'une base de données physique de secours.
Sur la base de données de secours :
a) DB_BLOCK_CHECKSUM=FULL
DB_BLOCK_CHECKSUM détecte les corruptions de restauration et de blocs de données, détecte les corruptions sur la base de données principale et protège la base de données de secours. Ce paramètre nécessite des ressources CPU minimales.
b) DB_LOST_WRITE_PROTECT=TYPICAL
Une perte d'écriture peut se produire lorsqu'un sous-système d'E/S accuse réception de la fin d'une écriture, alors qu'en fait l'écriture ne s'est pas produite dans le stockage persistant.
Cela créera une version obsolète du bloc de données. Lorsque le paramètre d'initialisation DB_LOST_WRITE_PROTECT est défini, la base de données enregistre les lectures du bloc de cache tampon dans le journal redo et ces informations sont utilisées pour détecter les écritures perdues.
Vous définissez DB_LOST_WRITE_PROTECT sur TYPICAL dans les bases de données principale et de secours.
Qu’est-ce qu’un événement Switchover ?
Le basculement est utile pour minimiser les temps d’arrêt lors de la maintenance planifiée. Il s'agit d'un événement planifié dans lequel Data Guard inverse les rôles de base de données principale et de base de données de secours.
La base de données principale ne sera pas affectée pendant que nous apportons les modifications requises sur notre base de données de secours (par exemple, mises à niveau des ensembles de correctifs, mises à niveau de la version complète d'Oracle, etc.).
Une fois les modifications terminées, la production est basculée vers le site de secours fonctionnant sur la nouvelle version.
Cela signifie que, quel que soit le temps nécessaire pour effectuer la maintenance planifiée, le seul temps d'arrêt de la base de données de production est le temps nécessaire pour exécuter un basculement, qui peut être inférieur à 60 secondes.
Les opérations ci-dessous se produisent lorsque la commande de basculement est exécutée :
1. la base de données principale est notifiée qu'un basculement est sur le point de se produire.
2. tous les utilisateurs sont déconnectés du serveur principal.
3. Un enregistrement de restauration spécial est généré pour signaler la fin de la restauration (EOR).
4. La base de données principale est convertie en base de données de secours.
5. L'enregistrement EOR final est appliqué à la base de données de secours, ce qui garantit qu'aucune donnée n'a été perdue et convertit la base de données de secours en rôle principal.
Qu’est-ce qu’un événement de basculement ?
Le processus de basculement est similaire à l'événement de basculement, sauf que la base de données principale n'a jamais la possibilité d'écrire un enregistrement EOR car il s'agit d'un événement imprévu.
Le fait qu'un basculement entraîne ou non une perte de données dépend du mode de protection Data Guard :
a) Protection maximale >> Aucune perte de données
b) Disponibilité maximale >> Aucune perte de données (sauf en cas de panne précédente (par exemple, une panne de réseau) qui avait INTERROMPU LE TRANSPORT REDO et permis à la base de données principale d'avancer sur la base de données de secours)
c) Performances maximales (ASYNC) >> peut perdre toutes les transactions validées qui n'ont pas été transmises à la base de données de secours avant l'échec de la base de données principale.
L'événement de basculement peut être de deux types :
1)
L'administrateur manuel a un contrôle total sur les transitions entre les rôles principal et de secours. Cela peut prolonger la panne du temps nécessaire pour que l'administrateur soit averti et pour l'exécution manuelle de la commande.
2) Automatique
Il utilise la fonctionnalité Fast-Start Failover de Data Guard qui détecte automatiquement la panne, évalue l'état de la configuration de Data Guard et, le cas échéant, exécute le basculement vers une base de données de secours préalablement choisie.
Quels outils peuvent être utilisés pour la gestion de Data Guard ?
1) SQL*Plus – méthode traditionnelle, peut s'avérer très fastidieuse à utiliser
. 2) Data Guard Broker – automatise et centralise la création, la maintenance et la surveillance d'une configuration Data Guard. Simplifie et automatise de nombreuses
tâches administratives. Il possède sa propre ligne de commande (DGMGRL) et sa propre syntaxe.
3) Enterprise Manager – nécessite que le courtier Data Guard soit activé. une interface graphique pour le courtier Data Guard, remplaçant la ligne de commande DGMGRL et s'interfaçant directement avec les processus de surveillance du courtier.
Quelle est la différence entre l'objectif de point de récupération (RPO) et l'objectif de temps de récupération (RTO) ?
A) Objectif de point de récupération (RPO)
Problèmes de RPO avec les données. Il s'agit de la quantité de données que vous êtes prêt à perdre en cas de panne de votre système de base de données. Habituellement, les gens définissent la perte de données en termes de temps, les valeurs possibles peuvent donc être 5 secondes de perte de données, 2 heures de perte de données, etc.
N'oubliez pas que chaque base de données de secours possède son propre ensemble d'attributs et de paramètres. Cela signifie que vous pouvez mélanger des bases de données de secours sans perte de données avec
des bases de données de secours avec perte de données minimale dans la même configuration Data Guard.
Si vous avez décidé de mettre en œuvre une stratégie sans perte de données, vous devriez vraiment vous concentrer sur les réseaux et la perte de données.
B) Temps de récupération Objectif (RTO)
Le RTO est défini comme la rapidité avec laquelle vous pouvez être de nouveau opérationnel (alors que le RPO concerne la perte de données).
Ainsi, avec votre stratégie RPO, vous n'avez perdu, disons, qu'environ 6 secondes de données lorsque vous vous êtes engagé auprès de votre client, mais avec le RTO, vous Vous devez définir la rapidité avec laquelle les clients peuvent se reconnecter au système de base de données après la perte de données.
Que sont les fichiers SSL (Standby Redo Log) ?
Les fichiers SRL sont l'endroit où le processus du serveur de fichiers distant (RFS) de votre base de données de secours écrit la restauration entrante afin qu'elle soit persistante sur le disque pour la récupération. Les fichiers SRL sont importants pour de meilleures performances de transport et une meilleure protection des données.
Les SRL sont OBLIGATOIRES en mode Disponibilité maximale ou Protection maximale et OPTIONNEL (mais recommandé) en mode Performance maximale.
S'il n'y a pas de fichiers SSL (SRL), à chaque changement de journal dans la base de données principale, le processus RFS sur la base de données de secours qui dessert une destination de secours asynchrone doit créer un journal d'archive de la bonne taille. Pendant que le RFS est occupé à créer le fichier journal d'archive, le processus LNS au niveau de la base de données principale doit attendre, se plaçant de plus en plus derrière le LGWR (en cas de mode Performance maximale). C'est pourquoi il est recommandé d'avoir également les fichiers Standby Redo Log (SRL) en mode Performances maximales.
Nous les configurons généralement également sur notre base de données principale en préparation d'une transition de rôle entre primaire et secours.
De plus, ne multiplexez pas les SRL. Étant donné que Data Guard demandera immédiatement une nouvelle copie du journal d'archive en cas de défaillance d'un fichier SRL, il n'est pas vraiment nécessaire d'avoir plus d'une copie de chacun.
Data Guard fournit un ensemble complet de services qui créent, maintiennent, gèrent et surveillent une ou plusieurs bases de données de secours pour permettre aux bases de données Oracle de production de survivre aux sinistres et aux corruptions de données. Data Guard conserve ces bases de données de secours en tant que copies de la base de données de production. Data Guard peut être utilisé avec des techniques traditionnelles de sauvegarde, de restauration et de cluster pour fournir un niveau élevé de protection et de disponibilité des données.
Quels sont les avantages d’utiliser Oracle Data Guard ?
Voici les différents avantages liés à l'utilisation de la fonctionnalité Oracle Data Guard dans votre environnement.
- La haute disponibilité.
- Protection des données.
- Hors chargement Opération de sauvegarde vers la base de données de secours.
- Détection et résolution automatiques des écarts dans la base de données en veille.
- Transition automatique des rôles à l’aide de Data Guard Broker.
Quels sont les modes de protection dans Dataguard ?
Modes de protection Data Guard
Cette section décrit les modes de protection Data Guard.
Dans ces descriptions, une base de données de secours synchronisée est censée être une base de données qui répond aux exigences minimales du mode de protection des données configuré et qui ne présente pas d'intervalle de restauration.
Disponibilité maximale
Ce mode de protection offre le plus haut niveau de protection des données possible sans compromettre la disponibilité d'une base de données principale. Les transactions ne sont pas validées tant que toutes les données de restauration nécessaires à la récupération de ces transactions n'ont pas été écrites dans le journal de restauration en ligne et dans au moins une base de données de secours synchronisée. Si la base de données principale ne peut pas écrire son flux de restauration dans au moins une base de données de secours synchronisée, elle fonctionne comme si elle était en mode de performances maximales pour préserver la disponibilité de la base de données principale jusqu'à ce qu'elle soit à nouveau capable d'écrire son flux de restauration dans une base de données de secours synchronisée.
Ce mode garantit qu'aucune perte de données ne se produira en cas de panne de la base de données principale, mais uniquement si une seconde panne n'empêche pas l'envoi d'un ensemble complet de données de rétablissement depuis la base de données principale vers au moins une base de données de secours.
Performances maximales
Ce mode de protection offre le plus haut niveau de protection des données possible sans affecter les performances d'une base de données principale. Ceci est accompli en autorisant la validation des transactions dès que toutes les données de rétablissement générées par ces transactions ont été écrites dans le journal en ligne. Les données de rétablissement sont également écrites dans une ou plusieurs bases de données de secours, mais cela se fait de manière asynchrone en ce qui concerne l'engagement des transactions, de sorte que les performances de la base de données principale ne sont pas affectées par les retards d'écriture des données de rétablissement dans la ou les bases de données de secours.
Ce mode de protection offre une protection des données légèrement inférieure à celle du mode de disponibilité maximale et a un impact minimal sur les performances de la base de données principale.
Il s'agit du mode de protection par défaut.
Protection maximale
Ce mode de protection garantit qu'aucune perte de données ne se produit en cas de panne d'une base de données principale. Pour fournir ce niveau de protection, les données de restauration nécessaires à la récupération d'une transaction doivent être écrites à la fois dans le journal de restauration en ligne et dans au moins une base de données de secours synchronisée avant la validation de la transaction. Pour garantir qu'aucune perte de données ne se produise, la base de données principale s'arrêtera, plutôt que de continuer à traiter les transactions, si elle ne peut pas écrire son flux de rétablissement dans au moins une base de données de secours synchronisée.
Étant donné que ce mode de protection des données donne la priorité à la protection des données plutôt qu'à la disponibilité de la base de données principale, Oracle recommande d'utiliser au moins deux bases de données de secours pour protéger une base de données principale qui s'exécute en mode de protection maximale afin d'éviter qu'une seule défaillance de la base de données de secours n'entraîne l'arrêt de la base de données principale. .
Quelle est la différence entre la base de données de secours physique et la base de données de secours logique ?
Le processus Data Guard Apply dans la base de données de veille peut appliquer directement les informations de restauration et dans ce cas, il sera appelé veille physique.
OU Il peut appliquer SQL et dans ce cas il sera appelé veille logique.
Physique de secours :
dans ce cas, la base de données de secours est une réplique physique exacte, bloc par bloc, de la base de données principale.
Les vecteurs de modification reçus par le processus RFS sont directement appliqués à la base de données de secours à l'aide de la récupération de support. Ainsi, ici, le processus d'application lit les blocs de données, assemble les modifications de rétablissement à partir des mappages, puis applique directement les modifications de rétablissement aux blocs de données.
La veille physique est le meilleur choix pour la reprise après sinistre (DR) en raison de sa simplicité, de sa transparence, de ses hautes performances et de sa bonne protection des données.
Veille logique :
dans ce cas, la base de données de secours utilise la méthode SQL Apply pour « exploiter » la restauration en la convertissant en enregistrements de modifications logiques, puis en créant
des transactions SQL et en appliquant SQL à la base de données de secours.
Comme ce processus de relecture de la charge de travail est plus complexe que le processus de mise en veille physique, il nécessite plus de mémoire, de processeur et d'E/S.
Un bon avantage ici est qu'une base de données de secours logique peut être ouverte en lecture-écriture pendant que SQL Apply est actif, ce qui signifie que vous pouvez mettre à jour (créer/insérer/supprimer, etc.) des tables et des schémas locaux dans la base de données de secours logique.
Expliquer l'architecture Dataguard L'
architecture Data Guard intègre les éléments suivants :
• Base de données primaire : une base de données de production utilisée pour créer des bases de données de secours. Les journaux d'archives de la base de données principale sont transférés et appliqués aux bases de données de secours. Chaque base de données de secours ne peut être associée qu'à une seule base de données principale, mais une seule base de données principale peut être associée à plusieurs bases de données de secours.
• Base de données de secours : une réplique de la base de données principale.
• Services de transport de journaux : contrôlez le transfert automatique des fichiers de journalisation d'archive de la base de données principale vers une ou plusieurs destinations de secours.
• Configuration réseau : la base de données principale est connectée à une ou plusieurs bases de données de secours à l'aide d'Oracle Net.
• Services d'application de journaux - Appliquez les journaux redo archivés à la base de données de secours. Le processus de récupération géré (MRP) effectue en fait le travail de maintenance et d'application des journaux redo archivés.
• Services de gestion des rôles - Contrôlez le changement des rôles de base de données de primaire à redondant. Les services incluent le basculement, le basculement et le basculement.
• Data Guard Broker - Contrôle la création et la surveillance de Data Guard. Il est livré avec une interface graphique et une interface de ligne de commande.
Base de données primaire :
Une configuration Data Guard contient une base de données de production, également appelée base de données principale, qui fonctionne dans le rôle principal. Il s'agit de la base de données à laquelle accède la plupart de vos applications.
Base de données de secours :
une base de données de secours est une copie transactionnellement cohérente de la base de données principale. À l'aide d'une copie de sauvegarde de la base de données principale, vous pouvez créer jusqu'à neuf bases de données de secours et les incorporer dans une configuration Data Guard. Une fois créée, Data Guard gère automatiquement chaque base de données de secours en transmettant les données de restauration à partir de la base de données principale, puis en appliquant la restauration à la base de données de secours.
Les types de bases de données de secours sont les suivants :
Base de données de secours physique :
fournit une copie physiquement identique de la base de données principale, avec des structures de base de données sur disque identiques à la base de données principale bloc par bloc. Le schéma de la base de données, y compris les index, est le même. Une base de données de secours physique est maintenue synchronisée avec la base de données principale, via Redo Apply, qui récupère les données de restauration reçues de la base de données principale et applique la restauration à la base de données de secours physique.
Base de données de secours logique :
contient les mêmes informations logiques que la base de données de production, bien que l'organisation physique et la structure des données puissent être différentes. La base de données de secours logique est synchronisée avec la base de données primaire via SQL Apply, qui transforme les données du rétablissement reçu de la base de données primaire en instructions SQL, puis exécute les instructions SQL sur la base de données de secours.
Quelles sont les étapes pour créer une base de données de secours physique ?
1.Effectuer une sauvegarde complète à chaud de la base de données primaire
2. Activer la journalisation forcée dans la base de données
3. Préparer le fichier de paramètres pour la base de données primaire
4. Activer l'archivage
5.Créer un fichier de contrôle de secours
6.Transférer la sauvegarde complète, init.ora, le fichier de contrôle de secours vers nœud de secours.
7.Modifiez le fichier init.ora sur le nœud de veille.
8.Restaurer la base de données
9.Récupérer la base de données de secours
10.Mettre la base de données de secours en mode de récupération gérée
Quels sont les PARAMÈTRES DATAGUARD dans Oracle ?
Définir les paramètres d'initialisation de la base de données principale
------------------------------------------------------- -
Sur la base de données principale, vous définissez les paramètres d'initialisation qui contrôlent les services de rétablissement de transport pendant que la base de données joue le rôle principal. Vous devez ajouter des paramètres supplémentaires qui contrôlent la réception des services de rétablissement des données et d'application des journaux lorsque la base de données principale passe au rôle de secours.
DB_NAME=chicago
DB_UNIQUE_NAME=chicago
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
CONTROL_FILES='/arch1/chicago/control1.ctl', '/arch2/chicago/control2.ctl'
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/chicago/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_2=
'SERVICE=boston LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_ STATE_2=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
LOG_ARCHIVE_FORMAT=% t_%s_%r.arc
LOG_ARCHIVE_MAX_PROCESSES=30
Base de données primaire : Paramètres d'initialisation du rôle de secours
FAL_SERVER=boston
FAL_CLIENT=chicago
DB_FILE_NAME_CONVERT='boston','chicago'
LOG_FILE_NAME_CONVERT= '/arch1/boston/','/arch1/chicago/', '/arch2/boston/','/arch2/chicago/'
STANDBY_FILE_MANAGEMENT=AUTO
Préparer un fichier de paramètres d'initialisation pour la base de données de secours
----------------------- ------------------------------------------
Créer un fichier de paramètres d'initialisation de texte (PFILE ) à partir du fichier de paramètres du serveur (SPFILE) utilisé par la base de données primaire ; un fichier de paramètres d'initialisation de texte peut être copié vers l'emplacement de veille et modifié. Par exemple :
CREATE PFILE='/tmp/initboston.ora' FROM SPFILE;
Modification des paramètres d'initialisation d'une base de données physique de secours.
DB_NAME=chicago
DB_UNIQUE_NAME=boston
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
CONTROL_FILES='/arch1/boston/control1.ctl', '/arch2/boston/control2.ctl'
DB_FILE_NAME_CONVERT='chicago','boston'
LOG_FILE_NAME_CONVERT = '/arch1/chicago/','/arch1/boston/','/arch2/chicago/','/arch2/boston/'
LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1 /boston/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2= 'SERVICE=chicago LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
REM OTE_LOGIN_PASSWORDFILE=EXCLUSIVE
STANDBY_FILE_MANAGEMENT=AUTO
FAL_SERVER=chicago
FAL_CLIENT= boston
Quels sont les services requis sur la base de données principale et de secours ?
Les services requis sur la base de données principale sont les suivants :
• Log Writer Process (LGWR) : collecte les informations de restauration et met à jour les journaux de restauration en ligne. Il peut également créer des journaux de rétablissement archivés localement et transmettre les rétablissements en ligne aux bases de données de secours.
• Processus d'archivage (ARCn) : un ou plusieurs processus d'archivage effectuent des copies des journaux redo en ligne, soit localement, soit à distance pour les bases de données de secours.
• Serveur de récupération du journal d'archive (FAL)- Demandes de services pour les journaux redo d'archives provenant de clients FAL exécutés sur plusieurs bases de données de secours. Plusieurs serveurs FAL peuvent être exécutés sur une base de données principale, un pour chaque requête FAL. .
Les services requis sur la base de données de secours sont les suivants :
• Client Fetch Archive Log (FAL) : extrait les fichiers de journalisation archivés du site principal. Lance le transfert des journaux redo archivés lorsqu'il détecte une séquence d'intervalles.
• Serveur de fichiers distant (RFS) : reçoit les journaux redo archivés et/ou en veille de la base de données principale.
• Processus d'archivage (ARCn) : archive les journaux redo de secours appliqués par le processus de récupération gérée (MRP).
• Processus de récupération géré (MRP) : applique les informations de journalisation de l'archive à la base de données de secours.
Qu’est-ce que RTS (Redo Transport Services) dans Dataguard ?
Il contrôle le transfert automatisé des données de restauration de la base de données de production vers une ou plusieurs destinations d'archivage. Les services de transport de restauration effectuent les tâches suivantes :
a) Transmettre les données de restauration du système principal aux systèmes de secours dans la configuration.
b) Gérer le processus de résolution de toute lacune dans les fichiers de journalisation archivés en raison d'une panne de réseau.
c) Détectez automatiquement les fichiers de journalisation archivés manquants ou corrompus sur un système de secours et récupérez automatiquement les fichiers de journalisation archivés de remplacement à partir de la
base de données principale ou d'une autre base de données de secours.
Qu'est-ce qu'une base de données de secours d'instantanés ?
Oracle 11g introduit la base de données Snapshot Standby qui est essentiellement une base de données de secours pouvant être mise à jour et créée à partir d'une base de données de secours physique.
Nous pouvons convertir une base de données physique de secours en une base de données de secours instantanée, effectuer une sorte de test sur une base de données qui est une copie en lecture et en écriture de la base de données principale ou de production actuelle, puis enfin la rétablir à son état antérieur en tant que base de données physique de secours.
Lorsque la base de données de secours d'instantanés est ouverte en mode lecture-écriture, la restauration est reçue de la base de données principale, mais n'est pas appliquée.
Après l'avoir reconvertie en base de données physique de secours, elle est resynchronisée avec la base de données principale en appliquant les données de rétablissement accumulées qui ont été précédemment expédiées depuis la base de données principale mais non appliquées.
Grâce à un instantané en veille, nous sommes en mesure d'effectuer des tests d'applications en temps réel en utilisant des données de production en temps quasi réel. Très souvent, nous sommes amenés à réaliser des clones de production à des fins de tests. Mais en utilisant des bases de données de secours d'instantanés, nous pouvons répondre aux mêmes exigences en économisant l'effort, le temps, les ressources et l'espace disque.
Une base de données de secours d'instantané est une base de données de secours entièrement actualisable qui est créée en convertissant une base de données de secours physique en une base de données de secours d'instantané.
Comme une base de données de secours physique ou logique, une base de données de secours instantanée reçoit et archive les données de restauration d'une base de données principale. Contrairement à une base de données de secours physique ou logique, une base de données de secours instantanée n'applique pas les données de rétablissement qu'elle reçoit. Les données de rétablissement reçues par une base de données de secours d'instantané ne sont pas appliquées jusqu'à ce que la base de données de secours d'instantané soit reconvertie en base de données de secours physique, après avoir d'abord supprimé toutes les mises à jour locales effectuées sur la base de données de secours d'instantané.
Comment retarder l’application des logs sur une veille physique ?
Une base de données de secours applique automatiquement les journaux redo lorsqu'ils arrivent de la base de données principale. Mais dans certains cas, nous souhaitons créer un décalage temporel entre l'archivage d'un redo log sur le site principal, et l'application du log sur le site de secours.
Modifiez le paramètre d'initialisation LOG_ARCHIVE_DEST_n sur la base de données principale pour définir un délai pour la base de données de secours.
Exemple : Pour un délai de 60 minutes :
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=stdby_srvc DELAY=60';
L'attribut DELAY est exprimé en minutes.
Les journaux redo archivés sont toujours automatiquement copiés du site principal vers le site de secours, mais les journaux ne sont pas immédiatement appliqués à la base de données de secours. Les journaux sont appliqués à l'expiration de l'intervalle de temps spécifié.
Quelle est l'utilisation du paramètre DB_FILE_NAME_CONVERT dans la configuration d'Oracle Data Guard ?
Le paramètre DB_FILE_NAME_CONVERT est utilisé dans la configuration d'Oracle Data Guard dans les bases de données de secours. Le paramètre DB_FILE_NAME_CONVERT est utilisé pour mettre à jour l'emplacement des fichiers de données dans la base de données de secours. Ces paramètres sont utilisés lorsque vous utilisez une structure de répertoires différente dans la base de données de secours par rapport à l'emplacement des fichiers de données de la base de données principale.
Quelle est l'utilisation du paramètre LOG_FILE_NAME_CONVERT dans la configuration d'Oracle Data Guard ?
Le paramètre LOG_FILE_NAME_CONVERT est utilisé dans la configuration d'Oracle Data Guard dans les bases de données de secours. Le paramètre LOG_FILE_NAME_CONVERT est utilisé pour mettre à jour l'emplacement des fichiers de journalisation dans la base de données de secours. Ces paramètres sont utilisés lorsque vous utilisez une structure de répertoires différente dans la base de données de secours par rapport à l'emplacement du fichier de journalisation de la base de données principale.
Votre base de données de secours était hors de portée en raison d'un problème de réseau. Comment allez-vous le synchroniser à nouveau avec la base de données principale ?
Data Guard resynchronise automatiquement le réseau de secours après des pannes de réseau ou de secours à l'aide des données de restauration archivées sur le serveur principal.
Quelle est la différence entre les méthodes de rétablissement de transport SYNC et ASYNC ? Transport synchrone (SYNC) Également connu sous le nom de méthode de rétablissement du transport « sans perte de données ». Voici comment cela fonctionne : 1) Log Network Server (LNS) lit les informations de restauration à partir du tampon de restauration dans SGA de la base de données PRIMARY 2) Log Network Server (LNS) transmet la restauration à Oracle Net Services pour transmission à la base de données STANDBY 3) Fichier distant(RFS) enregistre les informations de rétablissement transmises par le LNS dans la base de données STANDBY 4) Le serveur de fichiers distant (RFS) les écrit dans un fichier séquentiel appelé fichier de journalisation de secours (SRL) dans la base de données STANDBY 5) Le serveur de fichiers distant (RFS) ) transmet un accusé de réception au processus LNS sur la base de données principale. 6) Log Network Server (LNS) informe le LGWR que la transmission est terminée sur la base de données principale. 7) Log Writer (LGWR) accuse réception de la validation auprès de l'utilisateur. Transport asynchrone (ASYNC) Contrairement à SYNC, le transport asynchrone (ASYNC) élimine la nécessité pour le LGWR d'attendre l'accusé de réception du LNS. Cela supprime l'impact sur les performances de la base de données principale, quelle que soit la distance entre les emplacements principal et de secours. Ainsi, si le LNS n'est pas en mesure de suivre le rythme et que le tampon de journal est recyclé avant que le rétablissement puisse être transmis au serveur de secours, le LNS passe automatiquement à la lecture et à l'envoi à partir des journaux de rétablissement en ligne. Une fois que le LNS est rattrapé, il revient automatiquement à la lecture et à l'envoi directement à partir du tampon de journal. Voici comment cela fonctionne : 1) Log Network Server (LNS) lit les informations de restauration à partir du tampon de restauration dans SGA de la base de données PRIMAIRE.
2) Log Network Server (LNS) transmet la restauration à Oracle Net Services pour transmission à la base de données STANDBY
3) Le serveur de fichiers distant (RFS) enregistre les informations de restauration transmises par le LNS dans la base de données STANDBY
4) Le serveur de fichiers distant (RFS) l'écrit vers un fichier séquentiel appelé fichier de journalisation de secours (SRL) dans la base de données STANDBY,
donc les étapes 5, 6 et 7 décrites ci-dessus pour SYNC ne sont pas applicables ici.
Le seul inconvénient d’ASYNC est le risque accru de perte de données. Supposons qu'un échec détruise la base de données principale avant que tout délai de transport ne soit réduit à zéro, cela signifie que toutes les transactions validées qui faisaient partie du délai de transport seront perdues. Il est donc fortement conseillé de disposer de suffisamment de bande passante réseau pour gérer
les taux de génération de restauration de pointe lors de l'utilisation de la méthode ASYNC.
Quel est l'impact du transport synchrone (SYNC) sur les performances de la base de données principale ?
SYNC garantit la protection de chaque transaction que la base de données reconnaît comme ayant été validée, mais en même temps LGWR doit attendre la confirmation que les données sont protégées en veille avant de pouvoir passer à la transaction suivante. Cela peut avoir un impact sur les performances de la base de données principale et cela dépend de facteurs tels que
- la quantité d'informations de restauration à écrire
- bande passante réseau disponible
- latence du réseau aller-retour (RTT)
- performances d'E/S en veille, écriture sur la SRL.
- distance entre les bases de données principale et de secours, car le RTT du réseau augmente avec la distance.
Qu'est-ce que la résolution automatique des écarts de Data Guard ?
Votre base de données utilise la méthode de transport ASYNC et la charge de l'instance est à son maximum. Le LNS est incapable de suivre le rythme et le tampon de journal est recyclé avant que le rétablissement puisse être transmis au serveur de secours. Le LNS passe automatiquement à la lecture et à l'envoi à partir des journaux de rétablissement en ligne. Une fois que le LNS est rattrapé, il revient automatiquement à la lecture et à l'envoi directement à partir du tampon de journal.
Désormais, dans certains cas, il peut y avoir deux commutateurs de journal ou plus avant que le LNS n'ait terminé l'envoi des informations de restauration à partir des fichiers de journalisation en ligne et, entre-temps, si de tels fichiers de journalisation en ligne requis ont été archivés, ces informations de restauration seront transmises via l'intervalle de Data Guard. processus de résolution « Résolution automatique des écarts ».
OU
Dans d'autres cas, lorsque votre réseau ou la base de données de secours est en panne et que votre système principal est un système occupé, donc avant que la connexion entre le principal et la base de données de secours ne soit restaurée, un espace important dans le fichier journal se formera.
La résolution automatique des écarts prendra en charge de tels scénarios en suivant le plan d'action ci-dessous :
1) Le processus ARCH sur la base de données principale ping en continu la base de données de secours pendant la panne pour déterminer son état.
2) Dès que la veille est restaurée, le processus ping ARCH interroge le fichier de contrôle de veille (via son processus RFS) pour déterminer le dernier fichier journal complet que la veille a reçu de la base de données principale.
3) Data Guard détermine quels fichiers journaux sont nécessaires pour resynchroniser la base de données de secours et commence immédiatement à les transmettre à l'aide de processus ARCH supplémentaires.
4) Le processus LNS de la base de données principale tentera également et réussira à établir une connexion à la base de données de secours et commencera à transmettre la restauration actuelle. Ainsi, tous les fichiers ARCH sont d'abord appliqués, puis le journal redo actuel.
L'architecture Data Guard permet de résoudre rapidement les lacunes à l'aide de plusieurs processus ARCH en arrière-plan.
Comment fonctionne le processus Data Guard Apply si les bases de données primaire et secondaire impliquent Oracle RAC ?
Si la base de données principale est RAC mais que la base de données de secours est non-RAC :
chaque instance Oracle RAC principale envoie son propre thread de rétablissement qui est fusionné par le processus d'application Data Guard au niveau de la base de données de secours et appliqué dans l'ordre SCN à la base de données de secours.
Si les bases de données principale et de secours sont RAC :
si la base de données de secours est également une base de données Oracle RAC, une seule instance (l'instance d'application) fusionnera et appliquera les modifications à la base de données de secours. Si l'instance d'application échoue pour une raison quelconque, le processus d'application basculera automatiquement vers une instance survivante dans la base de données de secours Oracle RAC lors de l'utilisation du courtier Data Guard.
Qu'est-ce que l'option Active Data Guard (Oracle Database 11g Enterprise Edition) ?
Pour la base de données physique de secours, avant la version 11g, la base de données devait être dans l'état de montage lorsque la récupération du support était active, ce qui signifie que vous ne pouviez pas interroger la base de données de secours pendant l'étape de récupération du support car il n'y avait pas de vue cohérente en lecture.
Les fonctionnalités d'Active Data Guard 11g résolvent le problème de cohérence de lecture en utilisant un SCN « requête ». Le processus de récupération de support sur la base de données de secours fera avancer la requête SCN une fois que toutes les modifications d'une transaction auront été appliquées. La requête SCN apparaîtra à l'utilisateur sous la forme de la colonne CURRENT_SCN dans la vue V$DATABASE sur la base de données de secours. Ainsi, les utilisateurs en lecture seule ne pourront voir les données que jusqu'au SCN de la requête, garantissant ainsi la même cohérence de lecture que la base de données principale.
Cela permet à une base de données physique de secours d'être ouverte en lecture seule pendant que la récupération de support est active, ce qui la rend utile pour effectuer des charges de travail en lecture seule.
De plus, si vous avez besoin d'un accès en lecture-écriture à la base de données de secours, vous pouvez utiliser la méthode SQL Apply de dataguard.
Quels sont les paramètres de base de données importants liés à la prévention de la corruption de Data Guard ?
Sur la base de données principale :
a) DB_ULTRA_SAFE
Les valeurs peuvent être DATA_AND_INDEX ou DATA_ONLY. La définition de DB_ULTRA_SAFE sur la base de données principale définira également automatiquement DB_ LOST_WRITE_PROTECT=TYPICAL sur la base de données principale.
Dans Oracle Database 11g Release 2 (11.2), la base de données principale tente automatiquement de réparer le bloc corrompu en temps réel en récupérant une bonne version du même bloc à partir d'une base de données physique de secours.
Sur la base de données de secours :
a) DB_BLOCK_CHECKSUM=FULL
DB_BLOCK_CHECKSUM détecte les corruptions de restauration et de blocs de données, détecte les corruptions sur la base de données principale et protège la base de données de secours. Ce paramètre nécessite des ressources CPU minimales.
b) DB_LOST_WRITE_PROTECT=TYPICAL
Une perte d'écriture peut se produire lorsqu'un sous-système d'E/S accuse réception de la fin d'une écriture, alors qu'en fait l'écriture ne s'est pas produite dans le stockage persistant.
Cela créera une version obsolète du bloc de données. Lorsque le paramètre d'initialisation DB_LOST_WRITE_PROTECT est défini, la base de données enregistre les lectures du bloc de cache tampon dans le journal redo et ces informations sont utilisées pour détecter les écritures perdues.
Vous définissez DB_LOST_WRITE_PROTECT sur TYPICAL dans les bases de données principale et de secours.
Qu’est-ce qu’un événement Switchover ?
Le basculement est utile pour minimiser les temps d’arrêt lors de la maintenance planifiée. Il s'agit d'un événement planifié dans lequel Data Guard inverse les rôles de base de données principale et de base de données de secours.
La base de données principale ne sera pas affectée pendant que nous apportons les modifications requises sur notre base de données de secours (par exemple, mises à niveau des ensembles de correctifs, mises à niveau de la version complète d'Oracle, etc.).
Une fois les modifications terminées, la production est basculée vers le site de secours fonctionnant sur la nouvelle version.
Cela signifie que, quel que soit le temps nécessaire pour effectuer la maintenance planifiée, le seul temps d'arrêt de la base de données de production est le temps nécessaire pour exécuter un basculement, qui peut être inférieur à 60 secondes.
Les opérations ci-dessous se produisent lorsque la commande de basculement est exécutée :
1. la base de données principale est notifiée qu'un basculement est sur le point de se produire.
2. tous les utilisateurs sont déconnectés du serveur principal.
3. Un enregistrement de restauration spécial est généré pour signaler la fin de la restauration (EOR).
4. La base de données principale est convertie en base de données de secours.
5. L'enregistrement EOR final est appliqué à la base de données de secours, ce qui garantit qu'aucune donnée n'a été perdue et convertit la base de données de secours en rôle principal.
Qu’est-ce qu’un événement de basculement ?
Le processus de basculement est similaire à l'événement de basculement, sauf que la base de données principale n'a jamais la possibilité d'écrire un enregistrement EOR car il s'agit d'un événement imprévu.
Le fait qu'un basculement entraîne ou non une perte de données dépend du mode de protection Data Guard :
a) Protection maximale >> Aucune perte de données
b) Disponibilité maximale >> Aucune perte de données (sauf en cas de panne précédente (par exemple, une panne de réseau) qui avait INTERROMPU LE TRANSPORT REDO et permis à la base de données principale d'avancer sur la base de données de secours)
c) Performances maximales (ASYNC) >> peut perdre toutes les transactions validées qui n'ont pas été transmises à la base de données de secours avant l'échec de la base de données principale.
L'événement de basculement peut être de deux types :
1)
L'administrateur manuel a un contrôle total sur les transitions entre les rôles principal et de secours. Cela peut prolonger la panne du temps nécessaire pour que l'administrateur soit averti et pour l'exécution manuelle de la commande.
2) Automatique
Il utilise la fonctionnalité Fast-Start Failover de Data Guard qui détecte automatiquement la panne, évalue l'état de la configuration de Data Guard et, le cas échéant, exécute le basculement vers une base de données de secours préalablement choisie.
Quels outils peuvent être utilisés pour la gestion de Data Guard ?
1) SQL*Plus – méthode traditionnelle, peut s'avérer très fastidieuse à utiliser
. 2) Data Guard Broker – automatise et centralise la création, la maintenance et la surveillance d'une configuration Data Guard. Simplifie et automatise de nombreuses
tâches administratives. Il possède sa propre ligne de commande (DGMGRL) et sa propre syntaxe.
3) Enterprise Manager – nécessite que le courtier Data Guard soit activé. une interface graphique pour le courtier Data Guard, remplaçant la ligne de commande DGMGRL et s'interfaçant directement avec les processus de surveillance du courtier.
Quelle est la différence entre l'objectif de point de récupération (RPO) et l'objectif de temps de récupération (RTO) ?
A) Objectif de point de récupération (RPO)
Problèmes de RPO avec les données. Il s'agit de la quantité de données que vous êtes prêt à perdre en cas de panne de votre système de base de données. Habituellement, les gens définissent la perte de données en termes de temps, les valeurs possibles peuvent donc être 5 secondes de perte de données, 2 heures de perte de données, etc.
N'oubliez pas que chaque base de données de secours possède son propre ensemble d'attributs et de paramètres. Cela signifie que vous pouvez mélanger des bases de données de secours sans perte de données avec
des bases de données de secours avec perte de données minimale dans la même configuration Data Guard.
Si vous avez décidé de mettre en œuvre une stratégie sans perte de données, vous devriez vraiment vous concentrer sur les réseaux et la perte de données.
B) Temps de récupération Objectif (RTO)
Le RTO est défini comme la rapidité avec laquelle vous pouvez être de nouveau opérationnel (alors que le RPO concerne la perte de données).
Ainsi, avec votre stratégie RPO, vous n'avez perdu, disons, qu'environ 6 secondes de données lorsque vous vous êtes engagé auprès de votre client, mais avec le RTO, vous Vous devez définir la rapidité avec laquelle les clients peuvent se reconnecter au système de base de données après la perte de données.
Que sont les fichiers SSL (Standby Redo Log) ?
Les fichiers SRL sont l'endroit où le processus du serveur de fichiers distant (RFS) de votre base de données de secours écrit la restauration entrante afin qu'elle soit persistante sur le disque pour la récupération. Les fichiers SRL sont importants pour de meilleures performances de transport et une meilleure protection des données.
Les SRL sont OBLIGATOIRES en mode Disponibilité maximale ou Protection maximale et OPTIONNEL (mais recommandé) en mode Performance maximale.
S'il n'y a pas de fichiers SSL (SRL), à chaque changement de journal dans la base de données principale, le processus RFS sur la base de données de secours qui dessert une destination de secours asynchrone doit créer un journal d'archive de la bonne taille. Pendant que le RFS est occupé à créer le fichier journal d'archive, le processus LNS au niveau de la base de données principale doit attendre, se plaçant de plus en plus derrière le LGWR (en cas de mode Performance maximale). C'est pourquoi il est recommandé d'avoir également les fichiers Standby Redo Log (SRL) en mode Performances maximales.
Nous les configurons généralement également sur notre base de données principale en préparation d'une transition de rôle entre primaire et secours.
De plus, ne multiplexez pas les SRL. Étant donné que Data Guard demandera immédiatement une nouvelle copie du journal d'archive en cas de défaillance d'un fichier SRL, il n'est pas vraiment nécessaire d'avoir plus d'une copie de chacun.
mercredi 4 mai 2016
Questions et réponses d'entretien avec Oracle DBA - Exportation/Importation
À quoi sert l’option CONSISTENT dans exp ?
Lorsque vous exportez une table, vous avez la garantie que le contenu de cette table sera cohérent avec l'heure à laquelle l'exportation de cette table a commencé. Cela signifie que si vous commencez à exporter le tableau à 12h00 et que quelqu'un apporte des modifications aux données du tableau à 12h05 et que votre exportation de ce tableau se termine à 12h10, alors l'exportation ne contiendra aucune des modifications apportées. entre 12h00 et 12h10. Vous ne pouvez pas modifier ce comportement avec l'utilitaire d'exportation d'Oracle.
Le paramètre CONSISTENT contrôle si l’intégralité de l’exportation est cohérente, même entre les tables. Si CONSISTENT=N (valeur par défaut), alors l'exportation d'une table sera cohérente, mais des changements peuvent survenir entre les tables. Si CONSISTENT=Y, alors l'intégralité du fichier de vidage est cohérente avec le moment où vous avez démarré l'exportation.
À quoi sert l’option DIRECT=Y dans exp ?
Normalement, l'exportation suivra le processus de l'instruction SELECT, c'est-à-dire que les données du disque seront copiées dans le cache tampon, puis écrites dans le fichier de vidage. Lorsque nous utilisons un chemin direct en spécifiant DIRECT=Y dans la commande d'exportation, Oracle copie les données directement du disque vers PGA et à partir de là, elles sont écrites dans le fichier de vidage.
À quoi sert l’option COMPRESS dans exp ?
Si nous spécifions COMPRESS=y lors de l'exportation, alors au moment de la création de la table lors de l'importation, l'étendue INITIAL de la table serait aussi grande que la somme de toutes les étendues allouées à la table dans la base de données d'origine.
Si nous spécifions COMPRESS=n lors de l'exportation, lors de la création de la table lors de l'importation, elle utilisera les mêmes valeurs d'étendue INITIAL que dans la base de données d'origine.
Disons maintenant que j'ai une table de 100 Mo. Il y a eu quelques suppressions et mises à jour et seuls 50 Mo de données réelles sont présents. J'exporte la table avec COMPRESS=y et la recrée dans une autre base de données. Il résumera toutes les étendues et les attribuera comme étendue INITIALE lors de la création de la table. Il n'y a que 50 Mo de données dans le tableau, mais 100 Mo ont déjà été alloués. Si vous disposez d’un espace limité, ce n’est pas une très bonne option.
Si je fais avec COMPRESS=N et que j'importe ensuite la table, son étendue INITIAL sera aussi grande que l'étendue INITIAL dans la base de données d'origine et ensuite, si nécessaire, de nouvelles étendues seront allouées. Alors maintenant, ma table dans la nouvelle base de données aurait une taille d'environ 50 Mo.
Quels sont les problèmes IMP/EXP courants ?
ORA-00001 : Contrainte d'unicité… violée – Vous importez peut-être des lignes en double. Utilisez IGNORE=N pour ignorer les tables qui existent déjà (imp donnera une erreur si l'objet est recréé) ou la table pourrait être supprimée/tronquée et réimportée si nous devons effectuer une actualisation de la table.
IMP-00015 : L'instruction a échoué... l'objet existe déjà... - Utilisez le paramètre d'importation IGNORE=Y pour ignorer ces erreurs, mais soyez prudent car vous pourriez vous retrouver avec des lignes en double.
ORA-01555 : instantané trop ancien – demandez à vos utilisateurs d'arrêter de travailler pendant que vous exportez ou utilisez le paramètre CONSISTENT=NO (cependant, cette option pourrait créer d'éventuels problèmes de référentiel, car les tables ne sont pas exportées à partir d'un instantané dans le temps).
ORA-01562 : Échec de l'extension du segment d'annulation - Créez des segments d'annulation plus grands ou définissez le paramètre COMMIT=Y (avec un paramètre BUFFER approprié) lors de l'importation.
Quels sont les avantages de la technologie Data Pump ?
L’ancienne technologie d’exportation/importation était basée sur le client. La technologie Data Pump est purement basée sur un serveur. Tous les fichiers de vidage, journaux et autres sont créés par défaut sur le serveur. La technologie Data Pump offre plusieurs avantages par rapport aux utilitaires traditionnels d’exportation et d’importation de données.
Voici les principaux avantages de la technologie Data Pump :
Performances améliorées : Les avantages en termes de performances sont significatifs si vous transférez d'énormes
quantités de données.
Possibilité de redémarrer des tâches : vous pouvez facilement redémarrer des tâches bloquées en raison d'un manque d'espace ou ayant
échoué pour d'autres raisons. Vous pouvez également arrêter et redémarrer manuellement les tâches.
Capacités d'exécution parallèle : en spécifiant une valeur pour le paramètre PARALLEL, vous pouvez choisir le nombre de threads d'exécution actifs pour une tâche d'exportation de pompe de données ou d'importation de pompe de données.
Possibilité de s'attacher à des tâches en cours d'exécution : vous pouvez vous attacher à une tâche Data Pump en cours d'exécution et interagir avec
elle à partir d'un écran ou d'un emplacement différent. Cela vous permet de surveiller les travaux, ainsi que de modifier
certains paramètres de manière interactive. Data Pump fait partie intégrante du serveur de base de données Oracle
et, en tant que tel, il n'a pas besoin d'un client pour s'exécuter une fois qu'il démarre une tâche.
Possibilité d'estimer les besoins en espace : vous pouvez facilement estimer les besoins en espace pour
vos tâches d'exportation en utilisant la méthode BLOCKS par défaut ou la méthode ESTIMATES, avant d'exécuter
une tâche d'exportation réelle (voir la section « Paramètres d'exportation de Data Pump » plus loin dans ce chapitre pour
plus de détails. ).
Mode de fonctionnement réseau : une fois que vous avez créé des liens de base de données entre deux bases de données, vous pouvez
effectuer des exportations depuis une base de données distante directement vers un ensemble de fichiers de vidage. Vous pouvez également effectuer
des importations directes via le réseau à l'aide de liens de bases de données, sans utiliser de fichiers de vidage. Le
mode réseau est un moyen de transférer des données d'une base de données directement vers une autre base de données à
l'aide de liens de base de données et sans avoir besoin de les stocker sur disque.
Capacité d'importation de données à granularité fine : Oracle9i proposait uniquement le paramètre QUERY, qui
vous permettait de spécifier que l'utilitaire d'exportation extrayait une partie spécifiée des lignes d'une table. Avec la pompe de données,
vous avez accès à un arsenal d'options fines considérablement amélioré, grâce à de nouveaux paramètres
comme INCLUDE et EXCLUDE.
Capacités de remappage : lors d'une importation Data Pump, vous pouvez remapper les schémas et les espaces de table,
ainsi que les noms de fichiers, à l'aide des nouveaux paramètres REMAP_ *. Les fonctionnalités de remappage vous permettent
de modifier des objets pendant le processus d'importation de données en remplaçant les anciens attributs par de nouvelles
valeurs. Par exemple, le paramètre REMAP_SCHEMA vous permet de mapper l'ensemble du schéma de l'utilisateur HR
vers un nouvel utilisateur, OE. Le paramètre REMAP_SCHEMA est similaire au paramètre TOUSER dans l'ancien
utilitaire d'importation.
Comment améliorer les performances d'exp ?
1. Réglez le paramètre BUFFER sur une valeur élevée. La valeur par défaut est 256 Ko.
2. Arrêtez les applications inutiles pour libérer les ressources.
3. Si vous exécutez plusieurs sessions, assurez-vous qu'elles écrivent sur des disques différents.
4. N'exportez pas vers NFS (Network File Share). L'exportation sur disque est plus rapide.
5. Définissez le paramètre RECORDLENGTH sur une valeur élevée.
6. Utilisez DIRECT=yes (exportation en mode direct).
Comment améliorer les performances des diablotins ?
1. Placez le fichier à importer sur un disque séparé des fichiers de données.
2. Augmentez le DB_CACHE_SIZE.
3. Définissez LOG_BUFFER sur grande taille.
4. Arrêtez l'archivage redolog, si possible.
5. Utilisez COMMIT=n, si possible.
6. Réglez le paramètre BUFFER sur une valeur élevée. La valeur par défaut est 256 Ko.
7. Il est conseillé de supprimer les index avant l'importation pour accélérer le processus d'importation ou de définir INDEXES=N et de créer des index plus tard après l'importation. Les index peuvent facilement être recréés une fois les données importées avec succès.
8. Utilisez STATISTICS=NONE.
9. Désactivez les déclencheurs INSERT, car ils se déclenchent lors de l'importation.
10. Définissez le paramètre COMMIT_WRITE=NOWAIT (sous Oracle 10g) ou COMMIT_WAIT=NOWAIT (sous Oracle 11g) lors de l'importation.
Quels sont les modes d’exportation de datapump ?
vous pouvez effectuer des tâches d'exportation Data Pump dans plusieurs modes :
Mode d'exportation complète : vous utilisez le paramètre FULL lorsque vous souhaitez exporter l'intégralité de la base de données en
une seule session d'exportation. Vous avez besoin du rôle EXPORT_FULL_DATABASE pour utiliser ce mode.
Mode Schéma : Si vous souhaitez exporter les données et/ou objets d'un seul utilisateur uniquement, vous devez utiliser le
paramètre SCHEMAS.
Mode Tablespace : En utilisant le paramètre TABLESPACES, vous pouvez exporter toutes les tables dans un ou
plusieurs tablespaces. Si vous utilisez le paramètre TRANSPORT_TABLESPACES, vous pouvez exporter uniquement les
métadonnées des objets contenus dans un ou plusieurs tablespaces. Vous vous souviendrez peut-être que vous pouvez
exporter des tablespaces entre bases de données en exportant d'abord les métadonnées, en copiant les fichiers du
tablespace sur le serveur cible, puis en important les métadonnées dans la base de données cible.
Mode tableau : En utilisant le paramètre TABLES, vous pouvez exporter un ou plusieurs tableaux. Le paramètre TABLES
est identique au paramètre TABLES de l'ancien utilitaire d'exportation.
Qu'est-ce que le paramètre COMPRESSION dans expdp ?
Le paramètre COMPRESSION permet à l'utilisateur de spécifier les données à compresser avant d'écrire les données d'exportation dans un fichier de vidage. Par défaut, toutes les métadonnées sont compressées avant d'être écrites dans un fichier de vidage d'exportation. Vous pouvez désactiver la compression en spécifiant la valeur NONE pour le paramètre COMPRESSION, comme indiqué ici :
$ expdp hr/hr DIRECTORY=dpump_dir1 DUMPFILE=hr_comp.dmp COMPRESSION=NONE
Le paramètre COMPRESSION peut prendre l'une des quatre valeurs suivantes :
ALL : active compression pour toute l’opération.
DATA_ONLY : spécifie que toutes les données doivent être écrites dans le fichier de vidage dans un format compressé.
METADATA_ONLY : spécifie que toutes les métadonnées doivent être écrites dans le fichier de vidage dans un format compressé.
Ceci est la valeur par défault.
NONE : désactive la compression de tous les types.
Que sont les paramètres de filtrage des exportations dans expdp ?
Data Pump contient plusieurs paramètres liés au filtrage des exportations. Certains d’entre eux remplacent les anciens paramètres d’exportation ; d'autres offrent de nouvelles fonctionnalités.
CONTENT
En utilisant le paramètre CONTENT, vous pouvez filtrer ce qui entre dans le fichier de vidage d'exportation. Le
paramètre CONTENT peut prendre trois valeurs :
• ALL exporte à la fois les données de table et les définitions de table et d'autres objets (métadonnées).
• DATA_ONLY exporte uniquement les lignes du tableau.
• METADATA_ONLY exporte uniquement les métadonnées.
EXCLUDE et INCLUDE
Les paramètres EXCLUDE et INCLUDE sont deux paramètres mutuellement exclusifs que vous pouvez utiliser pour effectuer ce que l'on appelle le filtrage des métadonnées. Le filtrage des métadonnées vous permet d'omettre ou d'inclure de manière sélective certains types d'objets lors d'une tâche d'exportation ou d'importation de Data Pump. Dans l'ancien utilitaire d'exportation, vous utilisiez les paramètres CONSTRAINTS, GRANTS et INDEXES pour spécifier si vous souhaitiez exporter ces objets. À l'aide des paramètres EXCLUDE et INCLUDE, vous pouvez désormais inclure ou exclure de nombreux autres types d'objets en plus des quatre objets que vous pouviez filtrer précédemment. Par exemple, si vous ne souhaitez exporter aucun package lors de l'export, vous pouvez le spécifier à l'aide du paramètre EXCLUDE.
QUERY
Le paramètre QUERY remplit la même fonction que dans l'utilitaire d'exportation traditionnel : il vous permet d'exporter de manière sélective les données des lignes d'un tableau à l'aide d'une instruction SQL. Le paramètre QUERY permet de qualifier l'instruction SQL avec un nom de table, afin qu'elle s'applique uniquement à une table particulière. Voici un exemple :
QUERY=OE.ORDERS : "WHERE order_id > 100 000"
Dans cet exemple, seules les lignes de la table des commandes (appartenant à l'utilisateur OE) où l'order_id est
supérieur à 100 000 sont exportées.
Qu'est-ce que le paramètre de liaison réseau et comment fonctionne-t-il ?
L'utilitaire Data Pump Export permet de lancer une exportation réseau. À l'aide du paramètre NETWORK_LINK, vous pouvez lancer une tâche d'exportation à partir de votre serveur et demander à Data Pump d'exporter des données à partir d'une base de données distante pour vider les fichiers situés sur l'instance à partir de laquelle vous lancez la tâche d'exportation Data Pump.
Voici un exemple qui vous montre comment effectuer une exportation réseau :
$ expdp hr/hr DIRECTORY=dpump_dir1 NETWORK_LINK=finance
DUMPFILE=network_export.dmp LOGFILE=network_export.log
Dans l'exemple, le paramètre NETWORK_LINK doit avoir un lien de base de données valide comme valeur . Cela
signifie que vous devez avoir créé le lien vers la base de données au préalable. Cet exemple exporte les données de la base de données financière sur le serveur prod1.
Disons que vous disposez de deux bases de données, appelées locale et distante. Pour utiliser le paramètre NETWORK_LINK et transmettre des données directement sur le réseau, procédez comme suit :
1. Créez un lien de base de données vers la base de données distante, nommée distante dans cet exemple :
SQL> CREATE DATABASE LINK distant
CONNECT TO scott IDENTIFIED BY Tiger
UTILISER « remote.world » ;
2. S'il n'y en a pas déjà un, créez un objet répertoire Data Pump :
SQL> CREATE DIRECTORY remote_dir1 AS '/u01/app/oracle/dp_dir';
3. Définissez le nouveau répertoire comme répertoire par défaut en exportant la valeur du répertoire :
$ export DATA_PUMP_DIR=remote_dir1
4. Effectuez l'exportation réseau à partir de la base de données nommée distante :
$ expdp system/sammyy1 SCHEMAS=SCOTT FILE_NAME=network.dmp NETWORK_LINK=finance
Vous verrez que le travail d'exportation de Data Pump créera le fichier de vidage network.dmp (dans l'emplacement du répertoire spécifié par remote_dir1) sur le serveur hébergeant la base de données nommée local. Cependant, les données contenues dans le fichier dump sont extraites du schéma de l'utilisateur Scott dans la base de données distante (nommée distante dans notre exemple). Vous pouvez voir que le paramètre NETWORK_LINK transporte les fichiers de vidage sur le réseau depuis un emplacement distant vers le serveur local. Tout ce dont vous avez besoin est un lien de base de données depuis une base de données sur le serveur local vers la base de données source sur le serveur distant.
À quoi sert l’option INDEXFILE dans imp ?
Écrira les DDL des objets du fichier dump dans le fichier spécifié.
À quoi sert l’option IGNORE dans Imp ?
Ignorera les erreurs lors de l'importation et poursuivra l'importation.
Quelles sont les différences entre expdp et exp (Data Pump ou exp/imp normal) ?
Data Pump est centré sur le serveur (les fichiers seront sur le serveur).
Data Pump dispose d'API, à partir de procédures, nous pouvons exécuter des tâches Data Pump.
Dans Data Pump, nous pouvons arrêter et redémarrer les tâches.
Data Pump effectuera une exécution parallèle.
Les bandes et les tuyaux ne sont pas pris en charge dans Data Pump.
Data Pump consomme plus d'espace table d'annulation.
L’importation Data Pump créera l’utilisateur, si l’utilisateur n’existe pas.
Pourquoi expdp est plus rapide que exp (ou) pourquoi Data Pump est plus rapide que l'exportation/importation conventionnelle ?
Data Pump est en mode bloc, exp est en mode octet.
Data Pump effectuera une exécution parallèle.
Data Pump utilise l'API de chemin direct.
Comment améliorer les performances d'expdp ?
Utilisation d'une option parallèle qui augmente les threads de travail. Cela doit être défini en fonction du nombre de processeurs.
Comment améliorer les performances d'impdp ?
Utilisation d'une option parallèle qui augmente les threads de travail. Cela doit être défini en fonction du nombre de processeurs.
Dans Data Pump, où les informations sur les tâches seront stockées (ou) si vous redémarrez une tâche dans Data Pump, comment saura-t-elle d'où reprendre ?
Chaque fois que l'exportation ou l'importation de Data Pump est en cours d'exécution, Oracle crée une table avec le JOB_NAME et sera supprimée une fois le travail terminé. À partir de ce tableau, Oracle découvrira la quantité de travail terminée et où continuer, etc.
Le nom du travail d'exportation par défaut sera SYS_EXPORT_XXXX_01, où XXXX peut être FULL ou SCHEMA ou TABLE.
Le nom de la tâche d'importation par défaut sera SYS_IMPORT_XXXX_01, où XXXX peut être FULL ou SCHEMA ou TABLE.
Quel est l’ordre d’importation des objets dans impdp ?
Tablespaces
Utilisateurs
Rôles
Liens base de données
Séquences
Répertoires
Synonymes
Types
Tables/Partitions
Vues
Commentaires
Packages/Procédures/Fonctions
Vues matérialisées
Comment importer uniquement des métadonnées ?
CONTENT= METADATA_ONLY
Comment importer dans différents utilisateurs/tablespace/fichier de données/table ?
REMAP_SCHEMA
REMAP_TABLESPACE
REMAP_DATAFILE
REMAP_TABLE
REMAP_DATA
Lorsque vous exportez une table, vous avez la garantie que le contenu de cette table sera cohérent avec l'heure à laquelle l'exportation de cette table a commencé. Cela signifie que si vous commencez à exporter le tableau à 12h00 et que quelqu'un apporte des modifications aux données du tableau à 12h05 et que votre exportation de ce tableau se termine à 12h10, alors l'exportation ne contiendra aucune des modifications apportées. entre 12h00 et 12h10. Vous ne pouvez pas modifier ce comportement avec l'utilitaire d'exportation d'Oracle.
Le paramètre CONSISTENT contrôle si l’intégralité de l’exportation est cohérente, même entre les tables. Si CONSISTENT=N (valeur par défaut), alors l'exportation d'une table sera cohérente, mais des changements peuvent survenir entre les tables. Si CONSISTENT=Y, alors l'intégralité du fichier de vidage est cohérente avec le moment où vous avez démarré l'exportation.
À quoi sert l’option DIRECT=Y dans exp ?
Normalement, l'exportation suivra le processus de l'instruction SELECT, c'est-à-dire que les données du disque seront copiées dans le cache tampon, puis écrites dans le fichier de vidage. Lorsque nous utilisons un chemin direct en spécifiant DIRECT=Y dans la commande d'exportation, Oracle copie les données directement du disque vers PGA et à partir de là, elles sont écrites dans le fichier de vidage.
À quoi sert l’option COMPRESS dans exp ?
Si nous spécifions COMPRESS=y lors de l'exportation, alors au moment de la création de la table lors de l'importation, l'étendue INITIAL de la table serait aussi grande que la somme de toutes les étendues allouées à la table dans la base de données d'origine.
Si nous spécifions COMPRESS=n lors de l'exportation, lors de la création de la table lors de l'importation, elle utilisera les mêmes valeurs d'étendue INITIAL que dans la base de données d'origine.
Disons maintenant que j'ai une table de 100 Mo. Il y a eu quelques suppressions et mises à jour et seuls 50 Mo de données réelles sont présents. J'exporte la table avec COMPRESS=y et la recrée dans une autre base de données. Il résumera toutes les étendues et les attribuera comme étendue INITIALE lors de la création de la table. Il n'y a que 50 Mo de données dans le tableau, mais 100 Mo ont déjà été alloués. Si vous disposez d’un espace limité, ce n’est pas une très bonne option.
Si je fais avec COMPRESS=N et que j'importe ensuite la table, son étendue INITIAL sera aussi grande que l'étendue INITIAL dans la base de données d'origine et ensuite, si nécessaire, de nouvelles étendues seront allouées. Alors maintenant, ma table dans la nouvelle base de données aurait une taille d'environ 50 Mo.
Quels sont les problèmes IMP/EXP courants ?
ORA-00001 : Contrainte d'unicité… violée – Vous importez peut-être des lignes en double. Utilisez IGNORE=N pour ignorer les tables qui existent déjà (imp donnera une erreur si l'objet est recréé) ou la table pourrait être supprimée/tronquée et réimportée si nous devons effectuer une actualisation de la table.
IMP-00015 : L'instruction a échoué... l'objet existe déjà... - Utilisez le paramètre d'importation IGNORE=Y pour ignorer ces erreurs, mais soyez prudent car vous pourriez vous retrouver avec des lignes en double.
ORA-01555 : instantané trop ancien – demandez à vos utilisateurs d'arrêter de travailler pendant que vous exportez ou utilisez le paramètre CONSISTENT=NO (cependant, cette option pourrait créer d'éventuels problèmes de référentiel, car les tables ne sont pas exportées à partir d'un instantané dans le temps).
ORA-01562 : Échec de l'extension du segment d'annulation - Créez des segments d'annulation plus grands ou définissez le paramètre COMMIT=Y (avec un paramètre BUFFER approprié) lors de l'importation.
Quels sont les avantages de la technologie Data Pump ?
L’ancienne technologie d’exportation/importation était basée sur le client. La technologie Data Pump est purement basée sur un serveur. Tous les fichiers de vidage, journaux et autres sont créés par défaut sur le serveur. La technologie Data Pump offre plusieurs avantages par rapport aux utilitaires traditionnels d’exportation et d’importation de données.
Voici les principaux avantages de la technologie Data Pump :
Performances améliorées : Les avantages en termes de performances sont significatifs si vous transférez d'énormes
quantités de données.
Possibilité de redémarrer des tâches : vous pouvez facilement redémarrer des tâches bloquées en raison d'un manque d'espace ou ayant
échoué pour d'autres raisons. Vous pouvez également arrêter et redémarrer manuellement les tâches.
Capacités d'exécution parallèle : en spécifiant une valeur pour le paramètre PARALLEL, vous pouvez choisir le nombre de threads d'exécution actifs pour une tâche d'exportation de pompe de données ou d'importation de pompe de données.
Possibilité de s'attacher à des tâches en cours d'exécution : vous pouvez vous attacher à une tâche Data Pump en cours d'exécution et interagir avec
elle à partir d'un écran ou d'un emplacement différent. Cela vous permet de surveiller les travaux, ainsi que de modifier
certains paramètres de manière interactive. Data Pump fait partie intégrante du serveur de base de données Oracle
et, en tant que tel, il n'a pas besoin d'un client pour s'exécuter une fois qu'il démarre une tâche.
Possibilité d'estimer les besoins en espace : vous pouvez facilement estimer les besoins en espace pour
vos tâches d'exportation en utilisant la méthode BLOCKS par défaut ou la méthode ESTIMATES, avant d'exécuter
une tâche d'exportation réelle (voir la section « Paramètres d'exportation de Data Pump » plus loin dans ce chapitre pour
plus de détails. ).
Mode de fonctionnement réseau : une fois que vous avez créé des liens de base de données entre deux bases de données, vous pouvez
effectuer des exportations depuis une base de données distante directement vers un ensemble de fichiers de vidage. Vous pouvez également effectuer
des importations directes via le réseau à l'aide de liens de bases de données, sans utiliser de fichiers de vidage. Le
mode réseau est un moyen de transférer des données d'une base de données directement vers une autre base de données à
l'aide de liens de base de données et sans avoir besoin de les stocker sur disque.
Capacité d'importation de données à granularité fine : Oracle9i proposait uniquement le paramètre QUERY, qui
vous permettait de spécifier que l'utilitaire d'exportation extrayait une partie spécifiée des lignes d'une table. Avec la pompe de données,
vous avez accès à un arsenal d'options fines considérablement amélioré, grâce à de nouveaux paramètres
comme INCLUDE et EXCLUDE.
Capacités de remappage : lors d'une importation Data Pump, vous pouvez remapper les schémas et les espaces de table,
ainsi que les noms de fichiers, à l'aide des nouveaux paramètres REMAP_ *. Les fonctionnalités de remappage vous permettent
de modifier des objets pendant le processus d'importation de données en remplaçant les anciens attributs par de nouvelles
valeurs. Par exemple, le paramètre REMAP_SCHEMA vous permet de mapper l'ensemble du schéma de l'utilisateur HR
vers un nouvel utilisateur, OE. Le paramètre REMAP_SCHEMA est similaire au paramètre TOUSER dans l'ancien
utilitaire d'importation.
Comment améliorer les performances d'exp ?
1. Réglez le paramètre BUFFER sur une valeur élevée. La valeur par défaut est 256 Ko.
2. Arrêtez les applications inutiles pour libérer les ressources.
3. Si vous exécutez plusieurs sessions, assurez-vous qu'elles écrivent sur des disques différents.
4. N'exportez pas vers NFS (Network File Share). L'exportation sur disque est plus rapide.
5. Définissez le paramètre RECORDLENGTH sur une valeur élevée.
6. Utilisez DIRECT=yes (exportation en mode direct).
Comment améliorer les performances des diablotins ?
1. Placez le fichier à importer sur un disque séparé des fichiers de données.
2. Augmentez le DB_CACHE_SIZE.
3. Définissez LOG_BUFFER sur grande taille.
4. Arrêtez l'archivage redolog, si possible.
5. Utilisez COMMIT=n, si possible.
6. Réglez le paramètre BUFFER sur une valeur élevée. La valeur par défaut est 256 Ko.
7. Il est conseillé de supprimer les index avant l'importation pour accélérer le processus d'importation ou de définir INDEXES=N et de créer des index plus tard après l'importation. Les index peuvent facilement être recréés une fois les données importées avec succès.
8. Utilisez STATISTICS=NONE.
9. Désactivez les déclencheurs INSERT, car ils se déclenchent lors de l'importation.
10. Définissez le paramètre COMMIT_WRITE=NOWAIT (sous Oracle 10g) ou COMMIT_WAIT=NOWAIT (sous Oracle 11g) lors de l'importation.
Quels sont les modes d’exportation de datapump ?
vous pouvez effectuer des tâches d'exportation Data Pump dans plusieurs modes :
Mode d'exportation complète : vous utilisez le paramètre FULL lorsque vous souhaitez exporter l'intégralité de la base de données en
une seule session d'exportation. Vous avez besoin du rôle EXPORT_FULL_DATABASE pour utiliser ce mode.
Mode Schéma : Si vous souhaitez exporter les données et/ou objets d'un seul utilisateur uniquement, vous devez utiliser le
paramètre SCHEMAS.
Mode Tablespace : En utilisant le paramètre TABLESPACES, vous pouvez exporter toutes les tables dans un ou
plusieurs tablespaces. Si vous utilisez le paramètre TRANSPORT_TABLESPACES, vous pouvez exporter uniquement les
métadonnées des objets contenus dans un ou plusieurs tablespaces. Vous vous souviendrez peut-être que vous pouvez
exporter des tablespaces entre bases de données en exportant d'abord les métadonnées, en copiant les fichiers du
tablespace sur le serveur cible, puis en important les métadonnées dans la base de données cible.
Mode tableau : En utilisant le paramètre TABLES, vous pouvez exporter un ou plusieurs tableaux. Le paramètre TABLES
est identique au paramètre TABLES de l'ancien utilitaire d'exportation.
Qu'est-ce que le paramètre COMPRESSION dans expdp ?
Le paramètre COMPRESSION permet à l'utilisateur de spécifier les données à compresser avant d'écrire les données d'exportation dans un fichier de vidage. Par défaut, toutes les métadonnées sont compressées avant d'être écrites dans un fichier de vidage d'exportation. Vous pouvez désactiver la compression en spécifiant la valeur NONE pour le paramètre COMPRESSION, comme indiqué ici :
$ expdp hr/hr DIRECTORY=dpump_dir1 DUMPFILE=hr_comp.dmp COMPRESSION=NONE
Le paramètre COMPRESSION peut prendre l'une des quatre valeurs suivantes :
ALL : active compression pour toute l’opération.
DATA_ONLY : spécifie que toutes les données doivent être écrites dans le fichier de vidage dans un format compressé.
METADATA_ONLY : spécifie que toutes les métadonnées doivent être écrites dans le fichier de vidage dans un format compressé.
Ceci est la valeur par défault.
NONE : désactive la compression de tous les types.
Que sont les paramètres de filtrage des exportations dans expdp ?
Data Pump contient plusieurs paramètres liés au filtrage des exportations. Certains d’entre eux remplacent les anciens paramètres d’exportation ; d'autres offrent de nouvelles fonctionnalités.
CONTENT
En utilisant le paramètre CONTENT, vous pouvez filtrer ce qui entre dans le fichier de vidage d'exportation. Le
paramètre CONTENT peut prendre trois valeurs :
• ALL exporte à la fois les données de table et les définitions de table et d'autres objets (métadonnées).
• DATA_ONLY exporte uniquement les lignes du tableau.
• METADATA_ONLY exporte uniquement les métadonnées.
EXCLUDE et INCLUDE
Les paramètres EXCLUDE et INCLUDE sont deux paramètres mutuellement exclusifs que vous pouvez utiliser pour effectuer ce que l'on appelle le filtrage des métadonnées. Le filtrage des métadonnées vous permet d'omettre ou d'inclure de manière sélective certains types d'objets lors d'une tâche d'exportation ou d'importation de Data Pump. Dans l'ancien utilitaire d'exportation, vous utilisiez les paramètres CONSTRAINTS, GRANTS et INDEXES pour spécifier si vous souhaitiez exporter ces objets. À l'aide des paramètres EXCLUDE et INCLUDE, vous pouvez désormais inclure ou exclure de nombreux autres types d'objets en plus des quatre objets que vous pouviez filtrer précédemment. Par exemple, si vous ne souhaitez exporter aucun package lors de l'export, vous pouvez le spécifier à l'aide du paramètre EXCLUDE.
QUERY
Le paramètre QUERY remplit la même fonction que dans l'utilitaire d'exportation traditionnel : il vous permet d'exporter de manière sélective les données des lignes d'un tableau à l'aide d'une instruction SQL. Le paramètre QUERY permet de qualifier l'instruction SQL avec un nom de table, afin qu'elle s'applique uniquement à une table particulière. Voici un exemple :
QUERY=OE.ORDERS : "WHERE order_id > 100 000"
Dans cet exemple, seules les lignes de la table des commandes (appartenant à l'utilisateur OE) où l'order_id est
supérieur à 100 000 sont exportées.
Qu'est-ce que le paramètre de liaison réseau et comment fonctionne-t-il ?
L'utilitaire Data Pump Export permet de lancer une exportation réseau. À l'aide du paramètre NETWORK_LINK, vous pouvez lancer une tâche d'exportation à partir de votre serveur et demander à Data Pump d'exporter des données à partir d'une base de données distante pour vider les fichiers situés sur l'instance à partir de laquelle vous lancez la tâche d'exportation Data Pump.
Voici un exemple qui vous montre comment effectuer une exportation réseau :
$ expdp hr/hr DIRECTORY=dpump_dir1 NETWORK_LINK=finance
DUMPFILE=network_export.dmp LOGFILE=network_export.log
Dans l'exemple, le paramètre NETWORK_LINK doit avoir un lien de base de données valide comme valeur . Cela
signifie que vous devez avoir créé le lien vers la base de données au préalable. Cet exemple exporte les données de la base de données financière sur le serveur prod1.
Disons que vous disposez de deux bases de données, appelées locale et distante. Pour utiliser le paramètre NETWORK_LINK et transmettre des données directement sur le réseau, procédez comme suit :
1. Créez un lien de base de données vers la base de données distante, nommée distante dans cet exemple :
SQL> CREATE DATABASE LINK distant
CONNECT TO scott IDENTIFIED BY Tiger
UTILISER « remote.world » ;
2. S'il n'y en a pas déjà un, créez un objet répertoire Data Pump :
SQL> CREATE DIRECTORY remote_dir1 AS '/u01/app/oracle/dp_dir';
3. Définissez le nouveau répertoire comme répertoire par défaut en exportant la valeur du répertoire :
$ export DATA_PUMP_DIR=remote_dir1
4. Effectuez l'exportation réseau à partir de la base de données nommée distante :
$ expdp system/sammyy1 SCHEMAS=SCOTT FILE_NAME=network.dmp NETWORK_LINK=finance
Vous verrez que le travail d'exportation de Data Pump créera le fichier de vidage network.dmp (dans l'emplacement du répertoire spécifié par remote_dir1) sur le serveur hébergeant la base de données nommée local. Cependant, les données contenues dans le fichier dump sont extraites du schéma de l'utilisateur Scott dans la base de données distante (nommée distante dans notre exemple). Vous pouvez voir que le paramètre NETWORK_LINK transporte les fichiers de vidage sur le réseau depuis un emplacement distant vers le serveur local. Tout ce dont vous avez besoin est un lien de base de données depuis une base de données sur le serveur local vers la base de données source sur le serveur distant.
Écrira les DDL des objets du fichier dump dans le fichier spécifié.
À quoi sert l’option IGNORE dans Imp ?
Ignorera les erreurs lors de l'importation et poursuivra l'importation.
Quelles sont les différences entre expdp et exp (Data Pump ou exp/imp normal) ?
Data Pump est centré sur le serveur (les fichiers seront sur le serveur).
Data Pump dispose d'API, à partir de procédures, nous pouvons exécuter des tâches Data Pump.
Dans Data Pump, nous pouvons arrêter et redémarrer les tâches.
Data Pump effectuera une exécution parallèle.
Les bandes et les tuyaux ne sont pas pris en charge dans Data Pump.
Data Pump consomme plus d'espace table d'annulation.
L’importation Data Pump créera l’utilisateur, si l’utilisateur n’existe pas.
Pourquoi expdp est plus rapide que exp (ou) pourquoi Data Pump est plus rapide que l'exportation/importation conventionnelle ?
Data Pump est en mode bloc, exp est en mode octet.
Data Pump effectuera une exécution parallèle.
Data Pump utilise l'API de chemin direct.
Comment améliorer les performances d'expdp ?
Utilisation d'une option parallèle qui augmente les threads de travail. Cela doit être défini en fonction du nombre de processeurs.
Comment améliorer les performances d'impdp ?
Utilisation d'une option parallèle qui augmente les threads de travail. Cela doit être défini en fonction du nombre de processeurs.
Dans Data Pump, où les informations sur les tâches seront stockées (ou) si vous redémarrez une tâche dans Data Pump, comment saura-t-elle d'où reprendre ?
Chaque fois que l'exportation ou l'importation de Data Pump est en cours d'exécution, Oracle crée une table avec le JOB_NAME et sera supprimée une fois le travail terminé. À partir de ce tableau, Oracle découvrira la quantité de travail terminée et où continuer, etc.
Le nom du travail d'exportation par défaut sera SYS_EXPORT_XXXX_01, où XXXX peut être FULL ou SCHEMA ou TABLE.
Le nom de la tâche d'importation par défaut sera SYS_IMPORT_XXXX_01, où XXXX peut être FULL ou SCHEMA ou TABLE.
Quel est l’ordre d’importation des objets dans impdp ?
Tablespaces
Utilisateurs
Rôles
Liens base de données
Séquences
Répertoires
Synonymes
Types
Tables/Partitions
Vues
Commentaires
Packages/Procédures/Fonctions
Vues matérialisées
Comment importer uniquement des métadonnées ?
CONTENT= METADATA_ONLY
Comment importer dans différents utilisateurs/tablespace/fichier de données/table ?
REMAP_SCHEMA
REMAP_TABLESPACE
REMAP_DATAFILE
REMAP_TABLE
REMAP_DATA
Questions et réponses d'entretien avec Oracle DBA - Sauvegarde et récupération
Quelle est la différence entre la restauration et la récupération de la base de données ?
La restauration signifie copier l'objet de base de données du support de sauvegarde vers la destination où cela est réellement nécessaire, tandis que la récupération signifie appliquer l'objet de base de données copié précédemment (roll forward) afin de mettre la base de données dans un état cohérent.
Quelle est la différence entre une guérison complète et incomplète ?
Une récupération de base de données incomplète est une récupération qui n’atteint pas le point de défaillance. La récupération peut être soit un point dans le temps, soit un SCN particulier ou un journal d'archive particulier, spécialement en cas de journal d'archive manquant ou d'échec de redolog, alors qu'une récupération complète récupère jusqu'au point de défaillance, éventuellement lors de la sauvegarde de tous les journaux d'archive.
Comment décideriez-vous de votre stratégie de sauvegarde et du calendrier de sauvegarde ?
En fait, la stratégie de sauvegarde dépend uniquement des besoins commerciaux de votre organisation.
S'il n'y a pas de temps d'arrêt, la base de données doit être exécutée en mode archivelog et vous devez effectuer des sauvegardes fréquentes ou quotidiennes.
Si le temps d'arrêt est suffisant et que la perte de données n'affectera pas votre entreprise, vous pouvez exécuter votre base de données en mode noarchivelog et la sauvegarde peut être effectuée fréquemment, hebdomadairement ou mensuellement.
Dans la plupart des cas, dans une organisation où aucun temps d'arrêt, une sauvegarde incohérente fréquente n'est nécessaire (sauvegarde quotidienne), des fichiers de journalisation en ligne multiplexés (plusieurs copies), un emplacement différent pour les fichiers de journalisation, la base de données doit fonctionner en mode archivelog et dataguard peut être implémenté pour un peu de protection supplémentaire.
Quel est l'avantage d'exécuter la base de données en mode archivelog par rapport au mode sans archivelog ?
Lorsqu'une base de données n'est pas en mode archivelog, chaque fois que le changement de journal se produit, certaines informations de journalisation seront perdues. Afin d'éviter cela, les journaux redo doivent être archivés. Ceci peut être réalisé en configurant la base de données en mode archivelog.
Si une base de données Oracle tombe en panne ? Comment récupéreriez-vous cette transaction qui n’est pas en sauvegarde ?
Si la base de données est dans le journal d'archives, nous pouvons récupérer cette transaction, sinon nous ne pouvons pas récupérer cette transaction qui n'est pas en sauvegarde.
Quelle est la différence entre la sauvegarde HOTBACKUP et la sauvegarde RMAN ?
Pour la sauvegarde à chaud, nous devons mettre la base de données en mode de début de sauvegarde, puis effectuer une sauvegarde alors que RMAN ne mettrait pas la base de données en mode de début de sauvegarde. RMAN est plus rapide, peut effectuer une sauvegarde incrémentielle (modifications uniquement) et ne place pas l'espace table en mode de sauvegarde à chaud.
Pouvons-nous utiliser la même base de données cible que la base de données du catalogue ?
Non, le catalogue de récupération ne doit pas résider dans la base de données cible (base de données à sauvegarder) car la base de données ne peut pas être récupérée à l'état monté.
Niveaux de sauvegarde incrémentielle :
Niveau 0 – sauvegarde complète qui peut être utilisée pour les incréments ultérieurs
RMAN> sauvegarde incrémentielle de niveau 0 de la base de données ;
Différentiel niveau 1 – uniquement les blocs qui ont changé depuis la dernière sauvegarde (qu'elle soit de niveau 0 ou de niveau 1)
RMAN> sauvegarde incrémentielle de niveau 1 de la base de données différentielle ;
Niveau cumulatif 1 – toutes les modifications depuis la dernière sauvegarde incrémentielle de niveau 0
RMAN> sauvegarde de la base de données cumulative de niveau 1 ;
Une sauvegarde complète ne peut pas être utilisée pour une sauvegarde cumulative de niveau 1.
Une sauvegarde cumulative de niveau 1 doit être effectuée en plus d'une sauvegarde incrémentielle de niveau 0.
Pourquoi la sauvegarde incrémentielle RMAN échoue même si une sauvegarde complète existe ?
Si vous avez effectué la sauvegarde complète RMAN à l'aide de la commande « Sauvegarder la base de données », alors qu'une sauvegarde de niveau 0 est physiquement identique à une sauvegarde complète. La seule différence est que la sauvegarde de niveau 0 est enregistrée en tant que sauvegarde incrémentielle dans le référentiel RMAN afin qu'elle puisse être utilisée comme parent pour une sauvegarde de niveau 1. Simplement, la « sauvegarde complète sans niveau 0 » ne peut pas être considérée comme une sauvegarde parent à partir de laquelle vous pouvez effectuer une sauvegarde de niveau 1.
Pouvons-nous effectuer une sauvegarde RMAN niveau 1 sans niveau 0 ?
Si aucun niveau 0 n'est disponible, le comportement dépend du paramètre de mode de compatibilité (version Oracle).
Si le mode de compatibilité est inférieur à 10.0.0, RMAN génère une sauvegarde de niveau 0 du contenu des fichiers au moment de la sauvegarde.
Si la compatibilité est supérieure à 10.0.0, RMAN copie toutes les modifications de bloc depuis la création du fichier et stocke les résultats sous forme de sauvegarde de niveau 1.
Comment mettre une sauvegarde manuelle/gérée par l'utilisateur dans RMAN ?
En cas de catalogue de récupération, vous pouvez le placer à l'aide de la commande catalog :
RMAN> CATALOG START WITH '/oracle/backup.ctl' ;
Comment vérifier la version RMAN dans Oracle ?
Si vous souhaitez vérifier la version du catalogue RMAN, utilisez la requête ci-dessous depuis SQL*plus
SQL> Select * from rcver ;
Que se passe-t-il réellement en cas de récupération d'instance ?
En cas d'échec de l'instance Oracle, Oracle effectue une récupération d'instance lorsque la base de données associée est redémarrée. La récupération d'instance se déroule en 2 étapes :
Récupération du cache : les modifications apportées à une base de données sont enregistrées simultanément dans le cache tampon de la base de données ainsi que dans les fichiers de journalisation. Lorsqu'il y a suffisamment de données dans le cache du tampon de base de données, elles sont écrites dans des fichiers de données. Si une instance Oracle échoue avant que ces données ne soient écrites dans des fichiers de données, Oracle utilise des fichiers de journalisation en ligne pour récupérer les données perdues au redémarrage de la base de données associée. Ce processus est appelé récupération du cache.
Récupération de transaction : lorsqu'une transaction modifie des données dans une base de données (l'image avant des données modifiées est stockée dans un segment d'annulation qui est utilisé pour restaurer les valeurs d'origine au cas où la transaction serait annulée). Au moment d'une panne d'instance, la base de données peut contenir des transactions non validées. Il est possible que les modifications apportées par ces transactions non validées aient été enregistrées dans des fichiers de données. Pour maintenir la cohérence de la lecture, Oracle annule toutes les transactions non validées lorsque la base de données associée est redémarrée. Oracle utilise les données d'annulation stockées dans les segments d'annulation pour ce faire. Ce processus est appelé récupération de transaction.
Qu’est-ce que RMAN ?
Recovery Manager (RMAN) est un utilitaire qui peut gérer l'ensemble de vos activités de sauvegarde et de récupération Oracle.
Quelle est la différence entre l’utilisation du catalogue de récupération et du fichier de contrôle ?
Lorsqu'une nouvelle incarnation se produit, les anciennes informations de sauvegarde dans le fichier de contrôle seront perdues. Il sera conservé dans le catalogue de récupération.
Dans le catalogue de récupération, nous pouvons stocker des scripts.
Le catalogue de récupération est central et peut contenir des informations sur de nombreuses bases de données.
Pouvons-nous utiliser la même base de données cible que le catalogue ?
Non, le catalogue de récupération ne doit pas résider dans la base de données cible (la base de données doit être sauvegardée), car la base de données ne peut pas être récupérée à l'état monté.
Comment savez-vous combien de tâches RMAN ont été accomplies ?
En interrogeant v$rman_status ou v$session_longops.
D'où les commandes de liste et de rapport recevront-elles des entrées ?
Les commandes commandent l'interrogation de v$ et les vues du catalogue de récupération. V$BACKUP_FILES ou de nombreuses vues du catalogue de récupération telles que RC_DATAFILE_COPY ou RC_ARCHIVED_LOG.
Commande pour supprimer les journaux d'archives datant de plus de 7 jours ?
RMAN> supprimer l'archivelog terminé avant sysdate-7 ;
Combien de fois Oracle demande-t-il avant de supprimer un catalogue ?
La valeur par défaut est deux fois, une pour la commande réelle, l'autre pour la confirmation.
Comment afficher les valeurs par défaut actuelles de la base de données.
RMAN> afficher tout ;
À quoi sert la commande crosscheck dans RMAN ?
Un contrôle croisé sera utile pour vérifier si les informations du catalogue sont intactes avec les informations au niveau du système d'exploitation. Cette commande met uniquement à jour les enregistrements du référentiel avec l'état des sauvegardes.
Par exemple, si l'utilisateur supprime les journaux archivés du disque avec une commande du système d'exploitation, le référentiel indique toujours que les journaux sont sur le disque, alors qu'en réalité ils ne le sont pas.
Quelles sont les différences entre les commandes crosscheck et validate ?
La commande Validate consiste à examiner un jeu de sauvegarde et à indiquer s'il peut être restauré. RMAN analyse tous les éléments de sauvegarde dans les jeux de sauvegarde spécifiés et examine la somme de contrôle pour vérifier que le contenu est intact afin que la sauvegarde puisse être restaurée avec succès si nécessaire.
La commande Crosscheck consiste à vérifier l'état des sauvegardes et des copies enregistrées dans le référentiel RMAN par rapport à un support tel qu'un disque ou une bande. La commande crosscheck traite uniquement les fichiers créés sur le même type de périphérique que le canal exécutant crosscheck.
Laquelle est la bonne sauvegarde : une sauvegarde différentielle (incrémentale) ou une sauvegarde cumulative (incrémentale) ?
Une sauvegarde différentielle, qui sauvegarde tous les blocs modifiés après la sauvegarde incrémentielle la plus récente au niveau 1 ou 0
RMAN> SAUVEGARDE INCREMENTALE NIVEAU 1 BASE DE DONNÉES ;
Une sauvegarde cumulative, qui sauvegarde tous les blocs modifiés après la sauvegarde incrémentielle la plus récente au niveau 0
RMAN> SAUVEGARDE INCREMENTALE NIVEAU 1 BASE DE DONNÉES CUMULATIVES ;
Les sauvegardes cumulatives sont préférables aux sauvegardes différentielles lorsque le temps de récupération est plus important que l'espace disque, car lors de la récupération, chaque sauvegarde différentielle doit être appliquée successivement. Utilisez des sauvegardes incrémentielles cumulatives au lieu de sauvegardes différentielles, si suffisamment d'espace disque est disponible pour stocker les sauvegardes incrémentielles cumulatives.
Il s'agit d'une commande permettant d'effectuer une sauvegarde de niveau 0.
RMAN> SAUVEGARDE DE LA BASE DE DONNÉES DE NIVEAU INCRÉMENTIEL 0 ;
Quelle est la différence entre un jeu de sauvegarde et une pièce de sauvegarde ?
Le jeu de sauvegarde est logique et la pièce de sauvegarde est physique.
Commande RMAN à sauvegarder pour créer une base de données de secours
RMAN> base de données cible en double
Vous perdez un fichier de données et la base de données s'exécute en mode ARCHIVELOG. Vous disposez d'une sauvegarde complète de la base de données datant d'une semaine/jour et vous n'avez pas de sauvegarde de ce fichier de données (nouvellement créé). Comment restaurer/récupérer un fichier ?
Créez un fichier de données et récupérez le fichier de données.
SQL> modifier la base de données créer un fichier de données '/u01/app/oracle/oradata/xyz.dbf' taille 2G ;
RMAN> récupérer le fichier de données file_id ;
Qu'est-ce qu'une sauvegarde obsolète et une sauvegarde expirée ?
Un statut « expiré » signifie que l'élément de sauvegarde ou le jeu de sauvegarde est introuvable dans la destination de sauvegarde.
Un statut « obsolète » signifie que l’élément de sauvegarde est toujours disponible, mais qu’il n’est plus nécessaire. L'élément de sauvegarde n'est plus nécessaire puisque RMAN a été configuré pour ne plus avoir besoin de cet élément après tant de jours écoulés ou tant de sauvegardes effectuées.
Quelle est la différence entre la sauvegarde à chaud et la sauvegarde RMAN ?
Pour une sauvegarde à chaud, nous devons mettre la base de données en mode de démarrage de la sauvegarde, puis effectuer une sauvegarde.
RMAN ne mettra pas la base de données en mode sauvegarde.
Comment mettre une sauvegarde manuelle/gérée par l'utilisateur dans RMAN (catalogue de récupération) ?
En utilisant la commande catalog.
RMAN> LE CATALOGUE COMMENCE PAR '/tmp/backup.ctl';
Quels sont les composants architecturaux de RMAN ?
Exécutables RMAN
Processus Sercer
Canaux
Base de données cible
Base de données du catalogue de récupération (facultatif)
Couche de gestion des médias (facultatif)
Sauvegardes, jeux de sauvegarde et éléments de sauvegarde
Que sont les chaînes ?
Un canal est un processus serveur RMAN démarré lorsqu'il est nécessaire de communiquer avec un périphérique d'E/S, tel qu'un disque ou une bande. Un canal est ce qui lit et écrit les fichiers de sauvegarde RMAN. C'est grâce à l'allocation des canaux que vous déterminez les caractéristiques d'E/S :
Type de périphérique d'E/S en cours de lecture ou d'écriture, soit un disque, soit un sbt_tape. Maximisez la taille des fichiers créés sur I
/O.
Périphériques /O
Maximiser la vitesse de lecture des fichiers de base de données
Maximiser le nombre de fichiers ouverts à la fois
Pourquoi le catalogue est-il facultatif ?
Étant donné que RMAN gère les opérations de sauvegarde et de récupération, il nécessite un emplacement pour stocker les informations nécessaires sur la base de données. RMAN stocke toujours ces informations dans le fichier de contrôle de la base de données cible. Vous pouvez également stocker les métadonnées RMAN dans un schéma de catalogue de récupération contenu dans une base de données distincte. Le schéma du catalogue de récupération doit être stocké dans une base de données autre que la base de données cible.
Qu'est-ce qu'un jeu de sauvegarde ?
Un regroupement logique de fichiers de sauvegarde (les éléments de sauvegarde) créés lorsque vous émettez une commande de sauvegarde RMAN. Un jeu de sauvegarde est le nom RMAN pour une collection de fichiers associés à une sauvegarde. Un jeu de sauvegarde est composé d'un ou plusieurs éléments de sauvegarde.
Quels sont les avantages de l’utilisation de RMAN ?
Sauvegardes incrémentielles qui copient uniquement les blocs de données modifiés depuis la dernière sauvegarde.
Les tablespaces ne sont pas mis en mode sauvegarde, il n'y a donc pas de génération supplémentaire de journalisation lors des sauvegardes en ligne.
Détection des blocs corrompus lors des sauvegardes.
Parallélisation des opérations d'E/S.
Journalisation automatique de toutes les opérations de sauvegarde et de récupération.
Commandes intégrées de reporting et de listage.
Quels sont les différents rapports disponibles avec RMAN
RMAN>list backup ;
RMAN> archive de liste ;
Dans la base de données du catalogue, si certains blocs sont corrompus en raison d’une panne du système, comment allez-vous les récupérer ?
à l'aide de la commande RMAN BLOCK RECOVER
Comment activer la sauvegarde automatique du fichier de contrôle à l'aide de RMAN ?
Émettez la commande à l’invite RMAN.
RMAN> configurez la sauvegarde automatique du fichier de contrôle ;
Nous pouvons également configurer le format de sauvegarde du fichier de contrôle.
RMAN> configure le format de sauvegarde automatique du fichier de contrôle pour le type de disque de périphérique sur
2> '$HOME/BACKUP/RMAN/ F.bkp' ;
Comment identifiez-vous quelles sont toutes les bases de données cibles sauvegardées avec la base de données RMAN ?
Vous n'avez aucune vue pour identifier s'il est sauvegardé ou non. La seule option est de se connecter à la base de données cible et de sauvegarder la liste. Cela vous donnera les informations de sauvegarde avec la date et l'heure.
Comment identifier la corruption de bloc dans la base de données RMAN ? Comment le réparer ?
En utilisant la vue v$block_corruption, vous pouvez trouver les blocs corrompus.
RMAN> bloc de récupération du fichier de données <fileid> bloc <blockid> ;
En utilisant l'instruction ci-dessus, vous récupérez les blocs corrompus. Vérifiez d'abord si le bloc est corrompu ou non en utilisant cette commande
SQL>select file# block# from v$database_block_corruption ;
file# block
2 507
le bloc ci-dessus est corrompu…
connexion à Rman
Pour récupérer le bloc, utilisez cette commande…
RMAN>blockrecover datafile 2 block 507 ;
la commande ci-dessus récupère le bloc 507.
Maintenant, vérifiez-le…..
Rman>blockrecover corruption list ;
Comment cloner la base de données à l’aide du logiciel RMAN ? Donner de brèves étapes ? Quand utilisez-vous la commande crosscheck ?
Vérifiez si des copies de proxy ou des copies de disque de sauvegarde existent toujours.
Deux commandes disponibles dans RMAN pour cloner la base de données :
1) Dupliquer
2) Restaurer.
Répertorier certains des noms de vues du catalogue RMAN qui contiennent les informations du catalogue ?
RC_DATABASE_INCARNATION RC_BACKUP_COPY_DETAILS
RC_BACKUP_CORRUPTION
RC_BACKUP-DATAFILE_SUMMARY
Comment installer le catalogue de récupération RMAN ?
Étapes à suivre :
1) Créez une chaîne de connexion dans la base de données du catalogue.
2) Dans la base de données du catalogue, créez un nouvel utilisateur ou utilisez un utilisateur existant et accordez à cet utilisateur le privilège recovery_catalog_owner.
3) Connectez-vous à RMAN avec la chaîne de connexion
a) exportez ORACLE_SID
b) catalogue cible rman @chaîne de connexion
4) rman> créez un catalogue ;
5) enregistrer la base de données ;
Quelle est la différence entre les sauvegardes physiques et logiques ?
Dans Oracle Logical Backup, il s'agit de « qui est effectuée à l'aide d'une exportation/importation traditionnelle ou de la dernière pompe de données ». Où la sauvegarde physique est connue « lorsque vous prenez des fichiers liés à la base de données physique du système d'exploitation comme sauvegarde ».
Qu’est-ce que le RAID ? Qu’est-ce que RAID0 ? Qu’est-ce que RAID1 ? Qu’est-ce que RAID 10 ?
RAID : Il s'agit d'une matrice redondante de disques indépendants
RAID0 : Concaténation et suppression
RAID1 : Mise en miroir
Comment activer la sauvegarde incrémentielle rapide pour sauvegarder uniquement les blocs de données qui ont changé ?
SQL> ALTER DATABASE active le SUIVI DES CHANGEMENTS DE BLOC ;
Comment définir la zone de récupération flash ?
SQL> ALTER SYSTEM SET db_recovery_file_dest_size = 100G ;
SQL> ALTER SYSTEM SET db_recovery_file_dest = '/u10/oradata/school';
Qu’est-ce que le canal auxiliaire dans RMAN ? Quand en avez-vous besoin ?
Un canal auxiliaire est un lien vers une instance auxiliaire. Si aucun canal automatique n'est configuré, avant d'émettre la commande DUPLICATE, allouez manuellement au moins un canal auxiliaire dans la même commande RUN.
Comment utilisez-vous la vue V$RECOVERY_FILE_DEST pour afficher des informations concernant la zone de récupération flash ?
SQL> nom SELECT, space_limit, space_used, space_reclaimable, number_of_filesFROM v$recovery_file_dest ;
Comment afficher des messages d'avertissement ?
SQL> SELECT type_objet, type_message, niveau_message, raison, action_suggéréeFROM dba_outstanding_alerts ;
Comment sauvegarder l’intégralité de la base de données ?
RMAN> BASE DE DONNÉES DE SAUVEGARDE ;
Comment sauvegarder un espace de table individuel ?
RMAN> CONFIGURER LE TYPE DE PÉRIPHÉRIQUE PAR DÉFAUT SUR LE DISQUE ;
RMAN> système TABLESPACE DE SAUVEGARDE ;
Comment sauvegarder les fichiers de données et contrôler les fichiers ?
RMAN> FICHIER DE DONNÉES DE SAUVEGARDE 3 ;
RMAN> FICHIER DE CONTRÔLE DE COURANT DE SAUVEGARDE ;
Utilisez une récupération rapide sans restaurer toutes les sauvegardes de leur emplacement de sauvegarde vers l'emplacement spécifié dans le fichier de contrôle.
RMAN> COMMUTER LA BASE DE DONNÉES POUR COPIER ;
Ma base de données a une sauvegarde de niveau 1, dites-moi ce qui est sauvegardé ? avec exemple ? La base de données est UP et a effectué une sauvegarde de niveau 0, la sauvegarde effectuée est-elle cohérente ou incohérente ? Comment dites-vous qu’une sauvegarde est cohérente ou incohérente, selon la terminologie Oracle ? Pouvons-nous effectuer une sauvegarde lorsque la base de données est en panne ? Si j'ai une sauvegarde complète RMAN niveau 0 de Sun à 21 heures, le lundi à 21 heures, j'effectue une sauvegarde incrémentielle de niveau 1. Quel type de sauvegarde obtenez-vous et qu'est-ce qui est réellement sauvegardé ? Si j'ai une sauvegarde complète RMAN de Sun à 21 heures, le lundi à 21 heures, j'effectue une sauvegarde incrémentielle de niveau 1. Le mardi, la base de données est tombée en panne. Quel type de sauvegarde obtenez-vous et qu'est-ce qui est réellement sauvegardé ? Aucune sauvegarde n'est disponible. Pouvons-nous effectuer une sauvegarde de niveau 1 ? Une table a été supprimée entre 9h et 11h. Comment obtenir la sauvegarde de la table à l'aide de RMAN, taille de base de données de 500 Go, l'espace de point de montage disponible pour la récupération de table est de 15 Go ? L'administrateur système a modifié l'heure de 10h00 à 9h30, la table a été supprimée. Comment récupérer la table ? Un DATAFILE est corrompu et il n'y a pas de sauvegarde, Comment récupérer le fichier de données ? Tous les fichiers de contrôle sont corrompus, comment récupérer le fichier de contrôle ?
La restauration signifie copier l'objet de base de données du support de sauvegarde vers la destination où cela est réellement nécessaire, tandis que la récupération signifie appliquer l'objet de base de données copié précédemment (roll forward) afin de mettre la base de données dans un état cohérent.
Quelle est la différence entre une guérison complète et incomplète ?
Une récupération de base de données incomplète est une récupération qui n’atteint pas le point de défaillance. La récupération peut être soit un point dans le temps, soit un SCN particulier ou un journal d'archive particulier, spécialement en cas de journal d'archive manquant ou d'échec de redolog, alors qu'une récupération complète récupère jusqu'au point de défaillance, éventuellement lors de la sauvegarde de tous les journaux d'archive.
Comment décideriez-vous de votre stratégie de sauvegarde et du calendrier de sauvegarde ?
En fait, la stratégie de sauvegarde dépend uniquement des besoins commerciaux de votre organisation.
S'il n'y a pas de temps d'arrêt, la base de données doit être exécutée en mode archivelog et vous devez effectuer des sauvegardes fréquentes ou quotidiennes.
Si le temps d'arrêt est suffisant et que la perte de données n'affectera pas votre entreprise, vous pouvez exécuter votre base de données en mode noarchivelog et la sauvegarde peut être effectuée fréquemment, hebdomadairement ou mensuellement.
Dans la plupart des cas, dans une organisation où aucun temps d'arrêt, une sauvegarde incohérente fréquente n'est nécessaire (sauvegarde quotidienne), des fichiers de journalisation en ligne multiplexés (plusieurs copies), un emplacement différent pour les fichiers de journalisation, la base de données doit fonctionner en mode archivelog et dataguard peut être implémenté pour un peu de protection supplémentaire.
Quel est l'avantage d'exécuter la base de données en mode archivelog par rapport au mode sans archivelog ?
Lorsqu'une base de données n'est pas en mode archivelog, chaque fois que le changement de journal se produit, certaines informations de journalisation seront perdues. Afin d'éviter cela, les journaux redo doivent être archivés. Ceci peut être réalisé en configurant la base de données en mode archivelog.
Si une base de données Oracle tombe en panne ? Comment récupéreriez-vous cette transaction qui n’est pas en sauvegarde ?
Si la base de données est dans le journal d'archives, nous pouvons récupérer cette transaction, sinon nous ne pouvons pas récupérer cette transaction qui n'est pas en sauvegarde.
Quelle est la différence entre la sauvegarde HOTBACKUP et la sauvegarde RMAN ?
Pour la sauvegarde à chaud, nous devons mettre la base de données en mode de début de sauvegarde, puis effectuer une sauvegarde alors que RMAN ne mettrait pas la base de données en mode de début de sauvegarde. RMAN est plus rapide, peut effectuer une sauvegarde incrémentielle (modifications uniquement) et ne place pas l'espace table en mode de sauvegarde à chaud.
Pouvons-nous utiliser la même base de données cible que la base de données du catalogue ?
Non, le catalogue de récupération ne doit pas résider dans la base de données cible (base de données à sauvegarder) car la base de données ne peut pas être récupérée à l'état monté.
Niveaux de sauvegarde incrémentielle :
Niveau 0 – sauvegarde complète qui peut être utilisée pour les incréments ultérieurs
RMAN> sauvegarde incrémentielle de niveau 0 de la base de données ;
Différentiel niveau 1 – uniquement les blocs qui ont changé depuis la dernière sauvegarde (qu'elle soit de niveau 0 ou de niveau 1)
RMAN> sauvegarde incrémentielle de niveau 1 de la base de données différentielle ;
Niveau cumulatif 1 – toutes les modifications depuis la dernière sauvegarde incrémentielle de niveau 0
RMAN> sauvegarde de la base de données cumulative de niveau 1 ;
Une sauvegarde complète ne peut pas être utilisée pour une sauvegarde cumulative de niveau 1.
Une sauvegarde cumulative de niveau 1 doit être effectuée en plus d'une sauvegarde incrémentielle de niveau 0.
Pourquoi la sauvegarde incrémentielle RMAN échoue même si une sauvegarde complète existe ?
Si vous avez effectué la sauvegarde complète RMAN à l'aide de la commande « Sauvegarder la base de données », alors qu'une sauvegarde de niveau 0 est physiquement identique à une sauvegarde complète. La seule différence est que la sauvegarde de niveau 0 est enregistrée en tant que sauvegarde incrémentielle dans le référentiel RMAN afin qu'elle puisse être utilisée comme parent pour une sauvegarde de niveau 1. Simplement, la « sauvegarde complète sans niveau 0 » ne peut pas être considérée comme une sauvegarde parent à partir de laquelle vous pouvez effectuer une sauvegarde de niveau 1.
Pouvons-nous effectuer une sauvegarde RMAN niveau 1 sans niveau 0 ?
Si aucun niveau 0 n'est disponible, le comportement dépend du paramètre de mode de compatibilité (version Oracle).
Si le mode de compatibilité est inférieur à 10.0.0, RMAN génère une sauvegarde de niveau 0 du contenu des fichiers au moment de la sauvegarde.
Si la compatibilité est supérieure à 10.0.0, RMAN copie toutes les modifications de bloc depuis la création du fichier et stocke les résultats sous forme de sauvegarde de niveau 1.
Comment mettre une sauvegarde manuelle/gérée par l'utilisateur dans RMAN ?
En cas de catalogue de récupération, vous pouvez le placer à l'aide de la commande catalog :
RMAN> CATALOG START WITH '/oracle/backup.ctl' ;
Comment vérifier la version RMAN dans Oracle ?
Si vous souhaitez vérifier la version du catalogue RMAN, utilisez la requête ci-dessous depuis SQL*plus
SQL> Select * from rcver ;
Que se passe-t-il réellement en cas de récupération d'instance ?
En cas d'échec de l'instance Oracle, Oracle effectue une récupération d'instance lorsque la base de données associée est redémarrée. La récupération d'instance se déroule en 2 étapes :
Récupération du cache : les modifications apportées à une base de données sont enregistrées simultanément dans le cache tampon de la base de données ainsi que dans les fichiers de journalisation. Lorsqu'il y a suffisamment de données dans le cache du tampon de base de données, elles sont écrites dans des fichiers de données. Si une instance Oracle échoue avant que ces données ne soient écrites dans des fichiers de données, Oracle utilise des fichiers de journalisation en ligne pour récupérer les données perdues au redémarrage de la base de données associée. Ce processus est appelé récupération du cache.
Récupération de transaction : lorsqu'une transaction modifie des données dans une base de données (l'image avant des données modifiées est stockée dans un segment d'annulation qui est utilisé pour restaurer les valeurs d'origine au cas où la transaction serait annulée). Au moment d'une panne d'instance, la base de données peut contenir des transactions non validées. Il est possible que les modifications apportées par ces transactions non validées aient été enregistrées dans des fichiers de données. Pour maintenir la cohérence de la lecture, Oracle annule toutes les transactions non validées lorsque la base de données associée est redémarrée. Oracle utilise les données d'annulation stockées dans les segments d'annulation pour ce faire. Ce processus est appelé récupération de transaction.
Qu’est-ce que RMAN ?
Recovery Manager (RMAN) est un utilitaire qui peut gérer l'ensemble de vos activités de sauvegarde et de récupération Oracle.
Quelle est la différence entre l’utilisation du catalogue de récupération et du fichier de contrôle ?
Lorsqu'une nouvelle incarnation se produit, les anciennes informations de sauvegarde dans le fichier de contrôle seront perdues. Il sera conservé dans le catalogue de récupération.
Dans le catalogue de récupération, nous pouvons stocker des scripts.
Le catalogue de récupération est central et peut contenir des informations sur de nombreuses bases de données.
Pouvons-nous utiliser la même base de données cible que le catalogue ?
Non, le catalogue de récupération ne doit pas résider dans la base de données cible (la base de données doit être sauvegardée), car la base de données ne peut pas être récupérée à l'état monté.
Comment savez-vous combien de tâches RMAN ont été accomplies ?
En interrogeant v$rman_status ou v$session_longops.
D'où les commandes de liste et de rapport recevront-elles des entrées ?
Les commandes commandent l'interrogation de v$ et les vues du catalogue de récupération. V$BACKUP_FILES ou de nombreuses vues du catalogue de récupération telles que RC_DATAFILE_COPY ou RC_ARCHIVED_LOG.
Commande pour supprimer les journaux d'archives datant de plus de 7 jours ?
RMAN> supprimer l'archivelog terminé avant sysdate-7 ;
Combien de fois Oracle demande-t-il avant de supprimer un catalogue ?
La valeur par défaut est deux fois, une pour la commande réelle, l'autre pour la confirmation.
Comment afficher les valeurs par défaut actuelles de la base de données.
RMAN> afficher tout ;
À quoi sert la commande crosscheck dans RMAN ?
Un contrôle croisé sera utile pour vérifier si les informations du catalogue sont intactes avec les informations au niveau du système d'exploitation. Cette commande met uniquement à jour les enregistrements du référentiel avec l'état des sauvegardes.
Par exemple, si l'utilisateur supprime les journaux archivés du disque avec une commande du système d'exploitation, le référentiel indique toujours que les journaux sont sur le disque, alors qu'en réalité ils ne le sont pas.
Quelles sont les différences entre les commandes crosscheck et validate ?
La commande Validate consiste à examiner un jeu de sauvegarde et à indiquer s'il peut être restauré. RMAN analyse tous les éléments de sauvegarde dans les jeux de sauvegarde spécifiés et examine la somme de contrôle pour vérifier que le contenu est intact afin que la sauvegarde puisse être restaurée avec succès si nécessaire.
La commande Crosscheck consiste à vérifier l'état des sauvegardes et des copies enregistrées dans le référentiel RMAN par rapport à un support tel qu'un disque ou une bande. La commande crosscheck traite uniquement les fichiers créés sur le même type de périphérique que le canal exécutant crosscheck.
Laquelle est la bonne sauvegarde : une sauvegarde différentielle (incrémentale) ou une sauvegarde cumulative (incrémentale) ?
Une sauvegarde différentielle, qui sauvegarde tous les blocs modifiés après la sauvegarde incrémentielle la plus récente au niveau 1 ou 0
RMAN> SAUVEGARDE INCREMENTALE NIVEAU 1 BASE DE DONNÉES ;
Une sauvegarde cumulative, qui sauvegarde tous les blocs modifiés après la sauvegarde incrémentielle la plus récente au niveau 0
RMAN> SAUVEGARDE INCREMENTALE NIVEAU 1 BASE DE DONNÉES CUMULATIVES ;
Les sauvegardes cumulatives sont préférables aux sauvegardes différentielles lorsque le temps de récupération est plus important que l'espace disque, car lors de la récupération, chaque sauvegarde différentielle doit être appliquée successivement. Utilisez des sauvegardes incrémentielles cumulatives au lieu de sauvegardes différentielles, si suffisamment d'espace disque est disponible pour stocker les sauvegardes incrémentielles cumulatives.
Il s'agit d'une commande permettant d'effectuer une sauvegarde de niveau 0.
RMAN> SAUVEGARDE DE LA BASE DE DONNÉES DE NIVEAU INCRÉMENTIEL 0 ;
Quelle est la différence entre un jeu de sauvegarde et une pièce de sauvegarde ?
Le jeu de sauvegarde est logique et la pièce de sauvegarde est physique.
Commande RMAN à sauvegarder pour créer une base de données de secours
RMAN> base de données cible en double
Vous perdez un fichier de données et la base de données s'exécute en mode ARCHIVELOG. Vous disposez d'une sauvegarde complète de la base de données datant d'une semaine/jour et vous n'avez pas de sauvegarde de ce fichier de données (nouvellement créé). Comment restaurer/récupérer un fichier ?
Créez un fichier de données et récupérez le fichier de données.
SQL> modifier la base de données créer un fichier de données '/u01/app/oracle/oradata/xyz.dbf' taille 2G ;
RMAN> récupérer le fichier de données file_id ;
Qu'est-ce qu'une sauvegarde obsolète et une sauvegarde expirée ?
Un statut « expiré » signifie que l'élément de sauvegarde ou le jeu de sauvegarde est introuvable dans la destination de sauvegarde.
Un statut « obsolète » signifie que l’élément de sauvegarde est toujours disponible, mais qu’il n’est plus nécessaire. L'élément de sauvegarde n'est plus nécessaire puisque RMAN a été configuré pour ne plus avoir besoin de cet élément après tant de jours écoulés ou tant de sauvegardes effectuées.
Quelle est la différence entre la sauvegarde à chaud et la sauvegarde RMAN ?
Pour une sauvegarde à chaud, nous devons mettre la base de données en mode de démarrage de la sauvegarde, puis effectuer une sauvegarde.
RMAN ne mettra pas la base de données en mode sauvegarde.
Comment mettre une sauvegarde manuelle/gérée par l'utilisateur dans RMAN (catalogue de récupération) ?
En utilisant la commande catalog.
RMAN> LE CATALOGUE COMMENCE PAR '/tmp/backup.ctl';
Quels sont les composants architecturaux de RMAN ?
Exécutables RMAN
Processus Sercer
Canaux
Base de données cible
Base de données du catalogue de récupération (facultatif)
Couche de gestion des médias (facultatif)
Sauvegardes, jeux de sauvegarde et éléments de sauvegarde
Que sont les chaînes ?
Un canal est un processus serveur RMAN démarré lorsqu'il est nécessaire de communiquer avec un périphérique d'E/S, tel qu'un disque ou une bande. Un canal est ce qui lit et écrit les fichiers de sauvegarde RMAN. C'est grâce à l'allocation des canaux que vous déterminez les caractéristiques d'E/S :
Type de périphérique d'E/S en cours de lecture ou d'écriture, soit un disque, soit un sbt_tape. Maximisez la taille des fichiers créés sur I
/O.
Périphériques /O
Maximiser la vitesse de lecture des fichiers de base de données
Maximiser le nombre de fichiers ouverts à la fois
Pourquoi le catalogue est-il facultatif ?
Étant donné que RMAN gère les opérations de sauvegarde et de récupération, il nécessite un emplacement pour stocker les informations nécessaires sur la base de données. RMAN stocke toujours ces informations dans le fichier de contrôle de la base de données cible. Vous pouvez également stocker les métadonnées RMAN dans un schéma de catalogue de récupération contenu dans une base de données distincte. Le schéma du catalogue de récupération doit être stocké dans une base de données autre que la base de données cible.
Qu'est-ce qu'un jeu de sauvegarde ?
Un regroupement logique de fichiers de sauvegarde (les éléments de sauvegarde) créés lorsque vous émettez une commande de sauvegarde RMAN. Un jeu de sauvegarde est le nom RMAN pour une collection de fichiers associés à une sauvegarde. Un jeu de sauvegarde est composé d'un ou plusieurs éléments de sauvegarde.
Quels sont les avantages de l’utilisation de RMAN ?
Sauvegardes incrémentielles qui copient uniquement les blocs de données modifiés depuis la dernière sauvegarde.
Les tablespaces ne sont pas mis en mode sauvegarde, il n'y a donc pas de génération supplémentaire de journalisation lors des sauvegardes en ligne.
Détection des blocs corrompus lors des sauvegardes.
Parallélisation des opérations d'E/S.
Journalisation automatique de toutes les opérations de sauvegarde et de récupération.
Commandes intégrées de reporting et de listage.
Quels sont les différents rapports disponibles avec RMAN
RMAN>list backup ;
RMAN> archive de liste ;
Dans la base de données du catalogue, si certains blocs sont corrompus en raison d’une panne du système, comment allez-vous les récupérer ?
à l'aide de la commande RMAN BLOCK RECOVER
Comment activer la sauvegarde automatique du fichier de contrôle à l'aide de RMAN ?
Émettez la commande à l’invite RMAN.
RMAN> configurez la sauvegarde automatique du fichier de contrôle ;
Nous pouvons également configurer le format de sauvegarde du fichier de contrôle.
RMAN> configure le format de sauvegarde automatique du fichier de contrôle pour le type de disque de périphérique sur
2> '$HOME/BACKUP/RMAN/ F.bkp' ;
Comment identifiez-vous quelles sont toutes les bases de données cibles sauvegardées avec la base de données RMAN ?
Vous n'avez aucune vue pour identifier s'il est sauvegardé ou non. La seule option est de se connecter à la base de données cible et de sauvegarder la liste. Cela vous donnera les informations de sauvegarde avec la date et l'heure.
Comment identifier la corruption de bloc dans la base de données RMAN ? Comment le réparer ?
En utilisant la vue v$block_corruption, vous pouvez trouver les blocs corrompus.
RMAN> bloc de récupération du fichier de données <fileid> bloc <blockid> ;
En utilisant l'instruction ci-dessus, vous récupérez les blocs corrompus. Vérifiez d'abord si le bloc est corrompu ou non en utilisant cette commande
SQL>select file# block# from v$database_block_corruption ;
file# block
2 507
le bloc ci-dessus est corrompu…
connexion à Rman
Pour récupérer le bloc, utilisez cette commande…
RMAN>blockrecover datafile 2 block 507 ;
la commande ci-dessus récupère le bloc 507.
Maintenant, vérifiez-le…..
Rman>blockrecover corruption list ;
Comment cloner la base de données à l’aide du logiciel RMAN ? Donner de brèves étapes ? Quand utilisez-vous la commande crosscheck ?
Vérifiez si des copies de proxy ou des copies de disque de sauvegarde existent toujours.
Deux commandes disponibles dans RMAN pour cloner la base de données :
1) Dupliquer
2) Restaurer.
Répertorier certains des noms de vues du catalogue RMAN qui contiennent les informations du catalogue ?
RC_DATABASE_INCARNATION RC_BACKUP_COPY_DETAILS
RC_BACKUP_CORRUPTION
RC_BACKUP-DATAFILE_SUMMARY
Comment installer le catalogue de récupération RMAN ?
Étapes à suivre :
1) Créez une chaîne de connexion dans la base de données du catalogue.
2) Dans la base de données du catalogue, créez un nouvel utilisateur ou utilisez un utilisateur existant et accordez à cet utilisateur le privilège recovery_catalog_owner.
3) Connectez-vous à RMAN avec la chaîne de connexion
a) exportez ORACLE_SID
b) catalogue cible rman @chaîne de connexion
4) rman> créez un catalogue ;
5) enregistrer la base de données ;
Quelle est la différence entre les sauvegardes physiques et logiques ?
Dans Oracle Logical Backup, il s'agit de « qui est effectuée à l'aide d'une exportation/importation traditionnelle ou de la dernière pompe de données ». Où la sauvegarde physique est connue « lorsque vous prenez des fichiers liés à la base de données physique du système d'exploitation comme sauvegarde ».
Qu’est-ce que le RAID ? Qu’est-ce que RAID0 ? Qu’est-ce que RAID1 ? Qu’est-ce que RAID 10 ?
RAID : Il s'agit d'une matrice redondante de disques indépendants
RAID0 : Concaténation et suppression
RAID1 : Mise en miroir
Comment activer la sauvegarde incrémentielle rapide pour sauvegarder uniquement les blocs de données qui ont changé ?
SQL> ALTER DATABASE active le SUIVI DES CHANGEMENTS DE BLOC ;
Comment définir la zone de récupération flash ?
SQL> ALTER SYSTEM SET db_recovery_file_dest_size = 100G ;
SQL> ALTER SYSTEM SET db_recovery_file_dest = '/u10/oradata/school';
Qu’est-ce que le canal auxiliaire dans RMAN ? Quand en avez-vous besoin ?
Un canal auxiliaire est un lien vers une instance auxiliaire. Si aucun canal automatique n'est configuré, avant d'émettre la commande DUPLICATE, allouez manuellement au moins un canal auxiliaire dans la même commande RUN.
Comment utilisez-vous la vue V$RECOVERY_FILE_DEST pour afficher des informations concernant la zone de récupération flash ?
SQL> nom SELECT, space_limit, space_used, space_reclaimable, number_of_filesFROM v$recovery_file_dest ;
Comment afficher des messages d'avertissement ?
SQL> SELECT type_objet, type_message, niveau_message, raison, action_suggéréeFROM dba_outstanding_alerts ;
Comment sauvegarder l’intégralité de la base de données ?
RMAN> BASE DE DONNÉES DE SAUVEGARDE ;
Comment sauvegarder un espace de table individuel ?
RMAN> CONFIGURER LE TYPE DE PÉRIPHÉRIQUE PAR DÉFAUT SUR LE DISQUE ;
RMAN> système TABLESPACE DE SAUVEGARDE ;
Comment sauvegarder les fichiers de données et contrôler les fichiers ?
RMAN> FICHIER DE DONNÉES DE SAUVEGARDE 3 ;
RMAN> FICHIER DE CONTRÔLE DE COURANT DE SAUVEGARDE ;
Utilisez une récupération rapide sans restaurer toutes les sauvegardes de leur emplacement de sauvegarde vers l'emplacement spécifié dans le fichier de contrôle.
RMAN> COMMUTER LA BASE DE DONNÉES POUR COPIER ;
Ma base de données a une sauvegarde de niveau 1, dites-moi ce qui est sauvegardé ? avec exemple ? La base de données est UP et a effectué une sauvegarde de niveau 0, la sauvegarde effectuée est-elle cohérente ou incohérente ? Comment dites-vous qu’une sauvegarde est cohérente ou incohérente, selon la terminologie Oracle ? Pouvons-nous effectuer une sauvegarde lorsque la base de données est en panne ? Si j'ai une sauvegarde complète RMAN niveau 0 de Sun à 21 heures, le lundi à 21 heures, j'effectue une sauvegarde incrémentielle de niveau 1. Quel type de sauvegarde obtenez-vous et qu'est-ce qui est réellement sauvegardé ? Si j'ai une sauvegarde complète RMAN de Sun à 21 heures, le lundi à 21 heures, j'effectue une sauvegarde incrémentielle de niveau 1. Le mardi, la base de données est tombée en panne. Quel type de sauvegarde obtenez-vous et qu'est-ce qui est réellement sauvegardé ? Aucune sauvegarde n'est disponible. Pouvons-nous effectuer une sauvegarde de niveau 1 ? Une table a été supprimée entre 9h et 11h. Comment obtenir la sauvegarde de la table à l'aide de RMAN, taille de base de données de 500 Go, l'espace de point de montage disponible pour la récupération de table est de 15 Go ? L'administrateur système a modifié l'heure de 10h00 à 9h30, la table a été supprimée. Comment récupérer la table ? Un DATAFILE est corrompu et il n'y a pas de sauvegarde, Comment récupérer le fichier de données ? Tous les fichiers de contrôle sont corrompus, comment récupérer le fichier de contrôle ?
Questions et réponses d'entretien avec Oracle DBA - Patching, clonage et mise à niveau
Dans quels mois Oracle publie-t-il des correctifs CPU ?
JAN, APR, JUL, OCT
Lorsque nous appliquons un seul patch, pouvez-vous utiliser l'utilitaire opatch ?
Oui, vous pouvez utiliser Opatch en cas de patch unique. Le seul type de patch qui ne peut pas être utilisé avec OPatch est un ensemble de patchs.
Est-il possible d'appliquer OPATCH sans temps d'arrêt ?
Comme vous le savez, pour appliquer le correctif, votre base de données et votre écouteur doivent être en panne. Lorsque vous appliquez OPTACH, il mettra à jour votre ORACLE_HOME actuel. Venant ainsi à votre question, en fait, il n'est pas possible sans temps d'arrêt ou sans temps d'arrêt en cas d'instance unique, mais dans RAC, vous pouvez appliquer Opatch sans temps d'arrêt car il y aura plus d'ORACLE_HOME séparé et plus d'instances distinctes (exécutées une seule fois sur chaque ORACLE_HOME). ).
Lorsque vous avez déplacé des fichiers binaires Oracle d'un serveur ORACLE_HOME vers un autre serveur, quel utilitaire Oracle sera utilisé pour rendre ce nouvel ORACLE_HOME utilisable ?
Reliez tout.
Vous disposez d'une collection de patch (près de 100 patchs) ou d'un ensemble de patchs. Comment pouvez-vous appliquer un seul patch à partir de celui-ci ?
Avec Napply lui-même (en fournissant l'emplacement du correctif et l'identifiant du correctif spécifique), vous ne pouvez appliquer qu'un seul correctif à partir d'une collection de correctifs extraits. Pour plus d'informations, consultez l'utilitaire opatch NApply –help. Cela vous donnera une image claire.
Par exemple :
opatch util napply <patch_location> -id 9 -skip_subset -skip_duplicate
Cela appliquera uniquement l'ID de correctif 9 à partir de l'emplacement du correctif et ignorera les doublons et les sous-ensembles de correctifs installés dans votre ORACLE_HOME.
Si le CPU et le PSU sont disponibles pour une version donnée, laquelle préférerez-vous postuler ?
D'après la discussion ci-dessus, il est clair qu'une fois que vous appliquez le bloc d'alimentation, la méthode recommandée consiste à appliquer uniquement le bloc d'alimentation suivant. En fait, il n'est pas nécessaire d'appliquer le processeur sur le dessus du bloc d'alimentation, car le bloc d'alimentation contient du processeur (si vous appliquez le processeur sur le bloc d'alimentation, vous considérerez que vous essayez de restaurer le bloc d'alimentation et que cela nécessitera en fait plus d'efforts). Donc, si vous n’avez décidé ou appliqué aucun des correctifs, je vous suggérerai d’utiliser les correctifs PSU. Pour plus de détails, reportez-vous : Produits Oracle [ID 1430923.1], ID 1446582.1
Le bloc d'alimentation est un surensemble de processeur, alors pourquoi quelqu'un choisit-il d'appliquer un processeur plutôt qu'un bloc d'alimentation ?
Les processeurs sont plus petits et plus ciblés que les blocs d'alimentation et traitent principalement des problèmes de sécurité. Cela semble être théoriquement une approche plus consécutive et peut causer moins de problèmes que le bloc d'alimentation car il contient moins de changements de code. Ainsi, pour quiconque s'intéresse uniquement aux correctifs de sécurité et non aux correctifs de fonctionnalités, le processeur peut être une bonne approche.
Comment télécharger des patchs, patchset ou Opatch depuis metalink ?
Si vous utilisez le dernier support.oracle.com, après vous être connecté au tableau de bord metalink
- Cliquez sur l'onglet "Patches et mises à jour"
- Dans la barre latérale gauche, cliquez sur "Derniers correctifs" sous "Oracle Server/Tools".
- Une nouvelle fenêtre apparaîtra.
- Passez simplement la souris sur votre produit dans la page « Derniers correctifs Oracle Server/Tools ».
- La version correspondante de la plateforme Oracle apparaîtra. Ensuite, choisissez simplement la version du patchset et cliquez dessus.
- Vous accéderez à la page de téléchargement. À partir de la page de téléchargement, vous pouvez également modifier votre plate-forme et la version de votre ensemble de correctifs.
RÉFÉRENCES :
http://docs.oracle.com/cd/E11857_01/em.111/e12255/e_oui_appendix.htm
Oracle® Universal Installer et OPatch User's Guide
11g Release 2 (11.2) pour Windows et UNIX
Numéro de pièce E12255-11
Qu'est-ce que le patch récent a-t-il été appliqué ? Patch PSU de janvier 2016 Qu'est-ce qu'OPatch ? C'est l'utilitaire pour appliquer le patch. Comment appliquer Opatch dans Oracle ? 1. Vous DEVEZ lire le fichier Readme.txt inclus dans le fichier opatch, recherchez toute condition préalable. étapes/étapes post-installation ou modifications liées à la base de données. Assurez-vous également que vous disposez de la version opatch correcte requise par ce correctif. 2.Assurez-vous d'avoir une bonne sauvegarde de la base de données. 3. Notez tous les objets non valides dans la base de données avant le patch. 4. Arrêtez tous les processus Oracle exécutés à partir de cet Oracle Home, y compris l'instance d'écoute et de base de données, l'agent de gestion, etc. 5. Vous DEVEZ sauvegarder votre oracle Home et votre inventaire tar -cvf $ORACLE_HOME $ORACLE_HOME/oraInventory | gzip > Backup_Software_Version.tar.gz 6. Décompressez le correctif dans $ORACLE_HOME/patches 7. cd dans le répertoire du correctif et exécutez opatch -apply pour appliquer le correctif. 8. Lisez le fichier de sortie/journal pour vous assurer qu'il n'y a pas eu d'erreurs. Patcher le logiciel Oracle avec OPatch ? opatch napply <patch_location> -skip_subset -skip_duplicate OPatch ignore les correctifs en double et les sous-ensembles de correctifs (correctifs sous <patch_location> qui sont des sous-ensembles de correctifs installés dans le répertoire d'accueil Oracle). Qu’est-ce qu’Opactch dans Oracle ? Utilitaire OPATCH (correctif Oracle RDBMS) 1. Téléchargez le correctif requis depuis Metalink en fonction de la version du système d'exploitation et de la version de la base de données. 2. Besoin de désactiver la base de données avant d'appliquer le correctif. 3. Décompressez et appliquez le correctif à l'aide de la commande « opatch apply ». Une fois le correctif appliqué avec succès, vous verrez le message réussi « OPatch réussi ». Vérifiez que votre correctif est appliqué à l'aide de la commande « opatch lsinventory ». 4. Chaque correctif a un identifiant unique, la commande pour restaurer un correctif est la commande « opatch rollback -id <patch no.> ». Une fois le correctif appliqué avec succès, vous verrez le message de réussite « OPatch réussi ». Vérifiez que votre correctif est appliqué. en utilisant la commande « opatch lsinventory ». 5. Le format du fichier de correctif sera du type « p<patch no.>_<db version>_<os>.zip ». 6. Nous pouvons vérifier la version d'opatch à l'aide de la commande « opatch -version ». 7. Généralement, il faut 2 minutes pour appliquer un patch.
8. Pour obtenir la dernière version d'Opatch, téléchargez « patch 6880880 - dernier outil opatch », il contient le répertoire OPatch.
9. Le contenu des correctifs téléchargés ressemblera à « etc, des répertoires de fichiers et un fichier README ».
10. Le fichier journal de l'utilitaire Opatch peut être trouvé dans $ORACLE_HOME/cfgtoollogs/opatch
11. OPatch maintient également un index des commandes exécutées avec OPatch et les fichiers journaux qui lui sont associés dans le fichier history.txt situé dans le répertoire <ORACLE_HOME>/cfgtoollogs/opatch.
12. À partir de l'ensemble de correctifs 11.2.0.2, les ensembles de correctifs Oracle Database sont des installations complètes du logiciel Oracle Database. Cela signifie que vous n'avez pas besoin d'installer Oracle Database 11g Release 2 (11.2.0.1) avant d'installer Oracle Database 11g Release 2 (11.2.0.2).
13. La mise à niveau directe vers Oracle 10g n'est prise en charge que si votre base de données exécute l'une des versions suivantes : 8.0.6, 8.1.7, 9.0.1 ou 9.2.0. Sinon, vous devrez mettre à niveau la base de données vers l'une de ces versions ou utiliser une autre option de mise à niveau (comme l'exportation/importation).
14. Des mises à niveau directes vers 11g sont possibles à partir des bases de données existantes avec les versions 9.2.0.4+, 10.1.0.2+ ou 10.2.0.1+. Les mises à niveau à partir d'autres versions sont prises en charge uniquement via des mises à niveau intermédiaires vers une version de mise à niveau prise en charge.
http://avdeo.com/2008/08/19/opatch-utility-oracle-rdbms-patching/
Oracle version 10.2.0.4.0 à quoi fait référence chaque numéro ?
Le numéro de version d'Oracle fait référence à :
10 – Numéro de version principale de la base de données
2 – Numéro de version de maintenance de la base de données
0 – Numéro de version du serveur d'applications
4 – Numéro de version spécifique au composant
0 – Numéro de version spécifique à la plate-forme
Types de correctifs ?
Comment restaurer un patch ?
Qu’est-ce que le bloc d’alimentation ?
Qu’est-ce que Rolling Patch ?
Comment vérifier les correctifs installés ?
Combien de temps faudra-t-il pour appliquer les correctifs ?
Problèmes courants rencontrés lors de l'application de correctifs ?
Clonage
=======
Qu'est-ce que le clonage ? Comment prendre le clonage RMAN ? Expliquer les étapes ? Mise à niveau ======= Qu'est-ce que la mise à niveau continue ? Il s'agit d'une nouvelle fonctionnalité ASM de la base de données 11g. Les instances ASM de la version Oracle Database 11g (à partir de 11.1) peuvent être mises à niveau ou corrigées à l'aide de la fonctionnalité de mise à niveau continue. Cela nous permet de corriger ou de mettre à niveau les nœuds ASM dans un environnement en cluster sans affecter la disponibilité de la base de données. Lors d'une mise à niveau continue, nous pouvons maintenir un cluster fonctionnel pendant qu'un ou plusieurs nœuds du cluster s'exécutent dans différentes versions logicielles. La mise à niveau continue peut être utilisée uniquement pour les versions de base de données Oracle 11g (à partir de 11.1). Étapes pour mettre à niveau dans Oracle ? Mise à niveau manuelle qui implique les étapes suivantes : 1. Sauvegardez la base de données.
2.Dans les environnements UNIX/Linux, définissez les variables $ORACLE_HOME et $PATH pour qu'elles pointent vers le nouveau répertoire d'accueil Oracle 11g.
3.Analysez l'instance existante à l'aide du script "$ORACLE_HOME/rdbms/admin/utlu111i.sql".
4.Démarrez la base de données d'origine à l'aide de la commande STARTUP UPGRADE et procédez à la mise à niveau en exécutant le script "$ORACLE_HOME/rdbms/admin/catupgrd.sql".
5.Recompilez les objets invalides.
6.Redémarrez la base de données.
7.Exécutez le script "$ORACLE_HOME/rdbms/admin/utlu111s.sql" et vérifiez le résultat de la mise à niveau.
8.Résolvez tout problème ou abandonnez la mise à niveau.
Que se passe-t-il lorsque vous donnez « STARTUP UPGRADE » ?
$sqlplus "/as sysdba"
SQL> STARTUP UPGRADE
Remarque :
----
Le mot-clé UPGRADE vous permet d'ouvrir une base de données basée sur une version antérieure d'Oracle Database. Il restreint également les connexions aux sessions AS SYSDBA, désactive les déclencheurs système et effectue des opérations supplémentaires qui préparent l'environnement pour la mise à niveau.
Vous devrez peut-être utiliser l'option PFILE pour spécifier l'emplacement de votre fichier de paramètres d'initialisation.
Une fois la base de données démarrée en mode mise à niveau, seules les requêtes sur les vues fixes s'exécutent sans erreur jusqu'à l'exécution du script catupgrd.sql. Avant d'exécuter catupgrd.sql, les requêtes sur toute autre vue ou l'utilisation de PL/SQL renvoient une erreur.
Quelle est la différence entre la mise à niveau au démarrage et la migration ?
migration de démarrage :
---------------
Utilisé pour mettre à niveau une base de données jusqu'à 9i.
Mise à niveau de démarrage
---------------
À partir de 10G, nous utilisons la mise à niveau de démarrage pour mettre à niveau la base de données.
Que se passe-t-il en interne lorsque vous utilisez la mise à niveau/la migration au démarrage ?
Il ajustera automatiquement quelques paramètres de base de données (init) (indépendamment de ce que vous avez défini) à certaines valeurs afin d'exécuter les scripts de mise à niveau en douceur.
d'une autre manière... il émettra quelques instructions de modification pour définir certains paramètres requis pour terminer les scripts de mise à niveau sans aucun problème.
Problèmes courants rencontrés lors de la mise à niveau ?
L'erreur est liée au fichier de fuseau horaire.
Base de données démarrée en mode mise à niveau et lancement de catupgrd.sql :
SQL> mise à niveau de démarrage
de l'instance ORACLE démarrée.
Zone globale totale du système 6413680640 octets
Taille fixe 2160112 octets
Taille variable 1946159632 octets
Tampons de base de données 4429185024 octets
Tampons de rétablissement 36175872 octets
Base de données montée.
Base de données ouverte.
SQL> @catupgrd.sql
DOC>######################################### #############################
DOC>################### ################################################# ##
DOC>
DOC> La première fois que ce script est exécuté, aucun message d'erreur DOC> ne devrait être généré ; tous les messages d'erreur de mise à niveau normaux sont supprimés.
DOC>
DOC> Si ce script est réexécuté après avoir corrigé un problème, alors
DOC> attendez-vous à l'erreur suivante qui n'est pas automatiquement supprimée :
DOC>
DOC> ORA-00001 : contrainte unique () violée
DOC>#
FROM Registry$database
*
ERREUR à la ligne 2 :
ORA-00942 : la table ou la vue n'existe pas.
Cette erreur est liée au fichier de fuseau horaire qui doit être la version 4 pour Oracle version 11g. Si le fuseau horaire n'est pas la version 4, un correctif doit être appliqué.
La requête pour vérifier le fichier de fuseau horaire est :
SQL> select * from v$timezone_file ;
VERSION DU NOM DE FICHIER
———— ———-
timezlrg.dat 4
SQL> select * from v$timezone_file;
VERSION DU NOM DE FICHIER
———— ———-
timezlrg.dat 4
J'avais donc la version correcte. Je me souviens avoir appliqué le correctif avant la mise à niveau. J'ai eu de la chance car le correctif existait pour la version 10.2.0.3.
S'il n'existe pas de correctif pour vos versions Oracle, le correctif peut être téléchargé pour une version similaire et appliqué manuellement.
Les instructions sont ci-dessous :
1. Téléchargez le correctif identifié.
2. Décompressez le patch et localisez les 2 fichiers timezone.dat et timezlrg.dat dans le répertoire « files/oracore/zoneinfo » du patch non compressé (ou dans le fichier .jar correspondant d'un ensemble de patchs). S'il y a également un fichier readme.txt à cet emplacement, notez-le également.
3. Sauvegardez vos fichiers existants dans $ORACLE_HOME/oracore/zoneinfo – CELA PEUT ÊTRE VITAL, NE PAS SAUTER.
Remarque :
Avant de passer à l'étape 4, assurez-vous que les fichiers actuels ne sont pas utilisés.
Sous Windows, les fichiers refuseront simplement d'être supprimés lorsqu'ils seront utilisés.
Sous Unix, le remplacement des fichiers pendant leur utilisation peut entraîner leur corruption. Utilisez la commande fuser avant de remplacer les fichiers pour vous assurer qu’ils ne sont pas utilisés.
4. Copiez les 2 fichiers .dat et éventuellement le fichier readme.txt trouvés à l'étape 2 dans le répertoire $ORACLE_HOME/oracore/zoneinfo.
5. Redémarrez la base de données (en cas d'installation sur une base de données), ou redémarrez les applications clientes (en cas d'installation client). Notez qu'il n'est pas nécessaire que la base de données soit arrêtée avant l'application des fichiers de fuseau horaire, mais qu'elle doit être redémarrée par la suite.
JAN, APR, JUL, OCT
Lorsque nous appliquons un seul patch, pouvez-vous utiliser l'utilitaire opatch ?
Oui, vous pouvez utiliser Opatch en cas de patch unique. Le seul type de patch qui ne peut pas être utilisé avec OPatch est un ensemble de patchs.
Est-il possible d'appliquer OPATCH sans temps d'arrêt ?
Comme vous le savez, pour appliquer le correctif, votre base de données et votre écouteur doivent être en panne. Lorsque vous appliquez OPTACH, il mettra à jour votre ORACLE_HOME actuel. Venant ainsi à votre question, en fait, il n'est pas possible sans temps d'arrêt ou sans temps d'arrêt en cas d'instance unique, mais dans RAC, vous pouvez appliquer Opatch sans temps d'arrêt car il y aura plus d'ORACLE_HOME séparé et plus d'instances distinctes (exécutées une seule fois sur chaque ORACLE_HOME). ).
Lorsque vous avez déplacé des fichiers binaires Oracle d'un serveur ORACLE_HOME vers un autre serveur, quel utilitaire Oracle sera utilisé pour rendre ce nouvel ORACLE_HOME utilisable ?
Reliez tout.
Vous disposez d'une collection de patch (près de 100 patchs) ou d'un ensemble de patchs. Comment pouvez-vous appliquer un seul patch à partir de celui-ci ?
Avec Napply lui-même (en fournissant l'emplacement du correctif et l'identifiant du correctif spécifique), vous ne pouvez appliquer qu'un seul correctif à partir d'une collection de correctifs extraits. Pour plus d'informations, consultez l'utilitaire opatch NApply –help. Cela vous donnera une image claire.
Par exemple :
opatch util napply <patch_location> -id 9 -skip_subset -skip_duplicate
Cela appliquera uniquement l'ID de correctif 9 à partir de l'emplacement du correctif et ignorera les doublons et les sous-ensembles de correctifs installés dans votre ORACLE_HOME.
Si le CPU et le PSU sont disponibles pour une version donnée, laquelle préférerez-vous postuler ?
D'après la discussion ci-dessus, il est clair qu'une fois que vous appliquez le bloc d'alimentation, la méthode recommandée consiste à appliquer uniquement le bloc d'alimentation suivant. En fait, il n'est pas nécessaire d'appliquer le processeur sur le dessus du bloc d'alimentation, car le bloc d'alimentation contient du processeur (si vous appliquez le processeur sur le bloc d'alimentation, vous considérerez que vous essayez de restaurer le bloc d'alimentation et que cela nécessitera en fait plus d'efforts). Donc, si vous n’avez décidé ou appliqué aucun des correctifs, je vous suggérerai d’utiliser les correctifs PSU. Pour plus de détails, reportez-vous : Produits Oracle [ID 1430923.1], ID 1446582.1
Le bloc d'alimentation est un surensemble de processeur, alors pourquoi quelqu'un choisit-il d'appliquer un processeur plutôt qu'un bloc d'alimentation ?
Les processeurs sont plus petits et plus ciblés que les blocs d'alimentation et traitent principalement des problèmes de sécurité. Cela semble être théoriquement une approche plus consécutive et peut causer moins de problèmes que le bloc d'alimentation car il contient moins de changements de code. Ainsi, pour quiconque s'intéresse uniquement aux correctifs de sécurité et non aux correctifs de fonctionnalités, le processeur peut être une bonne approche.
Comment télécharger des patchs, patchset ou Opatch depuis metalink ?
Si vous utilisez le dernier support.oracle.com, après vous être connecté au tableau de bord metalink
- Cliquez sur l'onglet "Patches et mises à jour"
- Dans la barre latérale gauche, cliquez sur "Derniers correctifs" sous "Oracle Server/Tools".
- Une nouvelle fenêtre apparaîtra.
- Passez simplement la souris sur votre produit dans la page « Derniers correctifs Oracle Server/Tools ».
- La version correspondante de la plateforme Oracle apparaîtra. Ensuite, choisissez simplement la version du patchset et cliquez dessus.
- Vous accéderez à la page de téléchargement. À partir de la page de téléchargement, vous pouvez également modifier votre plate-forme et la version de votre ensemble de correctifs.
RÉFÉRENCES :
http://docs.oracle.com/cd/E11857_01/em.111/e12255/e_oui_appendix.htm
Oracle® Universal Installer et OPatch User's Guide
11g Release 2 (11.2) pour Windows et UNIX
Numéro de pièce E12255-11
Qu'est-ce que le patch récent a-t-il été appliqué ? Patch PSU de janvier 2016 Qu'est-ce qu'OPatch ? C'est l'utilitaire pour appliquer le patch. Comment appliquer Opatch dans Oracle ? 1. Vous DEVEZ lire le fichier Readme.txt inclus dans le fichier opatch, recherchez toute condition préalable. étapes/étapes post-installation ou modifications liées à la base de données. Assurez-vous également que vous disposez de la version opatch correcte requise par ce correctif. 2.Assurez-vous d'avoir une bonne sauvegarde de la base de données. 3. Notez tous les objets non valides dans la base de données avant le patch. 4. Arrêtez tous les processus Oracle exécutés à partir de cet Oracle Home, y compris l'instance d'écoute et de base de données, l'agent de gestion, etc. 5. Vous DEVEZ sauvegarder votre oracle Home et votre inventaire tar -cvf $ORACLE_HOME $ORACLE_HOME/oraInventory | gzip > Backup_Software_Version.tar.gz 6. Décompressez le correctif dans $ORACLE_HOME/patches 7. cd dans le répertoire du correctif et exécutez opatch -apply pour appliquer le correctif. 8. Lisez le fichier de sortie/journal pour vous assurer qu'il n'y a pas eu d'erreurs. Patcher le logiciel Oracle avec OPatch ? opatch napply <patch_location> -skip_subset -skip_duplicate OPatch ignore les correctifs en double et les sous-ensembles de correctifs (correctifs sous <patch_location> qui sont des sous-ensembles de correctifs installés dans le répertoire d'accueil Oracle). Qu’est-ce qu’Opactch dans Oracle ? Utilitaire OPATCH (correctif Oracle RDBMS) 1. Téléchargez le correctif requis depuis Metalink en fonction de la version du système d'exploitation et de la version de la base de données. 2. Besoin de désactiver la base de données avant d'appliquer le correctif. 3. Décompressez et appliquez le correctif à l'aide de la commande « opatch apply ». Une fois le correctif appliqué avec succès, vous verrez le message réussi « OPatch réussi ». Vérifiez que votre correctif est appliqué à l'aide de la commande « opatch lsinventory ». 4. Chaque correctif a un identifiant unique, la commande pour restaurer un correctif est la commande « opatch rollback -id <patch no.> ». Une fois le correctif appliqué avec succès, vous verrez le message de réussite « OPatch réussi ». Vérifiez que votre correctif est appliqué. en utilisant la commande « opatch lsinventory ». 5. Le format du fichier de correctif sera du type « p<patch no.>_<db version>_<os>.zip ». 6. Nous pouvons vérifier la version d'opatch à l'aide de la commande « opatch -version ». 7. Généralement, il faut 2 minutes pour appliquer un patch.
8. Pour obtenir la dernière version d'Opatch, téléchargez « patch 6880880 - dernier outil opatch », il contient le répertoire OPatch.
9. Le contenu des correctifs téléchargés ressemblera à « etc, des répertoires de fichiers et un fichier README ».
10. Le fichier journal de l'utilitaire Opatch peut être trouvé dans $ORACLE_HOME/cfgtoollogs/opatch
11. OPatch maintient également un index des commandes exécutées avec OPatch et les fichiers journaux qui lui sont associés dans le fichier history.txt situé dans le répertoire <ORACLE_HOME>/cfgtoollogs/opatch.
12. À partir de l'ensemble de correctifs 11.2.0.2, les ensembles de correctifs Oracle Database sont des installations complètes du logiciel Oracle Database. Cela signifie que vous n'avez pas besoin d'installer Oracle Database 11g Release 2 (11.2.0.1) avant d'installer Oracle Database 11g Release 2 (11.2.0.2).
13. La mise à niveau directe vers Oracle 10g n'est prise en charge que si votre base de données exécute l'une des versions suivantes : 8.0.6, 8.1.7, 9.0.1 ou 9.2.0. Sinon, vous devrez mettre à niveau la base de données vers l'une de ces versions ou utiliser une autre option de mise à niveau (comme l'exportation/importation).
14. Des mises à niveau directes vers 11g sont possibles à partir des bases de données existantes avec les versions 9.2.0.4+, 10.1.0.2+ ou 10.2.0.1+. Les mises à niveau à partir d'autres versions sont prises en charge uniquement via des mises à niveau intermédiaires vers une version de mise à niveau prise en charge.
http://avdeo.com/2008/08/19/opatch-utility-oracle-rdbms-patching/
Oracle version 10.2.0.4.0 à quoi fait référence chaque numéro ?
Le numéro de version d'Oracle fait référence à :
10 – Numéro de version principale de la base de données
2 – Numéro de version de maintenance de la base de données
0 – Numéro de version du serveur d'applications
4 – Numéro de version spécifique au composant
0 – Numéro de version spécifique à la plate-forme
Types de correctifs ?
Comment restaurer un patch ?
Qu’est-ce que le bloc d’alimentation ?
Qu’est-ce que Rolling Patch ?
Comment vérifier les correctifs installés ?
Combien de temps faudra-t-il pour appliquer les correctifs ?
Problèmes courants rencontrés lors de l'application de correctifs ?
Clonage
=======
Qu'est-ce que le clonage ? Comment prendre le clonage RMAN ? Expliquer les étapes ? Mise à niveau ======= Qu'est-ce que la mise à niveau continue ? Il s'agit d'une nouvelle fonctionnalité ASM de la base de données 11g. Les instances ASM de la version Oracle Database 11g (à partir de 11.1) peuvent être mises à niveau ou corrigées à l'aide de la fonctionnalité de mise à niveau continue. Cela nous permet de corriger ou de mettre à niveau les nœuds ASM dans un environnement en cluster sans affecter la disponibilité de la base de données. Lors d'une mise à niveau continue, nous pouvons maintenir un cluster fonctionnel pendant qu'un ou plusieurs nœuds du cluster s'exécutent dans différentes versions logicielles. La mise à niveau continue peut être utilisée uniquement pour les versions de base de données Oracle 11g (à partir de 11.1). Étapes pour mettre à niveau dans Oracle ? Mise à niveau manuelle qui implique les étapes suivantes : 1. Sauvegardez la base de données.
2.Dans les environnements UNIX/Linux, définissez les variables $ORACLE_HOME et $PATH pour qu'elles pointent vers le nouveau répertoire d'accueil Oracle 11g.
3.Analysez l'instance existante à l'aide du script "$ORACLE_HOME/rdbms/admin/utlu111i.sql".
4.Démarrez la base de données d'origine à l'aide de la commande STARTUP UPGRADE et procédez à la mise à niveau en exécutant le script "$ORACLE_HOME/rdbms/admin/catupgrd.sql".
5.Recompilez les objets invalides.
6.Redémarrez la base de données.
7.Exécutez le script "$ORACLE_HOME/rdbms/admin/utlu111s.sql" et vérifiez le résultat de la mise à niveau.
8.Résolvez tout problème ou abandonnez la mise à niveau.
Que se passe-t-il lorsque vous donnez « STARTUP UPGRADE » ?
$sqlplus "/as sysdba"
SQL> STARTUP UPGRADE
Remarque :
----
Le mot-clé UPGRADE vous permet d'ouvrir une base de données basée sur une version antérieure d'Oracle Database. Il restreint également les connexions aux sessions AS SYSDBA, désactive les déclencheurs système et effectue des opérations supplémentaires qui préparent l'environnement pour la mise à niveau.
Vous devrez peut-être utiliser l'option PFILE pour spécifier l'emplacement de votre fichier de paramètres d'initialisation.
Une fois la base de données démarrée en mode mise à niveau, seules les requêtes sur les vues fixes s'exécutent sans erreur jusqu'à l'exécution du script catupgrd.sql. Avant d'exécuter catupgrd.sql, les requêtes sur toute autre vue ou l'utilisation de PL/SQL renvoient une erreur.
Quelle est la différence entre la mise à niveau au démarrage et la migration ?
migration de démarrage :
---------------
Utilisé pour mettre à niveau une base de données jusqu'à 9i.
Mise à niveau de démarrage
---------------
À partir de 10G, nous utilisons la mise à niveau de démarrage pour mettre à niveau la base de données.
Que se passe-t-il en interne lorsque vous utilisez la mise à niveau/la migration au démarrage ?
Il ajustera automatiquement quelques paramètres de base de données (init) (indépendamment de ce que vous avez défini) à certaines valeurs afin d'exécuter les scripts de mise à niveau en douceur.
d'une autre manière... il émettra quelques instructions de modification pour définir certains paramètres requis pour terminer les scripts de mise à niveau sans aucun problème.
Problèmes courants rencontrés lors de la mise à niveau ?
L'erreur est liée au fichier de fuseau horaire.
Base de données démarrée en mode mise à niveau et lancement de catupgrd.sql :
SQL> mise à niveau de démarrage
de l'instance ORACLE démarrée.
Zone globale totale du système 6413680640 octets
Taille fixe 2160112 octets
Taille variable 1946159632 octets
Tampons de base de données 4429185024 octets
Tampons de rétablissement 36175872 octets
Base de données montée.
Base de données ouverte.
SQL> @catupgrd.sql
DOC>######################################### #############################
DOC>################### ################################################# ##
DOC>
DOC> La première fois que ce script est exécuté, aucun message d'erreur DOC> ne devrait être généré ; tous les messages d'erreur de mise à niveau normaux sont supprimés.
DOC>
DOC> Si ce script est réexécuté après avoir corrigé un problème, alors
DOC> attendez-vous à l'erreur suivante qui n'est pas automatiquement supprimée :
DOC>
DOC> ORA-00001 : contrainte unique () violée
DOC>#
FROM Registry$database
*
ERREUR à la ligne 2 :
ORA-00942 : la table ou la vue n'existe pas.
Cette erreur est liée au fichier de fuseau horaire qui doit être la version 4 pour Oracle version 11g. Si le fuseau horaire n'est pas la version 4, un correctif doit être appliqué.
La requête pour vérifier le fichier de fuseau horaire est :
SQL> select * from v$timezone_file ;
VERSION DU NOM DE FICHIER
———— ———-
timezlrg.dat 4
SQL> select * from v$timezone_file;
VERSION DU NOM DE FICHIER
———— ———-
timezlrg.dat 4
J'avais donc la version correcte. Je me souviens avoir appliqué le correctif avant la mise à niveau. J'ai eu de la chance car le correctif existait pour la version 10.2.0.3.
S'il n'existe pas de correctif pour vos versions Oracle, le correctif peut être téléchargé pour une version similaire et appliqué manuellement.
Les instructions sont ci-dessous :
1. Téléchargez le correctif identifié.
2. Décompressez le patch et localisez les 2 fichiers timezone.dat et timezlrg.dat dans le répertoire « files/oracore/zoneinfo » du patch non compressé (ou dans le fichier .jar correspondant d'un ensemble de patchs). S'il y a également un fichier readme.txt à cet emplacement, notez-le également.
3. Sauvegardez vos fichiers existants dans $ORACLE_HOME/oracore/zoneinfo – CELA PEUT ÊTRE VITAL, NE PAS SAUTER.
Remarque :
Avant de passer à l'étape 4, assurez-vous que les fichiers actuels ne sont pas utilisés.
Sous Windows, les fichiers refuseront simplement d'être supprimés lorsqu'ils seront utilisés.
Sous Unix, le remplacement des fichiers pendant leur utilisation peut entraîner leur corruption. Utilisez la commande fuser avant de remplacer les fichiers pour vous assurer qu’ils ne sont pas utilisés.
4. Copiez les 2 fichiers .dat et éventuellement le fichier readme.txt trouvés à l'étape 2 dans le répertoire $ORACLE_HOME/oracore/zoneinfo.
5. Redémarrez la base de données (en cas d'installation sur une base de données), ou redémarrez les applications clientes (en cas d'installation client). Notez qu'il n'est pas nécessaire que la base de données soit arrêtée avant l'application des fichiers de fuseau horaire, mais qu'elle doit être redémarrée par la suite.
lundi 2 mai 2016
Questions et réponses pour l'entretien d'embauche avec Oracle DBA - RAC
Qu’est-ce que le RAC ?
RAC signifie Cluster d'applications réelles.
Il s'agit d'une solution de clustering d'Oracle Corporation qui garantit la haute disponibilité des bases de données en fournissant des fonctionnalités de basculement d'instance et de basculement de médias.
Oracle RAC est une base de données en cluster dotée d'une architecture de cache partagé qui surmonte les limites des approches traditionnelles sans partage et disque partagé pour fournir une solution de base de données hautement évolutive et disponible pour toutes les applications métier.
Oracle RAC constitue la base du calcul en grille d'entreprise.
Pourquoi devons-nous créer un nombre impair de disques de vote ?
En ce qui concerne les disques de vote, un nœud doit pouvoir accéder à tout moment strictement à plus de la moitié des disques de vote. Donc, si vous voulez pouvoir tolérer une panne de n disques votants, vous devez en avoir au moins 2n+1 configurés. (n=1 signifie 3 disques votants). Vous pouvez configurer jusqu'à 32 disques votants, offrant ainsi une protection contre 15 pannes de disque simultanées.
Oracle recommande aux clients d'utiliser au moins 3 disques de vote dans Oracle RAC 10g version 2. Remarque : pour une meilleure disponibilité, les 3 fichiers de vote doivent être des disques physiquement séparés. Il est recommandé d'utiliser un nombre impair car 4 disques ne seront pas plus hautement disponibles que 3 disques, 1/2 de 3 est 1,5...arrondi à 2, 1/2 de 4 est 2, une fois que nous perdons 2 disques, notre cluster échouera avec 4 disques votants ou 3 disques votants.
Le cluster vérifie-t-il réellement le décompte des votes avant l'expulsion du nœud ? Si oui, pourriez-vous expliquer brièvement ce processus ?
Oui. Si vous perdez la moitié ou plus de tous vos disques de vote, les nœuds sont expulsés du cluster ou les nœuds s'expulsent eux-mêmes du cluster.
Comment OCSSD démarre-t-il en premier si le disque de vote et l'OCR résident dans les groupes de disques ASM ?
Vous vous demandez peut-être comment le CSSD, requis pour démarrer l'instance ASM en cluster, peut être démarré si les disques de vote sont stockés dans ASM ?
Cela ressemble à un problème de poule et d'œuf :
sans accès aux disques votants, il n'y a pas de CSS, le nœud ne peut donc pas rejoindre le cluster.
Mais sans faire partie du cluster, CSSD ne peut pas démarrer l'instance ASM.
Pour résoudre ce problème, les en-têtes de disque ASM ont de nouvelles métadonnées dans la version 11.2 :
vous pouvez utiliser kfed pour lire l'en-tête d'un disque ASM contenant un disque votant.
Les champs kfdhdb.vfstart et kfdhdb.vfend indiquent à CSS où trouver le fichier de vote. Cela ne nécessite pas que l’instance ASM soit active.
Une fois les disques de vote localisés, CSS peut y accéder et rejoindre le cluster.
Qu’est-ce que gsdctl dans RAC ? répertorier les commandes gsdctl dans Oracle RAC ?
GSDCTL signifie Global Service Daemon Control, nous pouvons utiliser les commandes gsdctl pour démarrer, arrêter et obtenir l'état du service GSD sur n'importe quelle plateforme.
Les options pour gsdctl sont :-
$ gsdctl start -- Pour démarrer le service GSD
$ gsdctl stop -- Pour arrêter le service GSD
$ gsdctl stat -- Pour obtenir l'état du service GSD
Emplacement du fichier journal pour gsdctl :
$ ORACLE_HOME/srvm /log/gsdaemon_node_name.log
Qu'est-ce qu'Oracle RAC One Node ?
Oracle RAC one Node est une instance unique exécutée sur un nœud du cluster tandis que le deuxième nœud est en mode veille froide. Si l'instance échoue pour une raison quelconque, un nœud RAC la détecte et redémarre l'instance sur le même nœud ou l'instance est déplacée vers le 2ème nœud en cas de panne ou de panne dans le 1er nœud. L’avantage de cette fonctionnalité est qu’elle fournit une solution de basculement à froid et qu’elle automatise la relocalisation de l’instance sans aucun temps d’arrêt et ne nécessite aucune intervention manuelle. Oracle a introduit cette fonctionnalité avec la version 11gR2 (disponible avec Enterprise Edition).
Qu'est-ce que RAC et en quoi est-il différent des bases de données non RAC ?
Les clusters Oracle Real Application permettent à plusieurs instances d'accéder à une seule base de données, les instances s'exécuteront sur plusieurs nœuds.
Dans les environnements Real Application Clusters, tous les nœuds exécutent simultanément des transactions sur la même base de données.
Real Application Clusters coordonne l'accès de chaque nœud aux données partagées pour assurer la cohérence et l'intégrité.
Quels sont les avantages du RAC (Real Application Clusters) ?
Fiabilité : si un nœud tombe en panne, la base de données ne échouera pas.
Disponibilité : des nœuds peuvent être ajoutés ou remplacés sans avoir à arrêter la base de données.
Évolutivité : davantage de nœuds peuvent être ajoutés au cluster à mesure que la charge de travail augmente.
Qu'est-ce que Cache Fusion ?
Oracle RAC est composé de deux instances ou plus. Lorsqu'un bloc de données est lu à partir d'un fichier de données par une instance du cluster et qu'une autre instance a besoin du même bloc, il est facile d'obtenir l'image du bloc à partir de l'instance qui a le bloc dans son SGA plutôt que de lire à partir du disque. . Pour activer la communication entre instances, Oracle RAC utilise des interconnexions. Le service Global Enqueue (GES) surveille et le processus de mise en file d'attente des instances gère la fusion du cache.
Quelle commande utiliseriez-vous pour vérifier la disponibilité du système RAC ?
crs_stat -t -v (-t -v sont facultatifs)
Comment vérifier que les instances RAC sont en cours d'exécution ?
SQL>sélectionnez * dans V$ACTIVE_INSTANCES ;
La requête donne le numéro d'instance dans la colonne INST_NUMBER, host_:instancename sous la colonne INST_NAME.
Comment pouvez-vous vous connecter à un nœud spécifique dans un environnement RAC ?
tnsnames.ora assurez-vous que INSTANCE_NAME y est spécifié.
Quel est le « NŒUD MAÎTRE » dans RAC ?
Le nœud avec le numéro de nœud le plus bas deviendra le nœud maître et une remasterisation dynamique des ressources aura lieu.
Pour connaître le nœud maître d'une ressource particulière, vous pouvez interroger v$ges_resource pour la colonne MASTER_NODE.
Pour savoir quel est le nœud maître, vous pouvez consulter le fichier ocssd.log et rechercher le « numéro de nœud maître ».
lorsque le premier nœud maître échoue dans le cluster, le numéro de nœud le plus bas deviendra le nœud maître.
Quels composants de RAC doivent résider dans un stockage partagé ?
Tous les fichiers de données, fichiers de contrôle, SPFIles et fichiers de journalisation doivent résider sur un stockage de destruction prenant en charge le cluster.
Donnez quelques exemples de solutions prenant en charge le stockage en cluster ?
·ASM (gestion automatique du stockage),
·Périphériques de disque brut,
·Système de fichiers réseau (NFS),
·OCFS2 et
·OCFS (systèmes Oracle Cluster Fie).
Que sont les composants du cluster Oracle ?
1. Interconnexion de cluster (HAIP)
2. Stockage partagé (OCR/Disque de vote)
3. Logiciel Clusterware
4. Composants du noyau Oracle
Que sont les composants Oracle RAC ?
VIP, applications Node, etc.
Que sont les composants du noyau Oracle ?
Fondamentalement, le noyau Oracle doit être activé avec l'option RAC On lorsque vous convertissez en RAC, c'est la différence car cela facilite quelques processus bg RAC comme LMON, LCK, LMD, LMS etc.
Comment activer RAC ?
# lier les bibliothèques Oracle
$ cd $ORACLE_HOME/rdbms/lib
$ make -f ins_rdbms.mk rac_on
# reconstruire Oracle
$ cd $ORACLE_HOME/bin
$ relier Oracle
Architecture de disque dans RAC ?
SAN (Storage Area Networks) - utilisant généralement la fibre pour se connecter au SAN
NAS (Network Attached Storage) - utilisant généralement un réseau pour se connecter au NAS en utilisant soit NFS, ISCSI
Qu’est-ce qu’Oracle Clusterware ?
Le logiciel Clusterware permet aux nœuds de communiquer entre eux et forme le cluster qui fait fonctionner les nœuds comme un seul serveur logique.
Le logiciel est exécuté par Cluster Ready Services (CRS) à l'aide d'Oracle Cluster Registry (OCR) qui enregistre et conserve les informations d'appartenance au cluster et aux nœuds ainsi que le disque de vote qui agit comme une condition de départage lors des échecs de communication. Des informations de pulsation cohérentes transitent via l'interconnexion jusqu'au disque votant lorsque le cluster est en cours d'exécution.
Clusters d'applications réels
Oracle RAC est une base de données en cluster avec une architecture de cache partagé qui surmonte les limites des approches traditionnelles sans partage et disque partagé pour fournir une solution de base de données hautement évolutive et disponible pour toutes vos applications métier. Oracle RAC constitue la base du calcul en grille d'entreprise.
L'option Real Application Clusters (RAC) d'Oracle prend en charge le déploiement transparent d'une base de données unique sur un cluster de serveurs, offrant ainsi une tolérance aux pannes en cas de pannes matérielles ou de pannes planifiées. Oracle RAC exécuté sur des clusters offre le plus haut niveau de capacité d'Oracle en termes de disponibilité, d'évolutivité et de calcul à faible coût.
Une base de données ouverte par plusieurs instances afin que la base de données soit hautement disponible en cas de panne d'une instance.
Logiciel de cluster. Oracles Clusterware ou des produits comme Veritas Volume Manager sont nécessaires pour fournir la prise en charge du cluster et permettre à chaque nœud de savoir quels nœuds appartiennent au cluster et sont disponibles et avec Oracle Cluterware de savoir quels nœuds ont échoué et de les éjecter du cluster, de sorte que les erreurs sur ce nœud peuvent être effacées.
Oracle Clusterware comporte deux composants clés Cluster Registry OCR et Voting Disk.
Le registre du cluster contient toutes les informations sur les nœuds, les instances, les services et le stockage ASM s'il est utilisé, il contient également des informations sur l'état, c'est-à-dire qu'ils sont disponibles et à jour ou similaires.
Le disque de vote est utilisé pour déterminer si un nœud a échoué, c'est-à-dire s'il s'est séparé de la majorité. Si un nœud est considéré comme n'appartenant plus à la majorité, il est redémarré de force et, après le redémarrage, s'ajoutera à nouveau aux nœuds de cluster survivants.
Quels sont les composants clés d'Oracle Clusterware ?
Oracle Clusterware comporte deux composants clés Cluster Registry OCR et Voting Disk.
Qu'est-ce que le disque de vote et l'OCR ? Disque de vote : Oracle RAC utilise le disque de vote pour gérer l'appartenance au cluster au moyen d'une vérification de l'état et arbitre la propriété du cluster entre les instances en cas de panne de réseau. Le disque de vote doit résider sur un disque partagé. Un nœud doit pouvoir accéder à plus de la moitié des disques votants à tout moment.
Par exemple, si 3 disques votants sont configurés, un nœud doit pouvoir accéder à au moins deux des disques votants à tout moment. Si un nœud ne peut pas accéder au nombre minimum requis de disques votants, il est expulsé ou supprimé du cluster.
Registre de cluster Oracle (OCR)
Le registre de cluster contient toutes les informations sur les nœuds, les instances, les services et le stockage ASM s'il est utilisé, il contient également des informations sur l'état, c'est-à-dire qu'ils sont disponibles et à jour ou similaires.
L'OCR doit résider sur un disque partagé accessible par tous les nœuds de votre cluster.
Quelles sont les tâches administratives liées au disque de vote ?
Les tâches administratives suivantes sont effectuées avec le disque de vote :
1) Sauvegarde des disques de vote
2) Récupération des disques de vote
3) Ajout de disques de vote
4) Suppression des disques de vote
5) Déplacement des disques de vote
Pouvez-vous ajouter un disque de vote en ligne ? Avez-vous besoin d'une sauvegarde du disque de vote ?
Oui, selon la documentation, si vous avez plusieurs disques de vote, vous pouvez les ajouter en ligne, mais si vous n'avez qu'un seul disque de vote, ce cluster sera en panne car il sera perdu, il vous suffit de démarrer crs en mode exclusif et d'ajouter le disque de vote en utilisant
crsctl. add votedisk <path>
Quelle est la recommandation Oracle pour la sauvegarde du disque de vote ?
Oracle nous recommande d'utiliser la commande dd pour sauvegarder le disque de vote avec une taille de bloc minimale de 4 Ko.
Comment sauvegarder les disques de vote ?
1) Oracle vous recommande de sauvegarder votre disque de vote après la création initiale du cluster et après avoir terminé toute procédure d'ajout ou de suppression de nœud.
2) Tout d'abord, en tant qu'utilisateur root, arrêtez Oracle Clusterware (avec la commande crsctl stop crs) sur tous les nœuds. Ensuite, déterminez le disque de vote actuel en exécutant la commande suivante :
crsctl query votedisk css
3) Ensuite, exécutez la commande dd ou ocopy pour sauvegarder un disque de vote, selon le cas.
Donnez la syntaxe de sauvegarde des disques de vote : -
Sur les systèmes Linux ou UNIX :
dd if=voting_disk_name of=backup_file_name
où,
vote_disk_name est le nom du disque de vote actif
backup_file_name est le nom du fichier dans lequel nous voulons sauvegarder le vote contenu du disque
Sur les systèmes Windows, utilisez la commande ocopy :
copy vote_disk_name backup_file_name
Comment vérifier une sauvegarde actuelle existante d'OCR ?
Nous pouvons vérifier la sauvegarde actuelle de l'OCR à l'aide de la commande suivante : ocrconfig -showbackup
Vous avez perdu le disque OCR, quelle est votre prochaine étape ?
La pile de cluster sera en panne car cssd est incapable de maintenir l'intégrité, cela est vrai dans 10g. À partir de 11gR2, la pile crsd sera en panne, le hasd toujours opérationnel. Vous pouvez rajouter l'ocr en restaurant la sauvegarde automatique ou importer la sauvegarde manuelle,
Quels sont les principaux événements d’attente RAC ?
Dans un environnement RAC, le cache tampon est global sur toutes les instances du cluster et le traitement diffère donc. Les événements d'attente les plus courants liés à cela sont la requête gc cr et la
requête gc buffer occupé GC CR : le temps nécessaire pour récupérer les données de le cache distant
Raison : trafic RAC utilisant une connexion lente ou des requêtes inefficaces (les requêtes mal réglées augmenteront la quantité de blocs de données demandés par une session Oracle. Plus il y a de blocs demandés, plus un bloc devra être lu à partir d'une instance distante. via l'interconnexion.)
GC BUFFER BUSY : C'est le temps que l'instance distante passe localement à accéder au bloc de données demandé.
Que faites-vous si vous voyez GC CR BLOCK LOST dans les 5 principaux événements chronométrés du rapport AWR ?
Cela est probablement dû à un défaut du réseau d'interconnexion.
Vérifiez netstat -s
si vous voyez « fragments supprimés » ou « échec du réassemblage de paquets ». Travaillez avec votre administrateur système pour trouver le problème du réseau.
Comment dépanner le redémarrage du nœud ?
Veuillez vérifier metalink...
Note 265769.1 Dépannage des redémarrages de CRS
Note.559365.1 Utilisation de Diagwait comme diagnostic pour obtenir plus d'informations sur le diagnostic des expulsions de nœuds Oracle Clusterware.
Srvctl ne peut pas démarrer l'instance, j'obtiens l'erreur suivante PRKP-1001 CRS-0215, mais sqlplus peut-il la démarrer sur les deux nœuds ? Comment identifier le problème ?
Définissez la variable d'environnement SRVM_TRACE sur true. Et démarrez l'instance avec srvctl. Vous obtiendrez maintenant une pile d’erreurs détaillée.
Que sont les processus Oracle Clusterware pour 10g sous Unix et Linux ?
Services de synchronisation de cluster (ocssd) : gère l'adhésion aux nœuds de cluster et s'exécute en tant qu'utilisateur Oracle ; l'échec de ce processus entraîne le redémarrage du cluster.
Cluster Ready Services (crsd) — Le processus crs gère les ressources du cluster (qui peuvent être une base de données, une instance, un service, un écouteur, une adresse IP virtuelle (VIP), un processus d'application, etc.) en fonction de la configuration de la ressource. informations stockées dans l'OCR. Cela inclut les opérations de démarrage, d’arrêt, de surveillance et de basculement. Ce processus s'exécute en tant qu'utilisateur racine
Démon du gestionnaire d'événements (evmd) : un processus en arrière-plan qui publie les événements créés par crs.
Process Monitor Daemon (OPROCD) : ce processus surveille le cluster et fournit une séparation des E/S. OPROCD effectue sa vérification, arrête de fonctionner et si le réveil dépasse l'heure prévue, alors OPROCD réinitialise le processeur et redémarre le nœud. Un échec OPROCD entraîne le redémarrage du nœud par Oracle Clusterware. OPROCD utilise le minuteur hangcheck sur les plates-formes Linux.
RACG (racgmain, racgimon) : étend le clusterware pour prendre en charge les exigences spécifiques à Oracle et les ressources complexes. Exécute des scripts d'appel du serveur lorsque des événements FAN se produisent.
Quels sont les processus en arrière-plan de la base de données Oracle spécifiques à RAC ?
Oracle RAC est composé de deux ou plusieurs instances de base de données. Elles sont composées de structures de mémoire et de processus d'arrière-plan identiques à ceux de la base de données à instance unique. Les instances Oracle RAC utilisent deux processus GES (Global Enqueue Service) et GCS (Global Cache Service) qui permettent la fusion du cache. Les instances Oracle RAC sont composées des processus d'arrière-plan suivants :
ACMS—Atomic Controlfile to Memory Service (ACMS)
GTX0-j—Processus de transaction global
LMON—Moniteur du service de mise en file d'attente global
LMD—Démon du service de mise en file d'attente global
LMS—Processus du service de cache global
LCK0—Processus de mise en file d'attente d'instance
RMSn—Processus de gestion Oracle RAC (RMSn)
RSMN —Remote Slave Monitor
Pour garantir que chaque instance de base de données Oracle RAC obtient le bloc dont elle a besoin pour satisfaire une requête ou une transaction, les instances Oracle RAC utilisent deux processus, le service de cache global (GCS) et le service de mise en file d'attente globale (GES). Le GCS et le GES conservent des enregistrements des statuts de chaque fichier de données et de chaque bloc mis en cache à l'aide d'un répertoire de ressources global (GRD). Le contenu GRD est distribué sur toutes les instances actives.
Qu’est-ce que le GRD ?
GRD signifie Répertoire mondial des ressources. Le GES et le GCS conservent des enregistrements des statuts de chaque fichier de données et de chaque bloc mis en cache à l'aide du répertoire de ressources global. Ce processus est appelé fusion de cache et contribue à l'intégrité des données.
Qu’est-ce qu’ACMS ?
ACMS signifie Atomic Controlfile Memory Service. Dans un environnement Oracle RAC, ACMS est un agent qui garantit qu'une mise à jour de mémoire SGA distribuée (c'est-à-dire) que les mises à jour SGA sont globalement validées en cas de succès ou globalement abandonnées en cas d'échec.
Qu'est-ce que l'écouteur SCAN ?
Un écouteur d'analyse est quelque chose qui s'ajoute à l'écouteur de nœud qui écoute les demandes de connexion à la base de données entrantes du client qui ont transité par l'adresse IP d'analyse, il a configuré les points de terminaison sur l'écouteur de nœud où il achemine les demandes de connexion à la base de données vers un écouteur de nœud particulier.
SCAN IP peut être désactivé s’il n’est pas nécessaire. Cependant SCAN IP est obligatoire lors de l'installation du RAC. L'activation/la désactivation de SCAN IP est principalement utilisée dans l'environnement des applications Oracle par le gestionnaire simultané (sorte de planificateur de tâches dans les applications Oracle).
Étapes pour désactiver le SCAN IP,
i. N'utilisez pas SCAN IP côté client.
ii. Arrêter l'écouteur d'analyse
srvctl stop scan_listener
iii. Arrêter l'analyse
srvctl stop scan (cela arrêtera l'analyse vip)
iv. Désactiver l'analyse et désactiver l'écouteur d'analyse
srvctl désactiver l'analyse
Quels sont les différents composants réseau du 10g RAC ?
Composants publics, privés et VIP
Les interfaces privées sont destinées à la communication intra-nœud.
VIP est avant tout une question de disponibilité de l'application. Lorsqu'un nœud tombe en panne, le composant VIP bascule vers un autre nœud. C'est la raison pour laquelle toutes les applications doivent être basées sur des composants VIP, ce qui signifie que les entrées TNS doivent avoir une entrée VIP dans la liste d'hôtes.
Qu'est-ce qu'un réseau d'interconnexion ?
Un réseau d'interconnexion est un réseau privé qui connecte tous les serveurs d'un cluster. Le réseau d'interconnexion utilise un/plusieurs commutateurs auxquels seuls les nœuds du cluster peuvent accéder.
À quoi sert l’interconnexion de cluster ?
L'interconnexion de cluster est utilisée par la fusion de cache pour la communication inter-instances.
Comment pouvons-nous configurer l’interconnexion du cluster ?
· Configurez le protocole UDP (User Datagram Protocol) sur Gigabit Ethernet pour les interconnexions de cluster.
· Sur les systèmes UNIX et Linux, nous utilisons les protocoles UDP et RDS (Reliable data socket) destinés à être utilisés par Oracle Clusterware.
· Les clusters Windows utilisent le protocole TCP.
Quel est le but de l’interconnexion privée ?
Clusterware utilise l'interconnexion privée pour la synchronisation du cluster (battement de réseau) et la communication démon entre les nœuds du cluster. Cette communication est basée sur le protocole TCP.
RAC utilise l'interconnexion pour la fusion de cache (UDP) et la communication inter-processus (TCP). Cache Fusion est le mappage de mémoire distante des tampons Oracle, partagés entre les caches des nœuds participants du cluster.
Qu'est-ce qu'une adresse IP virtuelle ou VIP ?
Une adresse IP virtuelle ou VIP est une adresse IP alternative que les connexions client utilisent à la place de l'adresse IP publique standard. Pour configurer l'adresse VIP, nous devons réserver une adresse IP de rechange pour chaque nœud, et les adresses IP doivent utiliser le même sous-réseau que le réseau public.
A quoi sert le VIP ?
Si un nœud échoue, l'adresse VIP du nœud bascule vers un autre nœud sur lequel l'adresse VIP peut accepter les connexions TCP mais ne peut pas accepter les connexions Oracle.
Pourquoi avons-nous une adresse IP virtuelle (VIP) dans Oracle RAC ?
Sans utiliser de VIP ou de FAN, les clients connectés à un nœud décédé attendront souvent un délai d'attente TCP (qui peut aller jusqu'à 10 minutes) avant de recevoir une erreur. Par conséquent, vous n’avez pas vraiment de bonne solution HA sans utiliser de VIP.
Lorsqu'un nœud tombe en panne, le VIP qui lui est associé est automatiquement basculé vers un autre nœud et le nouveau nœud réorganise le monde en indiquant une nouvelle adresse MAC pour l'IP. Les paquets suivants envoyés au VIP vont au nouveau nœud, qui renverra les paquets RST d'erreur aux clients. Cela entraîne des erreurs immédiates pour les clients.
Donnez les situations dans lesquelles le basculement d'adresse VIP se produit ?
Le basculement des adresses VIP se produit lorsque le nœud sur lequel l'adresse VIP s'exécute tombe en panne ; toutes les interfaces pour l'adresse VIP échouent, toutes les interfaces pour l'adresse VIP sont déconnectées du réseau.
Quelle est l’importance du basculement d’adresse VIP ?
Lorsqu'un basculement d'adresse VIP se produit, les clients qui tentent de se connecter à l'adresse VIP reçoivent une erreur de refus de connexion rapide. Ils n'ont pas à attendre les messages d'expiration de connexion TCP.
A quoi sert un service dans l’environnement Oracle RAC ?
Les applications doivent utiliser la fonctionnalité de services pour se connecter à la base de données Oracle. Les services nous permettent de définir des règles et des caractéristiques pour contrôler la manière dont les utilisateurs et les applications se connectent aux instances de base de données.
Quelles sont les caractéristiques contrôlées par la fonctionnalité des services Oracle ?
Les caractéristiques incluent un nom unique, un équilibrage de la charge de travail, des options de basculement et une haute disponibilité.
Qu'est-ce qui permet l'équilibrage de charge des applications dans RAC ?
Oracle Net Services permet l'équilibrage de charge des connexions d'application sur toutes les instances d'une base de données Oracle RAC.
Quels sont les types d’équilibrage de charge de connexion ?
La gestion de la charge de travail des connexions est l'un des aspects clés lorsque vous disposez d'instances RAC, car vous souhaitez distribuer les connexions à des nœuds/instances spécifiques ou à ceux qui ont moins de charge.
Il existe deux types d'équilibrage de charge de connexion :
1. Équilibrage de charge côté client (également appelé équilibrage de charge au moment de la connexion)
2. Équilibrage de charge côté serveur (également appelé équilibrage de charge de connexion d'écoute)
Quelle est la différence entre le côté serveur et le côté client -équilibrage de charge de connexion côté ?
L'équilibrage côté client se produit côté client, où l'équilibrage de charge est effectué à l'aide de l'écouteur. En cas d'équilibrage de charge côté serveur, l'écouteur utilise un avis d'équilibrage de charge pour rediriger les connexions vers l'instance fournissant le meilleur service.
Équilibrage de charge côté client : - La fonctionnalité d'équilibrage de charge côté client Oracle permet aux clients de randomiser les demandes de connexion parmi tous les écouteurs disponibles en fonction de leur charge.
Une entrée tns qui contient toutes les entrées de nœuds et utilise load_balance=on (activé par défaut) utilisera l'équilibrage de charge au moment de la connexion ou l'équilibrage de charge côté client.
Exemple d'entrée TNS côté client : -
finance =
(DESCRIPTION =
(ADRESSE = (PROTOCOLE = TCP)(HOST = myrac2-vip)(PORT = 2042))
(ADRESSE = (PROTOCOLE = TCP)(HOST = myrac1-vip)(PORT = 2042))
(ADDRESS = (PROTOCOL = TCP)(HOST = myrac3-vip)(PORT = 2042))
(LOAD_BALANCE = oui)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = FINANCE) (FAILOVER=ON)
(FAILOVER_MODE = (TYPE = SELECT) (METHOD = BASIC) (RETRIES = 180) (DELAY = 5))
)
)
Équilibrage de charge côté serveur : - Cela améliore les performances de connexion en équilibrant le nombre de connexions actives entre plusieurs instances et répartiteurs. Dans un environnement à instance unique (serveurs partagés), l'écouteur sélectionne le moindre répartiteur pour gérer les demandes client entrantes. Dans un environnement rac, PMON connaît la charge de toutes les instances et les répartiteurs, et en fonction des informations de charge, PMON redirige la connexion vers le nœud le moins chargé.
Dans un environnement RAC, le paramètre *.remote_listener qui est une entrée tns contenant toutes les adresses de nœuds doit être défini pour activer les mises à jour des conseils d'équilibrage de charge sur PMON.
L'exemple d'entrée Tns doit se trouver dans une instance du cluster RAC,
local_listener=LISTENER_MYRAC1
remote_listener = LISTENERS_MYRACDB
Quels sont les outils d'administration utilisés pour les environnements Oracle RAC ?
Le cluster Oracle RAC peut être administré comme une image unique à l'aide des éléments ci-dessous
· OEM (Enterprise Manager),
· SQL*PLUS,
· Contrôle du serveur (SRVCTL),
· Utilitaire de vérification de cluster (CLUVFY),
· DBCA,
· NETCA
Nommez certains outils Oracle Clusterware et leurs utilisations ?
· OIFCFG - allocation et désallocation des interfaces réseau.
·OCRCONFIG - Outil de ligne de commande pour gérer Oracle Cluster Registry.
·OCRDUMP - Identifiez l'interconnexion utilisée.
·CVU - Utilitaire de vérification de cluster pour obtenir l'état des ressources CRS.
Quelle est la différence entre CRSCTL et SRVCTL ?
crsctl gère les opérations liées au clusterware :
Démarrage et arrêt d'Oracle Clusterware
Activation et désactivation des démons Oracle Clusterware
Enregistrement des ressources du cluster
srvctl gère les opérations liées aux ressources Oracle :
Démarrage et arrêt des instances et des services de base de données
Également à partir de 11gR2, gère les ressources du cluster comme le réseau, vip, disques, etc.
Comment supprimer ASM d'un environnement Oracle RAC ?
Nous devons d'abord arrêter et supprimer l'instance dans le nœud en mode interactif ou silencieux. Après cela, asm peut être supprimé à l'aide de l'outil srvctl comme suit :
srvctl stop asm -n node_name
srvctl Remove asm -n node_name
Nous pouvons vérifier si ASM a été supprimé. en émettant la commande suivante :
srvctl config asm -n node_name
Comment vérifier qu'une instance a été supprimée de l'OCR après la suppression d'une instance ?
Exécutez la commande srvctl suivante :
srvctl config database -d nom_base de données
cd CRS_HOME/bin
./crs_stat
Quels sont les modes de suppression d'instances des bases de données du cluster ORacle Real Application ?
Nous pouvons supprimer des instances en mode silencieux ou en mode interactif à l'aide de DBCA (Database Configuration Assistant).
Quels sont les processus d'arrière-plan qui existent dans 11gr2 et leurs fonctionnalités ?
Nom du processus Fonctionnalité
crsd •Le démon CRS (crsd) gère les ressources du cluster en fonction des informations de configuration stockées dans Oracle Cluster Registry (OCR) pour chaque ressource. Cela inclut les opérations de démarrage, d’arrêt, de surveillance et de basculement. Le processus crsd génère des événements lorsque l'état d'une ressource change.
cssd • Service de synchronisation de cluster (CSS) : gère la configuration du cluster en contrôlant quels nœuds sont membres du cluster et en avertissant les membres lorsqu'un nœud rejoint ou quitte le cluster. Si vous utilisez un clusterware tiers certifié, CSS traite les interfaces avec votre clusterware pour gérer les informations d'appartenance aux nœuds. CSS comporte trois processus distincts : le démon CSS (ocssd), l'agent CSS (cssdagent) et le moniteur CSS (cssdmonitor). Le processus cssdagent surveille le cluster et fournit une séparation des entrées/sorties. Ce service était auparavant fourni par le démon Oracle Process Monitor (oprocd), également connu sous le nom d'OraFenceService sous Windows. Un échec de cssdagent entraîne le redémarrage d'Oracle Clusterware du nœud.
diskmon •Démon Disk Monitor (diskmon) : surveille et effectue le filtrage des entrées/sorties pour Oracle Exadata Storage Server. Comme le stockage Exadata peut être ajouté à n'importe quel nœud Oracle RAC à tout moment, le démon diskmon est toujours démarré au démarrage d'ocssd.
evmd •Event Manager (EVM) : processus en arrière-plan qui publie les événements Oracle Clusterware.
mdnsd •Service de noms de domaine multidiffusion (mDNS) : autorise les requêtes DNS. Le processus mDNS est un processus en arrière-plan sous Linux et UNIX, et un service sous Windows.
gnsd •Oracle Grid Naming Service (GNS) : est une passerelle entre le cluster mDNS et les serveurs DNS externes. Le processus GNS effectue la résolution de noms au sein du cluster.
ons •Oracle Notification Service (ONS) : service de publication et d'abonnement permettant de communiquer les événements Fast Application Notification (FAN).
oraagent •oraagent : étend le clusterware pour prendre en charge les exigences spécifiques à Oracle et les ressources complexes. Il exécute des scripts d'appel du serveur lorsque des événements FAN se produisent. Ce processus était connu sous le nom de RACG dans Oracle Clusterware 11g Release 1 (11.1).
orarootagent •Agent racine Oracle (orarootagent) : est un processus oraagent spécialisé qui aide CRSD à gérer les ressources appartenant à root, telles que le réseau, et l'adresse IP virtuelle de la grille.
oclskd •Démon de suppression de cluster (oclskd) : gère les demandes d'expulsion d'instance/de nœud qui ont été transmis au CSS
gipcd • Démon Grid IPC (gipcd) : est un démon d'assistance pour l'infrastructure de communication.
ctssd • Démon de synchronisation temporelle du cluster (ctssd) pour gérer la synchronisation temporelle entre les nœuds, plutôt en fonction de NTP.
Sous quel utilisateur ou propriétaire le processus démarrera-t-il ?
Nom du composant du propriétaire du processus
Oracle High Availability Service ohasd init, racine
Cluster Ready Service (CRS) Cluster Ready Services racine
Cluster Synchronization Service (CSS) ocssd, cssd monitor, cssdagent propriétaire de la grille
Event Manager (EVM) evmd, evmlogger propriétaire de la grille Heure
du cluster Service de synchronisation (CTSS) racine octssd
Oracle Notification Service (ONS) ons, eons propriétaire de la grille
Agent Oracle oragent propriétaire de la grille
Oracle Root Agent orarootagent racine
Grid Naming Service (GNS) racine gnsd
Grid Plug and Play (GPnP) gpnpd propriétaire de la grille
Service de nom de domaine multidiffusion (mDNS) Propriétaire de la grille mdnsd
Quelle est la principale différence entre 10g et 11g RAC ?
Il n'y a pas beaucoup de différence entre 10g et 11gR (1) RAC. Mais il existe une différence significative en 11gR2.
Avant 11gR1 (10g) RAC, les éléments suivants étaient gérés par Oracle CRS
Bases de données
Instances
Applications
Surveillance des nœuds
Services d'événements
Haute disponibilité
À partir de 11gR2 (et versions ultérieures), sa pile HA complète gère et fournit les ressources suivantes comme les autres logiciels de cluster comme VCS,
etc.
Instances
Applications
Gestion de cluster
Gestion de nœuds
Services d'événements Gestion de réseau
haute disponibilité
(fournit des services DNS/GNS/MDNSD au nom d'autres services traditionnels) et SCAN – Méthode de dénomination client à accès unique,
gestion du stockage HAIP (avec l'aide d'ASM et d'autres nouveaux systèmes de fichiers ACFS)
Synchronisation de l'heure (plutôt dépendante du NTP traditionnel)
Suppression du vérificateur de blocage dépendant du système d'exploitation, etc., géré avec son propre processus de surveillance supplémentaire.
Qu'est-ce que le temporisateur de contrôle de blocage ?
Le temporisateur Hangcheck vérifie régulièrement la santé du système. Si le système se bloque ou s'arrête, le nœud sera automatiquement redémarré.
Il y a 2 paramètres clés pour ce module :
-> hangcheck-tick : ce paramètre définit la période de temps entre les vérifications de la santé du système. La valeur par défaut est de 60 secondes ; Oracle recommande de le définir sur 30 secondes.
-> hangcheck-margin : ceci définit le délai de blocage maximum qui doit être toléré avant que hangcheck-timer ne réinitialise le nœud RAC.
Indiquer les paramètres d'initialisation qui doivent avoir la même valeur pour chaque instance dans une base de données Oracle RAC ?
Certains paramètres d'initialisation sont critiques au moment de la création de la base de données et doivent avoir les mêmes valeurs. Leur valeur doit être spécifiée dans SPFILE ou PFILE pour chaque instance. La liste des paramètres qui doivent être identiques sur chaque instance est donnée ci-dessous :
ACTIVE_INSTANCE_COUNT
ARCHIVE_LAG_TARGET
COMPATIBLE
CLUSTER_DATABASE
CLUSTER_DATABASE_INSTANCE
CONTROL_FILES
DB_BLOCK_SIZE
DB_DOMAIN
DB_FILES
DB_NAME
DB_RECOVERY_FILE_DEST
DB_RECOVERY_FILE_DEST_SIZE
DB_UNIQUE_NAME
INSTANCE_TYPE (SGBDR ou ASM)
PARALLEL_MAX_SERVERS
REMOTE_LOGIN_passWORD_FILE
UNDO_MANAGEMENT
Qu'est-ce que RAC ? Quel est l'avantage de RAC par rapport à une base de données à instance unique ?
Dans les environnements Real Application Clusters, tous les nœuds exécutent simultanément des transactions sur la même base de données. Real Application Clusters coordonne l'accès de chaque nœud aux données partagées pour assurer la cohérence et l'intégrité.
Avantages :
Améliorer le temps de réponse
Améliorer le débit
Haute disponibilité
Transparence
Avantages du RAC (Real Application Clusters)
Fiabilité - si un nœud tombe en panne, la base de données ne tombera pas en panne
Disponibilité - des nœuds peuvent être ajoutés ou remplacés sans avoir à arrêter la base de données
Évolutivité - davantage de nœuds peuvent être ajouté au cluster à mesure que la charge de travail augmente.
Qu'est-ce qu'une adresse IP virtuelle ou VIP ?
Une adresse IP virtuelle ou VIP est une adresse IP alternative que les connexions client utilisent à la place de l'adresse IP publique standard. Pour configurer l'adresse VIP, nous devons réserver une adresse IP de rechange pour chaque nœud, et les adresses IP doivent utiliser le même sous-réseau que le réseau public.
A quoi sert le VIP ?
Si un nœud échoue, l'adresse VIP du nœud bascule vers un autre nœud sur lequel l'adresse VIP peut accepter les connexions TCP mais ne peut pas accepter les connexions Oracle.
Donnez les situations dans lesquelles le basculement de l'adresse VIP se produit : -
Le basculement des adresses VIP se produit lorsque le nœud sur lequel l'adresse VIP s'exécute échoue, que toutes les interfaces pour l'adresse VIP échouent, que toutes les interfaces pour l'adresse VIP sont déconnectées du réseau.
En utilisant l'IP virtuelle, nous pouvons éviter notre problème de délai d'attente TCP/IP car le service de notification Oracle maintient la communication entre chaque nœud et écouteur.
Quelle est l’importance du basculement d’adresse VIP ?
Lorsqu'un basculement d'adresse VIP se produit, les clients qui tentent de se connecter à l'adresse VIP reçoivent une erreur de refus de connexion rapide. Ils n'ont pas à attendre les messages d'expiration de connexion TCP.
Qu'est-ce qu'un disque de vote ?
Voting Disk est un fichier qui se trouve dans la zone de stockage partagé et doit être accessible par tous les nœuds du cluster. Tous les nœuds du cluster enregistrent leurs informations de battement de cœur sur le disque de vote, afin de confirmer qu'ils sont tous opérationnels. Si les informations de battement de cœur d'un nœud du disque votant ne sont pas disponibles, ce nœud sera expulsé du cluster. Le démon CSS (Cluster Synchronization Service) du clusterware maintient le rythme cardiaque de tous les nœuds sur le disque votant. Lorsqu'un nœud n'est pas en mesure d'envoyer un battement de cœur au disque de vote, il se redémarre lui-même, aidant ainsi à éviter le syndrome du cerveau divisé.
Pour une haute disponibilité, Oracle vous recommande de disposer d'un minimum de trois disques de vote ou d'un nombre impair (3 ou plus).
Voting Disk - est un fichier qui réside sur le stockage partagé et gère les membres du cluster. Le disque de vote réaffecte la propriété du cluster entre les nœuds en cas de panne.
Les fichiers de disque de vote sont utilisés par Oracle Clusterware pour déterminer quels nœuds sont actuellement membres du cluster. Les fichiers de disque de vote sont également utilisés de concert avec d'autres composants du cluster tels que CRS pour maintenir l'intégrité des clusters.
Oracle Database 11g Release 2 offre la possibilité de stocker les disques de vote dans ASM avec l'OCR. Oracle Clusterware peut accéder à l'OCR et aux disques de vote présents dans ASM même si l'instance ASM est en panne. Par conséquent, CSS peut continuer à maintenir le cluster Oracle même si l'instance ASM échoue.
Combien de disques de vote conservez-vous ?
http://www.toadworld.com/KNOWLEDGE/KnowledgeXpertforOracle/tabid/648/TopicID/RACR2ARC6/Default.aspx
Par défaut, Oracle créera 3 fichiers de disque de vote dans ASM.
Oracle s'attend à ce que vous configuriez au moins 3 disques votants à des fins de redondance. Vous devez toujours configurer un nombre impair de disques votants >= 3. En effet, la perte de plus de la moitié de vos disques votants entraînera l'échec de l'ensemble du cluster.
Vous devez prévoir d'allouer 280 Mo pour chaque fichier de disque votant. Par exemple, si vous utilisez ASM et la redondance externe, vous devrez allouer 280 Mo de disque pour le disque votant. Si vous utilisez ASM et une redondance normale, vous aurez besoin de 560 Mo.
Pourquoi devons-nous conserver un nombre impair de disques votants ?
Oracle s'attend à ce que vous configuriez au moins 3 disques votants à des fins de redondance. Vous devez toujours configurer un nombre impair de disques votants >= 3. En effet, la perte de plus de la moitié de vos disques votants entraînera l'échec de l'ensemble du cluster.
Que sont les composants logiciels Oracle RAC ?
Oracle RAC est composé de deux ou plusieurs instances de base de données. Elles sont composées de structures de mémoire et de processus d'arrière-plan identiques à ceux de la base de données à instance unique. Les instances Oracle RAC utilisent deux processus GES (Global Enqueue Service) et GCS (Global Cache Service) qui permettent la fusion du cache. Les instances Oracle RAC sont composées des processus d'arrière-plan suivants :
ACMS—Atomic Controlfile to Memory Service (ACMS)
GTX0-j—Processus de transaction global
LMON—Moniteur du service de mise en file d'attente global
LMD—Démon du service de mise en file d'attente global
LMS—Processus du service de cache global
LCK0—Processus de mise en file d'attente d'instance
RMSn—Processus de gestion Oracle RAC (RMSn)
RSMN —Moniteur esclave à distance
Qu'est-ce que TAF ?
TAF (Transparent Application Failover) est une configuration qui permet le basculement de session entre différents nœuds d'un cluster de bases de données RAC.
Basculement d'application transparent (TAF). Si une défaillance de la liaison de communication se produit après l'établissement d'une connexion, la connexion bascule vers un autre nœud actif. Toutes les transactions interrompues sont annulées et les propriétés de session et les variables du programme côté serveur sont perdues. Dans certains cas, si l'instruction exécutée au moment du basculement est une instruction Select, cette instruction peut être automatiquement réexécutée sur la nouvelle connexion avec le curseur positionné sur la ligne sur laquelle il était positionné avant le basculement.
Après une panne d'un nœud Oracle RAC (généralement à cause d'une panne matérielle), toutes les nouvelles transactions d'application sont automatiquement redirigées vers un nœud de sauvegarde spécifié. Le défi du reroutage est de ne pas perdre les transactions qui étaient « en vol » au moment précis du crash. L'une des exigences de la disponibilité continue est la possibilité de redémarrer les transactions d'application en cours, permettant à un nœud défaillant de reprendre le traitement sur un autre serveur sans interruption. La réponse d'Oracle au basculement d'application est un nouveau mécanisme Oracle Net appelé Transparent Application Failover. TAF permet au DBA de configurer le type et la méthode de basculement pour chaque client Oracle Net.
L'architecture TAF offre la possibilité de redémarrer les transactions au niveau de la transaction (SELECT) ou de la session.
Quelle est la configuration requise pour Oracle Clusterware ?
1. Disque partagé externe pour stocker le fichier de logiciel Oracle Cluster (Disque de vote et registre de cluster Oracle - OCR)
2. Deux cartes réseau sur chaque nœud de logiciel de cluster (et trois jeux d'adresses IP) -
Carte réseau 1 (avec jeu d'adresses IP 1) pour réseau public
Carte réseau 2 (avec jeu d'adresses IP 2) pour réseau privé (pour la communication inter-nœuds entre les nœuds rac utilisés par le clusterware et la base de données rac)
Jeu d'adresses IP 3 pour IP virtuelle (VIP) (utilisé comme adresse IP virtuelle pour la connexion client et pour le basculement de la connexion)
3. Option de stockage pour OCR et disque de vote - RAW, OCFS2 (Oracle Cluster File System), NFS,…..
Qui permettent l'équilibrage de charge des applications dans RAC ?
Oracle Net Services permet l'équilibrage de charge des connexions d'application sur toutes les instances d'une base de données Oracle RAC.
Comment trouver l’emplacement du fichier OCR lorsque CRS est en panne ?
Si vous avez besoin de trouver l'emplacement de l'OCR (Oracle Cluster Registry) mais que votre CRS est en panne.
Lorsque le CRS est en panne :
Regardez dans le fichier « ocr.loc », l'emplacement de ce fichier change en fonction du système d'exploitation :
Sous Linux : /etc/oracle/ocr.loc
Sous Solaris : /var/opt/oracle/ocr.loc
Quand CRS est UP :
définissez l'environnement ASM ou l'environnement CRS, puis exécutez la commande ci-dessous :
ocrcheck
Dans un RAC à 2 nœuds, combien de cartes réseau utilisez-vous ?
2 cartes réseau sur chaque nœud clusterware
Carte réseau 1 (avec adresse IP définie 1) pour réseau public
Carte réseau 2 (avec adresse IP définie 2) pour réseau privé (pour la communication inter-nœuds entre les nœuds rac utilisés par le clusterware et la base de données rac)
En 2 nœud RAC, combien d'adresses IP r utilise-t-il ?
6 - 3 jeux d'adresses IP
## eth1-Public : 2
## eth0-Private : 2
## VIP : 2
Comment trouver les informations IP dans RAC ?
Modifiez le fichier /etc/hosts comme indiqué ci-dessous :
# Ne supprimez pas la ligne suivante, sinon divers programmes
# nécessitant une fonctionnalité réseau échoueront.
127.0.0.1 localhost.localdomain localhost
## Noms des nœuds publics
192.168.10.11 node1-pub.hingu.net node1-pub
192.168.10.22 node2-pub.hingu.net node2-pub
## Réseau privé (interconnexion)
192.168.0.11 node1- prv node1-prv
192.168.0.22 node2-prv node2-prv
## Réseau privé (stockage de zone réseau)
192.168.1.11 node1-nas node1-nas
192.168.1.22 node2-nas node2-nas
192.168.1.33 nas-server nas-server
# # IP virtuelles
192.168.10.111 node1-vip.hingu.net node1-vip
192.168.10.222 node2-vip.hingu.net node2-vip
Quelle est la différence entre les adresses IP RAC ?
L'adresse IP publique est l'adresse IP normale généralement utilisée par DBA et SA pour gérer le stockage, le système et la base de données. Les adresses IP publiques sont réservées à Internet.
L'adresse IP privée est utilisée uniquement pour le traitement du clustering interne (Cache Fusion) (c'est-à-dire comme interconnexion). Les adresses IP privées sont réservées aux réseaux privés.
VIP est utilisé par les applications de base de données pour activer le basculement en cas de panne d'un nœud de cluster. Le but d'avoir VIP est que la connexion client puisse être basculée vers les nœuds survivants en cas de panne.
Le développeur d'applications peut-il accéder à l'adresse IP privée ?
Non, l'adresse IP privée est utilisée uniquement pour le traitement du clustering interne (Cache Fusion) (alias comme interconnexion)
RAC signifie Cluster d'applications réelles.
Il s'agit d'une solution de clustering d'Oracle Corporation qui garantit la haute disponibilité des bases de données en fournissant des fonctionnalités de basculement d'instance et de basculement de médias.
Oracle RAC est une base de données en cluster dotée d'une architecture de cache partagé qui surmonte les limites des approches traditionnelles sans partage et disque partagé pour fournir une solution de base de données hautement évolutive et disponible pour toutes les applications métier.
Oracle RAC constitue la base du calcul en grille d'entreprise.
Pourquoi devons-nous créer un nombre impair de disques de vote ?
En ce qui concerne les disques de vote, un nœud doit pouvoir accéder à tout moment strictement à plus de la moitié des disques de vote. Donc, si vous voulez pouvoir tolérer une panne de n disques votants, vous devez en avoir au moins 2n+1 configurés. (n=1 signifie 3 disques votants). Vous pouvez configurer jusqu'à 32 disques votants, offrant ainsi une protection contre 15 pannes de disque simultanées.
Oracle recommande aux clients d'utiliser au moins 3 disques de vote dans Oracle RAC 10g version 2. Remarque : pour une meilleure disponibilité, les 3 fichiers de vote doivent être des disques physiquement séparés. Il est recommandé d'utiliser un nombre impair car 4 disques ne seront pas plus hautement disponibles que 3 disques, 1/2 de 3 est 1,5...arrondi à 2, 1/2 de 4 est 2, une fois que nous perdons 2 disques, notre cluster échouera avec 4 disques votants ou 3 disques votants.
Le cluster vérifie-t-il réellement le décompte des votes avant l'expulsion du nœud ? Si oui, pourriez-vous expliquer brièvement ce processus ?
Oui. Si vous perdez la moitié ou plus de tous vos disques de vote, les nœuds sont expulsés du cluster ou les nœuds s'expulsent eux-mêmes du cluster.
Comment OCSSD démarre-t-il en premier si le disque de vote et l'OCR résident dans les groupes de disques ASM ?
Vous vous demandez peut-être comment le CSSD, requis pour démarrer l'instance ASM en cluster, peut être démarré si les disques de vote sont stockés dans ASM ?
Cela ressemble à un problème de poule et d'œuf :
sans accès aux disques votants, il n'y a pas de CSS, le nœud ne peut donc pas rejoindre le cluster.
Mais sans faire partie du cluster, CSSD ne peut pas démarrer l'instance ASM.
Pour résoudre ce problème, les en-têtes de disque ASM ont de nouvelles métadonnées dans la version 11.2 :
vous pouvez utiliser kfed pour lire l'en-tête d'un disque ASM contenant un disque votant.
Les champs kfdhdb.vfstart et kfdhdb.vfend indiquent à CSS où trouver le fichier de vote. Cela ne nécessite pas que l’instance ASM soit active.
Une fois les disques de vote localisés, CSS peut y accéder et rejoindre le cluster.
Qu’est-ce que gsdctl dans RAC ? répertorier les commandes gsdctl dans Oracle RAC ?
GSDCTL signifie Global Service Daemon Control, nous pouvons utiliser les commandes gsdctl pour démarrer, arrêter et obtenir l'état du service GSD sur n'importe quelle plateforme.
Les options pour gsdctl sont :-
$ gsdctl start -- Pour démarrer le service GSD
$ gsdctl stop -- Pour arrêter le service GSD
$ gsdctl stat -- Pour obtenir l'état du service GSD
Emplacement du fichier journal pour gsdctl :
$ ORACLE_HOME/srvm /log/gsdaemon_node_name.log
Qu'est-ce qu'Oracle RAC One Node ?
Oracle RAC one Node est une instance unique exécutée sur un nœud du cluster tandis que le deuxième nœud est en mode veille froide. Si l'instance échoue pour une raison quelconque, un nœud RAC la détecte et redémarre l'instance sur le même nœud ou l'instance est déplacée vers le 2ème nœud en cas de panne ou de panne dans le 1er nœud. L’avantage de cette fonctionnalité est qu’elle fournit une solution de basculement à froid et qu’elle automatise la relocalisation de l’instance sans aucun temps d’arrêt et ne nécessite aucune intervention manuelle. Oracle a introduit cette fonctionnalité avec la version 11gR2 (disponible avec Enterprise Edition).
Qu'est-ce que RAC et en quoi est-il différent des bases de données non RAC ?
Les clusters Oracle Real Application permettent à plusieurs instances d'accéder à une seule base de données, les instances s'exécuteront sur plusieurs nœuds.
Dans les environnements Real Application Clusters, tous les nœuds exécutent simultanément des transactions sur la même base de données.
Real Application Clusters coordonne l'accès de chaque nœud aux données partagées pour assurer la cohérence et l'intégrité.
Quels sont les avantages du RAC (Real Application Clusters) ?
Fiabilité : si un nœud tombe en panne, la base de données ne échouera pas.
Disponibilité : des nœuds peuvent être ajoutés ou remplacés sans avoir à arrêter la base de données.
Évolutivité : davantage de nœuds peuvent être ajoutés au cluster à mesure que la charge de travail augmente.
Qu'est-ce que Cache Fusion ?
Oracle RAC est composé de deux instances ou plus. Lorsqu'un bloc de données est lu à partir d'un fichier de données par une instance du cluster et qu'une autre instance a besoin du même bloc, il est facile d'obtenir l'image du bloc à partir de l'instance qui a le bloc dans son SGA plutôt que de lire à partir du disque. . Pour activer la communication entre instances, Oracle RAC utilise des interconnexions. Le service Global Enqueue (GES) surveille et le processus de mise en file d'attente des instances gère la fusion du cache.
Quelle commande utiliseriez-vous pour vérifier la disponibilité du système RAC ?
crs_stat -t -v (-t -v sont facultatifs)
Comment vérifier que les instances RAC sont en cours d'exécution ?
SQL>sélectionnez * dans V$ACTIVE_INSTANCES ;
La requête donne le numéro d'instance dans la colonne INST_NUMBER, host_:instancename sous la colonne INST_NAME.
Comment pouvez-vous vous connecter à un nœud spécifique dans un environnement RAC ?
tnsnames.ora assurez-vous que INSTANCE_NAME y est spécifié.
Quel est le « NŒUD MAÎTRE » dans RAC ?
Le nœud avec le numéro de nœud le plus bas deviendra le nœud maître et une remasterisation dynamique des ressources aura lieu.
Pour connaître le nœud maître d'une ressource particulière, vous pouvez interroger v$ges_resource pour la colonne MASTER_NODE.
Pour savoir quel est le nœud maître, vous pouvez consulter le fichier ocssd.log et rechercher le « numéro de nœud maître ».
lorsque le premier nœud maître échoue dans le cluster, le numéro de nœud le plus bas deviendra le nœud maître.
Quels composants de RAC doivent résider dans un stockage partagé ?
Tous les fichiers de données, fichiers de contrôle, SPFIles et fichiers de journalisation doivent résider sur un stockage de destruction prenant en charge le cluster.
Donnez quelques exemples de solutions prenant en charge le stockage en cluster ?
·ASM (gestion automatique du stockage),
·Périphériques de disque brut,
·Système de fichiers réseau (NFS),
·OCFS2 et
·OCFS (systèmes Oracle Cluster Fie).
Que sont les composants du cluster Oracle ?
1. Interconnexion de cluster (HAIP)
2. Stockage partagé (OCR/Disque de vote)
3. Logiciel Clusterware
4. Composants du noyau Oracle
Que sont les composants Oracle RAC ?
VIP, applications Node, etc.
Que sont les composants du noyau Oracle ?
Fondamentalement, le noyau Oracle doit être activé avec l'option RAC On lorsque vous convertissez en RAC, c'est la différence car cela facilite quelques processus bg RAC comme LMON, LCK, LMD, LMS etc.
Comment activer RAC ?
# lier les bibliothèques Oracle
$ cd $ORACLE_HOME/rdbms/lib
$ make -f ins_rdbms.mk rac_on
# reconstruire Oracle
$ cd $ORACLE_HOME/bin
$ relier Oracle
Architecture de disque dans RAC ?
SAN (Storage Area Networks) - utilisant généralement la fibre pour se connecter au SAN
NAS (Network Attached Storage) - utilisant généralement un réseau pour se connecter au NAS en utilisant soit NFS, ISCSI
Qu’est-ce qu’Oracle Clusterware ?
Le logiciel Clusterware permet aux nœuds de communiquer entre eux et forme le cluster qui fait fonctionner les nœuds comme un seul serveur logique.
Le logiciel est exécuté par Cluster Ready Services (CRS) à l'aide d'Oracle Cluster Registry (OCR) qui enregistre et conserve les informations d'appartenance au cluster et aux nœuds ainsi que le disque de vote qui agit comme une condition de départage lors des échecs de communication. Des informations de pulsation cohérentes transitent via l'interconnexion jusqu'au disque votant lorsque le cluster est en cours d'exécution.
Clusters d'applications réels
Oracle RAC est une base de données en cluster avec une architecture de cache partagé qui surmonte les limites des approches traditionnelles sans partage et disque partagé pour fournir une solution de base de données hautement évolutive et disponible pour toutes vos applications métier. Oracle RAC constitue la base du calcul en grille d'entreprise.
L'option Real Application Clusters (RAC) d'Oracle prend en charge le déploiement transparent d'une base de données unique sur un cluster de serveurs, offrant ainsi une tolérance aux pannes en cas de pannes matérielles ou de pannes planifiées. Oracle RAC exécuté sur des clusters offre le plus haut niveau de capacité d'Oracle en termes de disponibilité, d'évolutivité et de calcul à faible coût.
Une base de données ouverte par plusieurs instances afin que la base de données soit hautement disponible en cas de panne d'une instance.
Logiciel de cluster. Oracles Clusterware ou des produits comme Veritas Volume Manager sont nécessaires pour fournir la prise en charge du cluster et permettre à chaque nœud de savoir quels nœuds appartiennent au cluster et sont disponibles et avec Oracle Cluterware de savoir quels nœuds ont échoué et de les éjecter du cluster, de sorte que les erreurs sur ce nœud peuvent être effacées.
Oracle Clusterware comporte deux composants clés Cluster Registry OCR et Voting Disk.
Le registre du cluster contient toutes les informations sur les nœuds, les instances, les services et le stockage ASM s'il est utilisé, il contient également des informations sur l'état, c'est-à-dire qu'ils sont disponibles et à jour ou similaires.
Le disque de vote est utilisé pour déterminer si un nœud a échoué, c'est-à-dire s'il s'est séparé de la majorité. Si un nœud est considéré comme n'appartenant plus à la majorité, il est redémarré de force et, après le redémarrage, s'ajoutera à nouveau aux nœuds de cluster survivants.
Quels sont les composants clés d'Oracle Clusterware ?
Oracle Clusterware comporte deux composants clés Cluster Registry OCR et Voting Disk.
Qu'est-ce que le disque de vote et l'OCR ? Disque de vote : Oracle RAC utilise le disque de vote pour gérer l'appartenance au cluster au moyen d'une vérification de l'état et arbitre la propriété du cluster entre les instances en cas de panne de réseau. Le disque de vote doit résider sur un disque partagé. Un nœud doit pouvoir accéder à plus de la moitié des disques votants à tout moment.
Par exemple, si 3 disques votants sont configurés, un nœud doit pouvoir accéder à au moins deux des disques votants à tout moment. Si un nœud ne peut pas accéder au nombre minimum requis de disques votants, il est expulsé ou supprimé du cluster.
Registre de cluster Oracle (OCR)
Le registre de cluster contient toutes les informations sur les nœuds, les instances, les services et le stockage ASM s'il est utilisé, il contient également des informations sur l'état, c'est-à-dire qu'ils sont disponibles et à jour ou similaires.
L'OCR doit résider sur un disque partagé accessible par tous les nœuds de votre cluster.
Quelles sont les tâches administratives liées au disque de vote ?
Les tâches administratives suivantes sont effectuées avec le disque de vote :
1) Sauvegarde des disques de vote
2) Récupération des disques de vote
3) Ajout de disques de vote
4) Suppression des disques de vote
5) Déplacement des disques de vote
Pouvez-vous ajouter un disque de vote en ligne ? Avez-vous besoin d'une sauvegarde du disque de vote ?
Oui, selon la documentation, si vous avez plusieurs disques de vote, vous pouvez les ajouter en ligne, mais si vous n'avez qu'un seul disque de vote, ce cluster sera en panne car il sera perdu, il vous suffit de démarrer crs en mode exclusif et d'ajouter le disque de vote en utilisant
crsctl. add votedisk <path>
Quelle est la recommandation Oracle pour la sauvegarde du disque de vote ?
Oracle nous recommande d'utiliser la commande dd pour sauvegarder le disque de vote avec une taille de bloc minimale de 4 Ko.
Comment sauvegarder les disques de vote ?
1) Oracle vous recommande de sauvegarder votre disque de vote après la création initiale du cluster et après avoir terminé toute procédure d'ajout ou de suppression de nœud.
2) Tout d'abord, en tant qu'utilisateur root, arrêtez Oracle Clusterware (avec la commande crsctl stop crs) sur tous les nœuds. Ensuite, déterminez le disque de vote actuel en exécutant la commande suivante :
crsctl query votedisk css
3) Ensuite, exécutez la commande dd ou ocopy pour sauvegarder un disque de vote, selon le cas.
Donnez la syntaxe de sauvegarde des disques de vote : -
Sur les systèmes Linux ou UNIX :
dd if=voting_disk_name of=backup_file_name
où,
vote_disk_name est le nom du disque de vote actif
backup_file_name est le nom du fichier dans lequel nous voulons sauvegarder le vote contenu du disque
Sur les systèmes Windows, utilisez la commande ocopy :
copy vote_disk_name backup_file_name
Comment vérifier une sauvegarde actuelle existante d'OCR ?
Nous pouvons vérifier la sauvegarde actuelle de l'OCR à l'aide de la commande suivante : ocrconfig -showbackup
Vous avez perdu le disque OCR, quelle est votre prochaine étape ?
La pile de cluster sera en panne car cssd est incapable de maintenir l'intégrité, cela est vrai dans 10g. À partir de 11gR2, la pile crsd sera en panne, le hasd toujours opérationnel. Vous pouvez rajouter l'ocr en restaurant la sauvegarde automatique ou importer la sauvegarde manuelle,
Quels sont les principaux événements d’attente RAC ?
Dans un environnement RAC, le cache tampon est global sur toutes les instances du cluster et le traitement diffère donc. Les événements d'attente les plus courants liés à cela sont la requête gc cr et la
requête gc buffer occupé GC CR : le temps nécessaire pour récupérer les données de le cache distant
Raison : trafic RAC utilisant une connexion lente ou des requêtes inefficaces (les requêtes mal réglées augmenteront la quantité de blocs de données demandés par une session Oracle. Plus il y a de blocs demandés, plus un bloc devra être lu à partir d'une instance distante. via l'interconnexion.)
GC BUFFER BUSY : C'est le temps que l'instance distante passe localement à accéder au bloc de données demandé.
Que faites-vous si vous voyez GC CR BLOCK LOST dans les 5 principaux événements chronométrés du rapport AWR ?
Cela est probablement dû à un défaut du réseau d'interconnexion.
Vérifiez netstat -s
si vous voyez « fragments supprimés » ou « échec du réassemblage de paquets ». Travaillez avec votre administrateur système pour trouver le problème du réseau.
Comment dépanner le redémarrage du nœud ?
Veuillez vérifier metalink...
Note 265769.1 Dépannage des redémarrages de CRS
Note.559365.1 Utilisation de Diagwait comme diagnostic pour obtenir plus d'informations sur le diagnostic des expulsions de nœuds Oracle Clusterware.
Srvctl ne peut pas démarrer l'instance, j'obtiens l'erreur suivante PRKP-1001 CRS-0215, mais sqlplus peut-il la démarrer sur les deux nœuds ? Comment identifier le problème ?
Définissez la variable d'environnement SRVM_TRACE sur true. Et démarrez l'instance avec srvctl. Vous obtiendrez maintenant une pile d’erreurs détaillée.
Que sont les processus Oracle Clusterware pour 10g sous Unix et Linux ?
Services de synchronisation de cluster (ocssd) : gère l'adhésion aux nœuds de cluster et s'exécute en tant qu'utilisateur Oracle ; l'échec de ce processus entraîne le redémarrage du cluster.
Cluster Ready Services (crsd) — Le processus crs gère les ressources du cluster (qui peuvent être une base de données, une instance, un service, un écouteur, une adresse IP virtuelle (VIP), un processus d'application, etc.) en fonction de la configuration de la ressource. informations stockées dans l'OCR. Cela inclut les opérations de démarrage, d’arrêt, de surveillance et de basculement. Ce processus s'exécute en tant qu'utilisateur racine
Démon du gestionnaire d'événements (evmd) : un processus en arrière-plan qui publie les événements créés par crs.
Process Monitor Daemon (OPROCD) : ce processus surveille le cluster et fournit une séparation des E/S. OPROCD effectue sa vérification, arrête de fonctionner et si le réveil dépasse l'heure prévue, alors OPROCD réinitialise le processeur et redémarre le nœud. Un échec OPROCD entraîne le redémarrage du nœud par Oracle Clusterware. OPROCD utilise le minuteur hangcheck sur les plates-formes Linux.
RACG (racgmain, racgimon) : étend le clusterware pour prendre en charge les exigences spécifiques à Oracle et les ressources complexes. Exécute des scripts d'appel du serveur lorsque des événements FAN se produisent.
Quels sont les processus en arrière-plan de la base de données Oracle spécifiques à RAC ?
Oracle RAC est composé de deux ou plusieurs instances de base de données. Elles sont composées de structures de mémoire et de processus d'arrière-plan identiques à ceux de la base de données à instance unique. Les instances Oracle RAC utilisent deux processus GES (Global Enqueue Service) et GCS (Global Cache Service) qui permettent la fusion du cache. Les instances Oracle RAC sont composées des processus d'arrière-plan suivants :
ACMS—Atomic Controlfile to Memory Service (ACMS)
GTX0-j—Processus de transaction global
LMON—Moniteur du service de mise en file d'attente global
LMD—Démon du service de mise en file d'attente global
LMS—Processus du service de cache global
LCK0—Processus de mise en file d'attente d'instance
RMSn—Processus de gestion Oracle RAC (RMSn)
RSMN —Remote Slave Monitor
Pour garantir que chaque instance de base de données Oracle RAC obtient le bloc dont elle a besoin pour satisfaire une requête ou une transaction, les instances Oracle RAC utilisent deux processus, le service de cache global (GCS) et le service de mise en file d'attente globale (GES). Le GCS et le GES conservent des enregistrements des statuts de chaque fichier de données et de chaque bloc mis en cache à l'aide d'un répertoire de ressources global (GRD). Le contenu GRD est distribué sur toutes les instances actives.
Qu’est-ce que le GRD ?
GRD signifie Répertoire mondial des ressources. Le GES et le GCS conservent des enregistrements des statuts de chaque fichier de données et de chaque bloc mis en cache à l'aide du répertoire de ressources global. Ce processus est appelé fusion de cache et contribue à l'intégrité des données.
Qu’est-ce qu’ACMS ?
ACMS signifie Atomic Controlfile Memory Service. Dans un environnement Oracle RAC, ACMS est un agent qui garantit qu'une mise à jour de mémoire SGA distribuée (c'est-à-dire) que les mises à jour SGA sont globalement validées en cas de succès ou globalement abandonnées en cas d'échec.
Qu'est-ce que l'écouteur SCAN ?
Un écouteur d'analyse est quelque chose qui s'ajoute à l'écouteur de nœud qui écoute les demandes de connexion à la base de données entrantes du client qui ont transité par l'adresse IP d'analyse, il a configuré les points de terminaison sur l'écouteur de nœud où il achemine les demandes de connexion à la base de données vers un écouteur de nœud particulier.
SCAN IP peut être désactivé s’il n’est pas nécessaire. Cependant SCAN IP est obligatoire lors de l'installation du RAC. L'activation/la désactivation de SCAN IP est principalement utilisée dans l'environnement des applications Oracle par le gestionnaire simultané (sorte de planificateur de tâches dans les applications Oracle).
Étapes pour désactiver le SCAN IP,
i. N'utilisez pas SCAN IP côté client.
ii. Arrêter l'écouteur d'analyse
srvctl stop scan_listener
iii. Arrêter l'analyse
srvctl stop scan (cela arrêtera l'analyse vip)
iv. Désactiver l'analyse et désactiver l'écouteur d'analyse
srvctl désactiver l'analyse
Quels sont les différents composants réseau du 10g RAC ?
Composants publics, privés et VIP
Les interfaces privées sont destinées à la communication intra-nœud.
VIP est avant tout une question de disponibilité de l'application. Lorsqu'un nœud tombe en panne, le composant VIP bascule vers un autre nœud. C'est la raison pour laquelle toutes les applications doivent être basées sur des composants VIP, ce qui signifie que les entrées TNS doivent avoir une entrée VIP dans la liste d'hôtes.
Qu'est-ce qu'un réseau d'interconnexion ?
Un réseau d'interconnexion est un réseau privé qui connecte tous les serveurs d'un cluster. Le réseau d'interconnexion utilise un/plusieurs commutateurs auxquels seuls les nœuds du cluster peuvent accéder.
À quoi sert l’interconnexion de cluster ?
L'interconnexion de cluster est utilisée par la fusion de cache pour la communication inter-instances.
Comment pouvons-nous configurer l’interconnexion du cluster ?
· Configurez le protocole UDP (User Datagram Protocol) sur Gigabit Ethernet pour les interconnexions de cluster.
· Sur les systèmes UNIX et Linux, nous utilisons les protocoles UDP et RDS (Reliable data socket) destinés à être utilisés par Oracle Clusterware.
· Les clusters Windows utilisent le protocole TCP.
Quel est le but de l’interconnexion privée ?
Clusterware utilise l'interconnexion privée pour la synchronisation du cluster (battement de réseau) et la communication démon entre les nœuds du cluster. Cette communication est basée sur le protocole TCP.
RAC utilise l'interconnexion pour la fusion de cache (UDP) et la communication inter-processus (TCP). Cache Fusion est le mappage de mémoire distante des tampons Oracle, partagés entre les caches des nœuds participants du cluster.
Qu'est-ce qu'une adresse IP virtuelle ou VIP ?
Une adresse IP virtuelle ou VIP est une adresse IP alternative que les connexions client utilisent à la place de l'adresse IP publique standard. Pour configurer l'adresse VIP, nous devons réserver une adresse IP de rechange pour chaque nœud, et les adresses IP doivent utiliser le même sous-réseau que le réseau public.
A quoi sert le VIP ?
Si un nœud échoue, l'adresse VIP du nœud bascule vers un autre nœud sur lequel l'adresse VIP peut accepter les connexions TCP mais ne peut pas accepter les connexions Oracle.
Pourquoi avons-nous une adresse IP virtuelle (VIP) dans Oracle RAC ?
Sans utiliser de VIP ou de FAN, les clients connectés à un nœud décédé attendront souvent un délai d'attente TCP (qui peut aller jusqu'à 10 minutes) avant de recevoir une erreur. Par conséquent, vous n’avez pas vraiment de bonne solution HA sans utiliser de VIP.
Lorsqu'un nœud tombe en panne, le VIP qui lui est associé est automatiquement basculé vers un autre nœud et le nouveau nœud réorganise le monde en indiquant une nouvelle adresse MAC pour l'IP. Les paquets suivants envoyés au VIP vont au nouveau nœud, qui renverra les paquets RST d'erreur aux clients. Cela entraîne des erreurs immédiates pour les clients.
Donnez les situations dans lesquelles le basculement d'adresse VIP se produit ?
Le basculement des adresses VIP se produit lorsque le nœud sur lequel l'adresse VIP s'exécute tombe en panne ; toutes les interfaces pour l'adresse VIP échouent, toutes les interfaces pour l'adresse VIP sont déconnectées du réseau.
Quelle est l’importance du basculement d’adresse VIP ?
Lorsqu'un basculement d'adresse VIP se produit, les clients qui tentent de se connecter à l'adresse VIP reçoivent une erreur de refus de connexion rapide. Ils n'ont pas à attendre les messages d'expiration de connexion TCP.
A quoi sert un service dans l’environnement Oracle RAC ?
Les applications doivent utiliser la fonctionnalité de services pour se connecter à la base de données Oracle. Les services nous permettent de définir des règles et des caractéristiques pour contrôler la manière dont les utilisateurs et les applications se connectent aux instances de base de données.
Quelles sont les caractéristiques contrôlées par la fonctionnalité des services Oracle ?
Les caractéristiques incluent un nom unique, un équilibrage de la charge de travail, des options de basculement et une haute disponibilité.
Qu'est-ce qui permet l'équilibrage de charge des applications dans RAC ?
Oracle Net Services permet l'équilibrage de charge des connexions d'application sur toutes les instances d'une base de données Oracle RAC.
Quels sont les types d’équilibrage de charge de connexion ?
La gestion de la charge de travail des connexions est l'un des aspects clés lorsque vous disposez d'instances RAC, car vous souhaitez distribuer les connexions à des nœuds/instances spécifiques ou à ceux qui ont moins de charge.
Il existe deux types d'équilibrage de charge de connexion :
1. Équilibrage de charge côté client (également appelé équilibrage de charge au moment de la connexion)
2. Équilibrage de charge côté serveur (également appelé équilibrage de charge de connexion d'écoute)
Quelle est la différence entre le côté serveur et le côté client -équilibrage de charge de connexion côté ?
L'équilibrage côté client se produit côté client, où l'équilibrage de charge est effectué à l'aide de l'écouteur. En cas d'équilibrage de charge côté serveur, l'écouteur utilise un avis d'équilibrage de charge pour rediriger les connexions vers l'instance fournissant le meilleur service.
Équilibrage de charge côté client : - La fonctionnalité d'équilibrage de charge côté client Oracle permet aux clients de randomiser les demandes de connexion parmi tous les écouteurs disponibles en fonction de leur charge.
Une entrée tns qui contient toutes les entrées de nœuds et utilise load_balance=on (activé par défaut) utilisera l'équilibrage de charge au moment de la connexion ou l'équilibrage de charge côté client.
Exemple d'entrée TNS côté client : -
finance =
(DESCRIPTION =
(ADRESSE = (PROTOCOLE = TCP)(HOST = myrac2-vip)(PORT = 2042))
(ADRESSE = (PROTOCOLE = TCP)(HOST = myrac1-vip)(PORT = 2042))
(ADDRESS = (PROTOCOL = TCP)(HOST = myrac3-vip)(PORT = 2042))
(LOAD_BALANCE = oui)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = FINANCE) (FAILOVER=ON)
(FAILOVER_MODE = (TYPE = SELECT) (METHOD = BASIC) (RETRIES = 180) (DELAY = 5))
)
)
Équilibrage de charge côté serveur : - Cela améliore les performances de connexion en équilibrant le nombre de connexions actives entre plusieurs instances et répartiteurs. Dans un environnement à instance unique (serveurs partagés), l'écouteur sélectionne le moindre répartiteur pour gérer les demandes client entrantes. Dans un environnement rac, PMON connaît la charge de toutes les instances et les répartiteurs, et en fonction des informations de charge, PMON redirige la connexion vers le nœud le moins chargé.
Dans un environnement RAC, le paramètre *.remote_listener qui est une entrée tns contenant toutes les adresses de nœuds doit être défini pour activer les mises à jour des conseils d'équilibrage de charge sur PMON.
L'exemple d'entrée Tns doit se trouver dans une instance du cluster RAC,
local_listener=LISTENER_MYRAC1
remote_listener = LISTENERS_MYRACDB
Quels sont les outils d'administration utilisés pour les environnements Oracle RAC ?
Le cluster Oracle RAC peut être administré comme une image unique à l'aide des éléments ci-dessous
· OEM (Enterprise Manager),
· SQL*PLUS,
· Contrôle du serveur (SRVCTL),
· Utilitaire de vérification de cluster (CLUVFY),
· DBCA,
· NETCA
Nommez certains outils Oracle Clusterware et leurs utilisations ?
· OIFCFG - allocation et désallocation des interfaces réseau.
·OCRCONFIG - Outil de ligne de commande pour gérer Oracle Cluster Registry.
·OCRDUMP - Identifiez l'interconnexion utilisée.
·CVU - Utilitaire de vérification de cluster pour obtenir l'état des ressources CRS.
Quelle est la différence entre CRSCTL et SRVCTL ?
crsctl gère les opérations liées au clusterware :
Démarrage et arrêt d'Oracle Clusterware
Activation et désactivation des démons Oracle Clusterware
Enregistrement des ressources du cluster
srvctl gère les opérations liées aux ressources Oracle :
Démarrage et arrêt des instances et des services de base de données
Également à partir de 11gR2, gère les ressources du cluster comme le réseau, vip, disques, etc.
Comment supprimer ASM d'un environnement Oracle RAC ?
Nous devons d'abord arrêter et supprimer l'instance dans le nœud en mode interactif ou silencieux. Après cela, asm peut être supprimé à l'aide de l'outil srvctl comme suit :
srvctl stop asm -n node_name
srvctl Remove asm -n node_name
Nous pouvons vérifier si ASM a été supprimé. en émettant la commande suivante :
srvctl config asm -n node_name
Comment vérifier qu'une instance a été supprimée de l'OCR après la suppression d'une instance ?
Exécutez la commande srvctl suivante :
srvctl config database -d nom_base de données
cd CRS_HOME/bin
./crs_stat
Quels sont les modes de suppression d'instances des bases de données du cluster ORacle Real Application ?
Nous pouvons supprimer des instances en mode silencieux ou en mode interactif à l'aide de DBCA (Database Configuration Assistant).
Quels sont les processus d'arrière-plan qui existent dans 11gr2 et leurs fonctionnalités ?
Nom du processus Fonctionnalité
crsd •Le démon CRS (crsd) gère les ressources du cluster en fonction des informations de configuration stockées dans Oracle Cluster Registry (OCR) pour chaque ressource. Cela inclut les opérations de démarrage, d’arrêt, de surveillance et de basculement. Le processus crsd génère des événements lorsque l'état d'une ressource change.
cssd • Service de synchronisation de cluster (CSS) : gère la configuration du cluster en contrôlant quels nœuds sont membres du cluster et en avertissant les membres lorsqu'un nœud rejoint ou quitte le cluster. Si vous utilisez un clusterware tiers certifié, CSS traite les interfaces avec votre clusterware pour gérer les informations d'appartenance aux nœuds. CSS comporte trois processus distincts : le démon CSS (ocssd), l'agent CSS (cssdagent) et le moniteur CSS (cssdmonitor). Le processus cssdagent surveille le cluster et fournit une séparation des entrées/sorties. Ce service était auparavant fourni par le démon Oracle Process Monitor (oprocd), également connu sous le nom d'OraFenceService sous Windows. Un échec de cssdagent entraîne le redémarrage d'Oracle Clusterware du nœud.
diskmon •Démon Disk Monitor (diskmon) : surveille et effectue le filtrage des entrées/sorties pour Oracle Exadata Storage Server. Comme le stockage Exadata peut être ajouté à n'importe quel nœud Oracle RAC à tout moment, le démon diskmon est toujours démarré au démarrage d'ocssd.
evmd •Event Manager (EVM) : processus en arrière-plan qui publie les événements Oracle Clusterware.
mdnsd •Service de noms de domaine multidiffusion (mDNS) : autorise les requêtes DNS. Le processus mDNS est un processus en arrière-plan sous Linux et UNIX, et un service sous Windows.
gnsd •Oracle Grid Naming Service (GNS) : est une passerelle entre le cluster mDNS et les serveurs DNS externes. Le processus GNS effectue la résolution de noms au sein du cluster.
ons •Oracle Notification Service (ONS) : service de publication et d'abonnement permettant de communiquer les événements Fast Application Notification (FAN).
oraagent •oraagent : étend le clusterware pour prendre en charge les exigences spécifiques à Oracle et les ressources complexes. Il exécute des scripts d'appel du serveur lorsque des événements FAN se produisent. Ce processus était connu sous le nom de RACG dans Oracle Clusterware 11g Release 1 (11.1).
orarootagent •Agent racine Oracle (orarootagent) : est un processus oraagent spécialisé qui aide CRSD à gérer les ressources appartenant à root, telles que le réseau, et l'adresse IP virtuelle de la grille.
oclskd •Démon de suppression de cluster (oclskd) : gère les demandes d'expulsion d'instance/de nœud qui ont été transmis au CSS
gipcd • Démon Grid IPC (gipcd) : est un démon d'assistance pour l'infrastructure de communication.
ctssd • Démon de synchronisation temporelle du cluster (ctssd) pour gérer la synchronisation temporelle entre les nœuds, plutôt en fonction de NTP.
Sous quel utilisateur ou propriétaire le processus démarrera-t-il ?
Nom du composant du propriétaire du processus
Oracle High Availability Service ohasd init, racine
Cluster Ready Service (CRS) Cluster Ready Services racine
Cluster Synchronization Service (CSS) ocssd, cssd monitor, cssdagent propriétaire de la grille
Event Manager (EVM) evmd, evmlogger propriétaire de la grille Heure
du cluster Service de synchronisation (CTSS) racine octssd
Oracle Notification Service (ONS) ons, eons propriétaire de la grille
Agent Oracle oragent propriétaire de la grille
Oracle Root Agent orarootagent racine
Grid Naming Service (GNS) racine gnsd
Grid Plug and Play (GPnP) gpnpd propriétaire de la grille
Service de nom de domaine multidiffusion (mDNS) Propriétaire de la grille mdnsd
Quelle est la principale différence entre 10g et 11g RAC ?
Il n'y a pas beaucoup de différence entre 10g et 11gR (1) RAC. Mais il existe une différence significative en 11gR2.
Avant 11gR1 (10g) RAC, les éléments suivants étaient gérés par Oracle CRS
Bases de données
Instances
Applications
Surveillance des nœuds
Services d'événements
Haute disponibilité
À partir de 11gR2 (et versions ultérieures), sa pile HA complète gère et fournit les ressources suivantes comme les autres logiciels de cluster comme VCS,
etc.
Instances
Applications
Gestion de cluster
Gestion de nœuds
Services d'événements Gestion de réseau
haute disponibilité
(fournit des services DNS/GNS/MDNSD au nom d'autres services traditionnels) et SCAN – Méthode de dénomination client à accès unique,
gestion du stockage HAIP (avec l'aide d'ASM et d'autres nouveaux systèmes de fichiers ACFS)
Synchronisation de l'heure (plutôt dépendante du NTP traditionnel)
Suppression du vérificateur de blocage dépendant du système d'exploitation, etc., géré avec son propre processus de surveillance supplémentaire.
Qu'est-ce que le temporisateur de contrôle de blocage ?
Le temporisateur Hangcheck vérifie régulièrement la santé du système. Si le système se bloque ou s'arrête, le nœud sera automatiquement redémarré.
Il y a 2 paramètres clés pour ce module :
-> hangcheck-tick : ce paramètre définit la période de temps entre les vérifications de la santé du système. La valeur par défaut est de 60 secondes ; Oracle recommande de le définir sur 30 secondes.
-> hangcheck-margin : ceci définit le délai de blocage maximum qui doit être toléré avant que hangcheck-timer ne réinitialise le nœud RAC.
Indiquer les paramètres d'initialisation qui doivent avoir la même valeur pour chaque instance dans une base de données Oracle RAC ?
Certains paramètres d'initialisation sont critiques au moment de la création de la base de données et doivent avoir les mêmes valeurs. Leur valeur doit être spécifiée dans SPFILE ou PFILE pour chaque instance. La liste des paramètres qui doivent être identiques sur chaque instance est donnée ci-dessous :
ACTIVE_INSTANCE_COUNT
ARCHIVE_LAG_TARGET
COMPATIBLE
CLUSTER_DATABASE
CLUSTER_DATABASE_INSTANCE
CONTROL_FILES
DB_BLOCK_SIZE
DB_DOMAIN
DB_FILES
DB_NAME
DB_RECOVERY_FILE_DEST
DB_RECOVERY_FILE_DEST_SIZE
DB_UNIQUE_NAME
INSTANCE_TYPE (SGBDR ou ASM)
PARALLEL_MAX_SERVERS
REMOTE_LOGIN_passWORD_FILE
UNDO_MANAGEMENT
Qu'est-ce que RAC ? Quel est l'avantage de RAC par rapport à une base de données à instance unique ?
Dans les environnements Real Application Clusters, tous les nœuds exécutent simultanément des transactions sur la même base de données. Real Application Clusters coordonne l'accès de chaque nœud aux données partagées pour assurer la cohérence et l'intégrité.
Avantages :
Améliorer le temps de réponse
Améliorer le débit
Haute disponibilité
Transparence
Avantages du RAC (Real Application Clusters)
Fiabilité - si un nœud tombe en panne, la base de données ne tombera pas en panne
Disponibilité - des nœuds peuvent être ajoutés ou remplacés sans avoir à arrêter la base de données
Évolutivité - davantage de nœuds peuvent être ajouté au cluster à mesure que la charge de travail augmente.
Qu'est-ce qu'une adresse IP virtuelle ou VIP ?
Une adresse IP virtuelle ou VIP est une adresse IP alternative que les connexions client utilisent à la place de l'adresse IP publique standard. Pour configurer l'adresse VIP, nous devons réserver une adresse IP de rechange pour chaque nœud, et les adresses IP doivent utiliser le même sous-réseau que le réseau public.
A quoi sert le VIP ?
Si un nœud échoue, l'adresse VIP du nœud bascule vers un autre nœud sur lequel l'adresse VIP peut accepter les connexions TCP mais ne peut pas accepter les connexions Oracle.
Donnez les situations dans lesquelles le basculement de l'adresse VIP se produit : -
Le basculement des adresses VIP se produit lorsque le nœud sur lequel l'adresse VIP s'exécute échoue, que toutes les interfaces pour l'adresse VIP échouent, que toutes les interfaces pour l'adresse VIP sont déconnectées du réseau.
En utilisant l'IP virtuelle, nous pouvons éviter notre problème de délai d'attente TCP/IP car le service de notification Oracle maintient la communication entre chaque nœud et écouteur.
Quelle est l’importance du basculement d’adresse VIP ?
Lorsqu'un basculement d'adresse VIP se produit, les clients qui tentent de se connecter à l'adresse VIP reçoivent une erreur de refus de connexion rapide. Ils n'ont pas à attendre les messages d'expiration de connexion TCP.
Qu'est-ce qu'un disque de vote ?
Voting Disk est un fichier qui se trouve dans la zone de stockage partagé et doit être accessible par tous les nœuds du cluster. Tous les nœuds du cluster enregistrent leurs informations de battement de cœur sur le disque de vote, afin de confirmer qu'ils sont tous opérationnels. Si les informations de battement de cœur d'un nœud du disque votant ne sont pas disponibles, ce nœud sera expulsé du cluster. Le démon CSS (Cluster Synchronization Service) du clusterware maintient le rythme cardiaque de tous les nœuds sur le disque votant. Lorsqu'un nœud n'est pas en mesure d'envoyer un battement de cœur au disque de vote, il se redémarre lui-même, aidant ainsi à éviter le syndrome du cerveau divisé.
Pour une haute disponibilité, Oracle vous recommande de disposer d'un minimum de trois disques de vote ou d'un nombre impair (3 ou plus).
Voting Disk - est un fichier qui réside sur le stockage partagé et gère les membres du cluster. Le disque de vote réaffecte la propriété du cluster entre les nœuds en cas de panne.
Les fichiers de disque de vote sont utilisés par Oracle Clusterware pour déterminer quels nœuds sont actuellement membres du cluster. Les fichiers de disque de vote sont également utilisés de concert avec d'autres composants du cluster tels que CRS pour maintenir l'intégrité des clusters.
Oracle Database 11g Release 2 offre la possibilité de stocker les disques de vote dans ASM avec l'OCR. Oracle Clusterware peut accéder à l'OCR et aux disques de vote présents dans ASM même si l'instance ASM est en panne. Par conséquent, CSS peut continuer à maintenir le cluster Oracle même si l'instance ASM échoue.
Combien de disques de vote conservez-vous ?
http://www.toadworld.com/KNOWLEDGE/KnowledgeXpertforOracle/tabid/648/TopicID/RACR2ARC6/Default.aspx
Par défaut, Oracle créera 3 fichiers de disque de vote dans ASM.
Oracle s'attend à ce que vous configuriez au moins 3 disques votants à des fins de redondance. Vous devez toujours configurer un nombre impair de disques votants >= 3. En effet, la perte de plus de la moitié de vos disques votants entraînera l'échec de l'ensemble du cluster.
Vous devez prévoir d'allouer 280 Mo pour chaque fichier de disque votant. Par exemple, si vous utilisez ASM et la redondance externe, vous devrez allouer 280 Mo de disque pour le disque votant. Si vous utilisez ASM et une redondance normale, vous aurez besoin de 560 Mo.
Pourquoi devons-nous conserver un nombre impair de disques votants ?
Oracle s'attend à ce que vous configuriez au moins 3 disques votants à des fins de redondance. Vous devez toujours configurer un nombre impair de disques votants >= 3. En effet, la perte de plus de la moitié de vos disques votants entraînera l'échec de l'ensemble du cluster.
Que sont les composants logiciels Oracle RAC ?
Oracle RAC est composé de deux ou plusieurs instances de base de données. Elles sont composées de structures de mémoire et de processus d'arrière-plan identiques à ceux de la base de données à instance unique. Les instances Oracle RAC utilisent deux processus GES (Global Enqueue Service) et GCS (Global Cache Service) qui permettent la fusion du cache. Les instances Oracle RAC sont composées des processus d'arrière-plan suivants :
ACMS—Atomic Controlfile to Memory Service (ACMS)
GTX0-j—Processus de transaction global
LMON—Moniteur du service de mise en file d'attente global
LMD—Démon du service de mise en file d'attente global
LMS—Processus du service de cache global
LCK0—Processus de mise en file d'attente d'instance
RMSn—Processus de gestion Oracle RAC (RMSn)
RSMN —Moniteur esclave à distance
Qu'est-ce que TAF ?
TAF (Transparent Application Failover) est une configuration qui permet le basculement de session entre différents nœuds d'un cluster de bases de données RAC.
Basculement d'application transparent (TAF). Si une défaillance de la liaison de communication se produit après l'établissement d'une connexion, la connexion bascule vers un autre nœud actif. Toutes les transactions interrompues sont annulées et les propriétés de session et les variables du programme côté serveur sont perdues. Dans certains cas, si l'instruction exécutée au moment du basculement est une instruction Select, cette instruction peut être automatiquement réexécutée sur la nouvelle connexion avec le curseur positionné sur la ligne sur laquelle il était positionné avant le basculement.
Après une panne d'un nœud Oracle RAC (généralement à cause d'une panne matérielle), toutes les nouvelles transactions d'application sont automatiquement redirigées vers un nœud de sauvegarde spécifié. Le défi du reroutage est de ne pas perdre les transactions qui étaient « en vol » au moment précis du crash. L'une des exigences de la disponibilité continue est la possibilité de redémarrer les transactions d'application en cours, permettant à un nœud défaillant de reprendre le traitement sur un autre serveur sans interruption. La réponse d'Oracle au basculement d'application est un nouveau mécanisme Oracle Net appelé Transparent Application Failover. TAF permet au DBA de configurer le type et la méthode de basculement pour chaque client Oracle Net.
L'architecture TAF offre la possibilité de redémarrer les transactions au niveau de la transaction (SELECT) ou de la session.
Quelle est la configuration requise pour Oracle Clusterware ?
1. Disque partagé externe pour stocker le fichier de logiciel Oracle Cluster (Disque de vote et registre de cluster Oracle - OCR)
2. Deux cartes réseau sur chaque nœud de logiciel de cluster (et trois jeux d'adresses IP) -
Carte réseau 1 (avec jeu d'adresses IP 1) pour réseau public
Carte réseau 2 (avec jeu d'adresses IP 2) pour réseau privé (pour la communication inter-nœuds entre les nœuds rac utilisés par le clusterware et la base de données rac)
Jeu d'adresses IP 3 pour IP virtuelle (VIP) (utilisé comme adresse IP virtuelle pour la connexion client et pour le basculement de la connexion)
3. Option de stockage pour OCR et disque de vote - RAW, OCFS2 (Oracle Cluster File System), NFS,…..
Qui permettent l'équilibrage de charge des applications dans RAC ?
Oracle Net Services permet l'équilibrage de charge des connexions d'application sur toutes les instances d'une base de données Oracle RAC.
Comment trouver l’emplacement du fichier OCR lorsque CRS est en panne ?
Si vous avez besoin de trouver l'emplacement de l'OCR (Oracle Cluster Registry) mais que votre CRS est en panne.
Lorsque le CRS est en panne :
Regardez dans le fichier « ocr.loc », l'emplacement de ce fichier change en fonction du système d'exploitation :
Sous Linux : /etc/oracle/ocr.loc
Sous Solaris : /var/opt/oracle/ocr.loc
Quand CRS est UP :
définissez l'environnement ASM ou l'environnement CRS, puis exécutez la commande ci-dessous :
ocrcheck
Dans un RAC à 2 nœuds, combien de cartes réseau utilisez-vous ?
2 cartes réseau sur chaque nœud clusterware
Carte réseau 1 (avec adresse IP définie 1) pour réseau public
Carte réseau 2 (avec adresse IP définie 2) pour réseau privé (pour la communication inter-nœuds entre les nœuds rac utilisés par le clusterware et la base de données rac)
En 2 nœud RAC, combien d'adresses IP r utilise-t-il ?
6 - 3 jeux d'adresses IP
## eth1-Public : 2
## eth0-Private : 2
## VIP : 2
Comment trouver les informations IP dans RAC ?
Modifiez le fichier /etc/hosts comme indiqué ci-dessous :
# Ne supprimez pas la ligne suivante, sinon divers programmes
# nécessitant une fonctionnalité réseau échoueront.
127.0.0.1 localhost.localdomain localhost
## Noms des nœuds publics
192.168.10.11 node1-pub.hingu.net node1-pub
192.168.10.22 node2-pub.hingu.net node2-pub
## Réseau privé (interconnexion)
192.168.0.11 node1- prv node1-prv
192.168.0.22 node2-prv node2-prv
## Réseau privé (stockage de zone réseau)
192.168.1.11 node1-nas node1-nas
192.168.1.22 node2-nas node2-nas
192.168.1.33 nas-server nas-server
# # IP virtuelles
192.168.10.111 node1-vip.hingu.net node1-vip
192.168.10.222 node2-vip.hingu.net node2-vip
Quelle est la différence entre les adresses IP RAC ?
L'adresse IP publique est l'adresse IP normale généralement utilisée par DBA et SA pour gérer le stockage, le système et la base de données. Les adresses IP publiques sont réservées à Internet.
L'adresse IP privée est utilisée uniquement pour le traitement du clustering interne (Cache Fusion) (c'est-à-dire comme interconnexion). Les adresses IP privées sont réservées aux réseaux privés.
VIP est utilisé par les applications de base de données pour activer le basculement en cas de panne d'un nœud de cluster. Le but d'avoir VIP est que la connexion client puisse être basculée vers les nœuds survivants en cas de panne.
Le développeur d'applications peut-il accéder à l'adresse IP privée ?
Non, l'adresse IP privée est utilisée uniquement pour le traitement du clustering interne (Cache Fusion) (alias comme interconnexion)
Abonnez-vous à : Messages (Atom)
- Obtenir le lien
- X
- Autres applications
- Obtenir le lien
- X
- Autres applications
Commentaires
Enregistrer un commentaire