Bases de données logiques de secours - Prise en charge des erreurs DSS-xxxxQue faire lorsque vous recevez un message DSS-00001 : SQL Apply n'est pas en cours d'exécution :
Confirmez que la base logique n'applique pas les modifications et qu'il y a effectivement un problème.
Vérifiez les événements SqlApply pour déterminer la dernière erreur et si SqlApply a été arrêté manuellement ou a échoué en raison d'une erreur.
S'il a été arrêté manuellement, à la suite d'un redémarrage de la base de données ou pour toute autre raison non liée à une erreur, redémarrez SQL Apply et confirmez que l'application est en train de se rattraper.
S'il a échoué en raison d'une erreur, combinez les informations provenant des événements SqlApply et du journal d'alerte de la base de données et prenez les mesures qui s'imposent :
Toutes les erreurs liées au schéma doivent être envoyées au support de l'application, par exemple
erreur ORA-01403 "aucune donnée trouvée
ORA-00955 : le nom est déjà utilisé par un objet existant.
Toutes les erreurs telles que les paramètres de la base de données, les problèmes de mémoire, les erreurs ORA-0600 et les erreurs de fichiers de données doivent être résolues par le DBA.
Ne passez pas de transactions sans être sûr à 100 % qu'il n'y aura pas d'impact. Par exemple, si pour une raison quelconque il y a une DDL pour supprimer un objet qui n'existe pas, bien que cela ne devrait pas se produire, aucun impact ne pourrait être causé par l'omission d'une instruction de suppression pour un objet inexistant.
Que faire lorsque vous recevez une DSS-00002 : DSS-00002 : Logical standby guard status set to None
Il n'y a rien à faire immédiatement. Il s'agit en fait d'un avertissement indiquant que le niveau de protection n'est pas correctement défini. Ce problème peut toujours être résolu pendant les heures de bureau.
Que faire lorsque vous recevez un DSS-00003 : Logical standby apply latency greater than ..... (latence d'application en attente logique supérieure à .....).
Vérifier que le SqlApply est toujours en cours d'exécution.
Vérifiez que le SqlApply est à jour. Il peut parfois se rattraper rapidement. Exécutez cette vérification plusieurs fois pour déterminer si SqlApply progresse, s'il se rattrape ou s'il prend du retard.
Vérifiez ce que font les processus SqlApply. Cela montrera s'ils attendent un journal d'archive, s'ils traitent une transaction ou s'ils paginent les LCR sur le disque.
Si SqlApply attend un journal d'archive, vérifiez que les destinations du journal d'archive n'ont pas de problème d'espace et que les destinations sur le primaire et le standby ne sont pas en erreur.
Si SqlApply a été redémarré et qu'un log toujours nécessaire a été supprimé, il peut arriver que le log ne soit pas envoyé en tant que requête FAL et qu'il doive être copié manuellement.
Si vous constatez qu'un processus d'application spécifique semble bloqué sur une seule transaction, obtenez le SID de ce processus SqlApply et effectuez une investigation dba normale comme vous le feriez pour n'importe quelle session problématique.
Que faire lorsque vous recevez un DSS-00004 : L'envoi du journal d'archives contient .... un ou plusieurs trous entre les séquences ....
Vérifiez que les destinations des journaux d'archives sont correctes et ne comportent pas d'erreur. Vérifiez que les paramètres FAL "SHOW PARAMETER FAL" sont corrects et que les écarts sont résolus automatiquement.
Toutes les requêtes nécessaires pour effectuer ces vérifications se trouvent dans la section ci-dessous.
Réponses et requêtes pour aider à surveiller les bases de données logiques en attente.
La mise en forme de ces requêtes suppose que SqlPlus est utilisé et qu'un écran de 132 caractères est disponible.
Cette base de données est-elle une base de secours logique ?
Exécutez la requête SQL suivante sur la base de données :
SELECT DATABASE_ROLE FROM V$DATABASE ;
Les bases de données en attente logique affichent "LOGICAL STANDBY".
La base de données en attente logique applique-t-elle des modifications ?
Exécutez le code SQL suivant sur la base de données de secours logique :
SET LINESIZE 132
COLONNE REALTIME_APPLY FORMAT A15
COLONNE STATE FORMAT A60
SELECT REALTIME_APPLY, STATE FROM V$LOGSTDBY_STATE ;
Si la valeur de STATE est "NULL" ou "SQL APPLY NOT ON", l'application SQL n'est pas en cours d'exécution.
La valeur de REALTIME_APPLY doit être Y pour permettre l'application en temps réel à partir des redo logs en attente.
L'application SQL est-elle à jour ?
Exécutez le code SQL suivant sur la base de données Logical standby :
SELECT
TO_CHAR(LATEST_TIME,'yyyy/mm/dd hh24:mi:ss') "LATEST_TIME",
TO_CHAR(APPLIED_TIME,'yyyy/mm/dd hh24:mi:ss') "APPLIED_TIME",
APPLIED_SCN, LATEST_SCN
FROM V$LOGSTDBY_PROGRESS ;
Si les valeurs LATEST_TIME et APPLIED_TIME sont proches, l'application SQL fonctionne correctement.
Une valeur NULL dans APPLIED_TIME peut indiquer que l'application SQL n'est pas en cours d'exécution.
Si le LATEST_TIME n'est pas proche du temps réel actuel, il peut y avoir un problème avec la réception des journaux d'archives du primaire.
Quelles séquences de journaux d'archives sont à quel stade pour le standby logique ?
Exécutez le code SQL suivant sur la base de données Logical standby :
SELECT 'RESTART' "TYPE", P.RESTART_SCN "SCN", TO_CHAR(P.RESTART_TIME,'yyyy/mm/dd hh24:mi:ss') "TIME", L.SEQUENCE# "SEQ#"
FROM V$LOGSTDBY_PROGRESS P,DBA_LOGSTDBY_LOG L WHERE P.RESTART_SCN >= L.FIRST_CHANGE# and P.RESTART_SCN < L.NEXT_CHANGE#
UNION
SELECT 'RESTART', P.RESTART_SCN, TO_CHAR(P.RESTART_TIME,'yyyy/mm/dd hh24:mi:ss'), L.SEQUENCE#
FROM V$LOGSTDBY_PROGRESS P, V$STANDBY_LOG L WHERE P.RESTART_SCN >= L.FIRST_CHANGE# et P.LATEST_SCN <=L.LAST_CHANGE#
UNION
SELECT 'APPLIED', P.APPLIED_SCN, TO_CHAR(P.APPLIED_TIME,'yyyy/mm/dd hh24:mi:ss'), L.SEQUENCE#
FROM V$LOGSTDBY_PROGRESS P,DBA_LOGSTDBY_LOG L WHERE P.APPLIED_SCN >= L.FIRST_CHANGE# and P.APPLIED_SCN < L.NEXT_CHANGE#
UNION
SELECT 'APPLIED', P.APPLIED_SCN, TO_CHAR(P.APPLIED_TIME,'yyyy/mm/dd hh24:mi:ss'), L.SEQUENCE#
FROM V$LOGSTDBY_PROGRESS P, V$STANDBY_LOG L WHERE P.APPLIED_SCN >=L.FIRST_CHANGE# et P.LATEST_SCN <=L.LAST_CHANGE#.
UNION
SELECT 'MINING', P.MINING_SCN, TO_CHAR(P.MINING_TIME,'yyyy/mm/dd hh24:mi:ss'), L.SEQUENCE#
FROM V$LOGSTDBY_PROGRESS P, DBA_LOGSTDBY_LOG L WHERE P.MINING_SCN >= L.FIRST_CHANGE# and P.MINING_SCN < L.NEXT_CHANGE#
UNION
SELECT 'MINING', P.MINING_SCN, TO_CHAR(P.MINING_TIME,'yyyy/mm/dd hh24:mi:ss'), L.SEQUENCE#
FROM V$LOGSTDBY_PROGRESS P, V$STANDBY_LOG L WHERE P.MINING_SCN >= L.FIRST_CHANGE# et P.LATEST_SCN <=L.LAST_CHANGE#
UNION
SELECT 'SHIPPED', P.LATEST_SCN, TO_CHAR(P.LATEST_TIME,'yyyy/mm/dd hh24:mi:ss'), L.SEQUENCE#
FROM V$LOGSTDBY_PROGRESS P, DBA_LOGSTDBY_LOG L WHERE P.LATEST_SCN >= L.FIRST_CHANGE# and P.LATEST_SCN < L.NEXT_CHANGE#
UNION
SELECT 'SHIPPED', P.LATEST_SCN, TO_CHAR(P.LATEST_TIME,'yyyy/mm/dd hh24:mi:ss'), L.SEQUENCE#
FROM V$LOGSTDBY_PROGRESS P, V$STANDBY_LOG L WHERE P.LATEST_SCN >= L.FIRST_CHANGE# and P.LATEST_SCN <=L.LAST_CHANGE# ;Une information importante est le SEQ# associé à RESTART. Bien que les journaux d'archives puissent avoir été exploités et appliqués, les journaux d'archives jusqu'au SEQ# RESTART sont nécessaires en cas de redémarrage de l'application SQL.
********
Quels sont les événements majeurs de l'application SQL qui se sont produits ?
Exécutez le code SQL suivant sur la base de données Logical standby :
SET LINESIZE 200
SET LONG 400
SET PAGESIZE 999
colonne EVENT_TIME FORMAT A20
colonne STATUS FORMAT A50
colonne EVENT FORMAT A100
SELECT TO_CHAR(EVENT_TIME,'YYYY/MM/DD HH24:MI:SS') "EVENT_TIME", STATUS, EVENT FROM DBA_LOGSTDBY_EVENTS ORDER BY EVENT_TIME ;
Par défaut, seuls les 100 derniers événements sont répertoriés. Vous pouvez avoir la chance de trouver des événements plus anciens dans le fichier alert.log, mais cela ne permet pas toujours d'afficher toutes les informations.
Quels sont les principaux événements Dataguard qui se sont produits ?
Exécutez le code SQL suivant sur la base de données Logical standby :
SET PAGESIZE 999
SET LINESIZE 132
colonne TIME FORMAT A19
colonne ERROR FORMAT 999999
colonne FORMAT DEST 9999
colonne MESSAGE FORMAT A90
SELECT TO_CHAR(TIMESTAMP,'yyyy/mm/dd hh24:mi:ss') "TIME", ERROR_CODE "ERROR", DEST_ID "DEST", MESSAGE
FROM V$DATAGUARD_STATUSWHERE timestamp > TRUNC(sysdate+6/24)
ORDER by timestamp DESC ;
Quels objets ou quelles instructions sont ignorés par Sql Apply ?
Exécutez le code SQL suivant sur la base de données Logical standby :
set linesize 132
set pagesize 999
colonne STATEMENT_OPT FORMAT A30
colonne OWNER FORMAT A20
colonne NAME FORMAT A30
colonne PROC FORMAT A30
SELECT STATEMENT_OPT, OWNER, NAME, PROC FROM DBA_LOGSTDBY_SKIP ;
Pour vérifier si des transactions spécifiques sont programmées pour être ignorées, exécutez le code SQL suivant sur la base de données Logical standby :
SELECT * FROM DBA_LOGSTDBY_SKIP_TRANSACTION ;
Que font les processus Sql Apply en cours d'exécution ?
Exécutez le code SQL suivant sur la base de données Logical standby :
set linesize 132
COLONNE SID FORMAT 99999
COLONNE SERIAL# FORMAT 9999999
COLONNE LOGSTDBY_ID FORMAT 99999
COLONNE SPID FORMAT A10
COLONNE TYPE FORMAT A12
COLONNE STATUS_CODE FORMAT 99999
COLONNE STATUS FORMAT A50
COLONNE HIGH_SCN FORMAT 9999999999
SELECT SID, SERIAL#, LOGSTDBY_ID, SPID, TYPE, STATUS_CODE, HIGH_SCN, STATUS
FROM v$logstdby_process ;La colonne STATUS est très descriptive de ce que fait chaque processus Sql Apply.
Où vont les journaux d'archives et y a-t-il des problèmes de réalisation ?
Exécutez le code SQL suivant sur la base de données logique de secours ou primaire :
set linesize 150
colonne DID FORMAT 999
colonne STATUS FORMAT A10
colonne DESTINATION FORMAT A30
colonne ARCHIVER FORMAT A4
colonne VALID_TYPE FORMAT A15
colonne VALID_ROLE FORMAT A12
colonne VALID_NOW FORMAT A16
colonne RECOVERY_MODE FORMAT A30
colonne ERROR FORMAT A40
SELECT DEST_ID "DID", STATUS, DESTINATION, ARCHIVER, VALID_NOW, VALID_TYPE, VALID_ROLE, ERROR FROM V$ARCHIVE_DEST
WHERE STATUS <> 'INACTIVE' ;
Quels sont les paramètres et les statistiques actuels de Sql Apply ?
Exécutez le code SQL suivant sur la base de données logique de secours ou la base de données primaire :
SELECT NAME, VALUE FROM V$LOGSTDBY_STATS ;Ce tableau contient de nombreuses informations utiles.
Comment savoir s'il n'y a pas assez de processus d'application ?
Exécutez le code SQL suivant sur la base de données logique de secours ou primaire :
COLONNE TRAN_APPLIED FORMAT A10
COLONNE TRAN_READY FORMAT A10
COLONNE NUM_APPLIERS FORMAT A10
COLONNE RATIO FORMAT 9999999999
SELECT TA.TRAN_APPLIED, TR.TRAN_READY, AP.NUM_APPLIERS, (TA.TRAN_APPLIED - TR.TRAN_READY )/ AP.NUM_APPLIERS "RATIO
FROM
(SELECT VALUE "TRAN_READY" FROM V$LOGSTDBY_STATS WHERE NAME = 'transactions ready') TR,
(SELECT VALUE "TRAN_APPLIED" FROM V$LOGSTDBY_STATS WHERE NAME = 'transactions appliquées') TA,
(SELECT VALUE "NUM_APPLIERS" FROM V$LOGSTDBY_STATS WHERE NAME = 'nombre de demandeurs') AP ;
La colonne RATIO doit renvoyer une valeur égale ou supérieure à 0.
Une valeur comprise entre 0 et 1 signifie qu'il y a des processus d'application inactifs et qu'il n'y a pas de gain à ajouter des processus d'application supplémentaires.
Une valeur comprise entre 1 et 2 signifie qu'il y a des transactions en file d'attente qui attendent d'être appliquées et qu'il n'y a qu'un gain minime à ajouter des processus d'application supplémentaires.
Une valeur supérieure à 2 indique qu'il y a de la contention sur les processus d'application et que des processus d'application supplémentaires doivent être ajoutés.
Ce processus doit être exécuté sur une certaine période car il ne mesure que des valeurs instantanées.
Comment sauter une transaction spécifique ?
1. Obtenez les valeurs XIDUSN, XIDSLT et XIDSQN de la transaction défaillante à partir de la table DBA_LOGSTDBY_EVENTS. Le code SQL suivant peut être utile :
SET LINESIZE 200
SET LONG 400
SET PAGESIZE 999
colonne EVENT_TIME FORMAT A20
colonne STATUS FORMAT A50
colonne CURRENT_SCN 999999999999999
colonne COMMIT_SCN 999999999999999
colonne XIDUSN FORMAT 999999
colonne XIDSLT FORMAT 999999
colonne XIDSQN FORMAT 999999
SELECT TO_CHAR(EVENT_TIME,'YYYY/MM/DD HH24:MI:SS') "EVENT_TIME", STATUS, CURRENT_SCN, COMMIT_SCN, XIDUSN, XIDSLT, XIDSQN
FROM DBA_LOGSTDBY_EVENTS
WHERE EVENT_TIME > SYSDATE-1
et status like 'ORA-00955%'
ORDER BY EVENT_TIME ;
2. Exécutez manuellement la transaction ignorée en y apportant les modifications nécessaires.
3. Sauter l'instruction DDL qui a échoué en utilisant la procédure DBMS_LOGSTDBY.SKIP_TRANSACTION
. Avec les valeurs de l'étape 1.
exec dbms_logstdby.skip_transaction(, , ) ;
La déclaration suivante peut être utile :
SELECT 'exec dbms_logstdby.skip_transaction('||XIDUSN||','|| XIDSLT||','|| XIDSQN||');' FROM DBA_LOGSTDBY_EVENTS where ...4. Redémarrer Sql Apply.
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE ;
Comment arrêter et démarrer les processus SqlApply ?
Exécutez le code SQL suivant sur le serveur logique de secours pour démarrer SqlApply en temps réel :
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE ;
Exécutez le code SQL suivant sur le standby logique pour démarrer SqlApply en temps réel si SqlApply a échoué avec une erreur et que vous êtes certain à 100 % que la transaction peut être ignorée :
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE SKIP FAILED TRANSACTION ;
Exécutez le code SQL suivant sur l'attente logique pour arrêter SqlApply :
ALTER DATABASE STOP LOGICAL STANDBY APPLY ;
Commentaires
Enregistrer un commentaire