Problème lors de la sauvegarde Oracle 10g

Question

Je viens de démarrer un travail et j'ai identifié un problème dans lequel la base de données n'est pas correctement sauvegardée pour ainsi dire. Nous faisons une sauvegarde toutes les 6 heures qui utilise l'utilitaire de sauvegarde natif Oracle, mais nous avons également vendu un processus par une société dans laquelle ils ont déclaré qu'ils pouvaient effectuer des sauvegardes "chaudes" de notre base de données en prenant simplement des copies de système de fichiers de nos fichiers de base de données et quand nous avions besoin de restaurer, nous fermions simplement Oracle, puis copions sur les fichiers qui avaient été copiés, redémarrer Oracle et le monde serait à nouveau entier. Le défi est le fait que nous n'avons pas encore tout compris. Je dois passer plus de temps à examiner le message qu'Oracle donne, mais ma question principale est: «Est-il possible» de prendre des copies de fichiers Oracle alors qu'Oracle est toujours en cours d'exécution et d'utiliser ces fichiers ultérieurement pour restaurer la base de données ? Je sais que cela fonctionne si la base de données est arrêtée, et que des copies sont faites, mais c'est la première fois que j'ai entendu qu'une copie (système de fichiers) peut être faite pendant que la base de données fonctionne. Toute orientation serait grandement appréciée. Voici l'erreur que nous recevons.

ORA-00314: log 3 of thread 1, expected sequence# 1939 doesn't match 1944 
ORA-00312: online log 3 thread 1: 'E:\ORACLE\ORADATA\ITMS\REDO03.LOG' 

Answer 1

Oui, il est possible, mais vous devez mettre toutes les tablespaces en mode de sauvegarde d'abord et les enlever par la suite (par exemple ALTER TABLESPACE x BEGIN BACKUP et ALTER TABLESPACE x END BACKUP, vous devrez vérifier la syntaxe et assurez-vous qu'il est approprié pour ta situation!). Surimposant énormément, ceci indique à Oracle de n'écrire aucun des fichiers de données, ainsi ils sont tous maintenus dans un état cohérent.

Les deux principaux problèmes que vous rencontrez sont que les fichiers individuels sont mis à jour pendant que vous les copiez afin qu'un seul fichier puisse être corrompu; et plus visiblement que différents fichiers ont des horodatages et des séquences internes différents, de sorte qu'Oracle ne les autorisera pas à être utilisés.

Si vous utilisez un processus que vous avez acheté alors il devrait déjà prendre soin de tout cela. Il semble que la sauvegarde soit OK et que la restauration ne fonctionne pas.

Je n'ai pas été impliqué dans une restauration à partir d'une sauvegarde à chaud pendant un certain temps, alors quelqu'un d'autre devra donner le détail de l'erreur réelle. Ma lecture de cela est que vous avez essayé d'ouvrir avec les fichiers de données restaurés, mais les journaux de reprise en direct plus tard. Lors de la restauration, je pense que vous devez soit RECOVER la base de données en utilisant les journaux de rétablissement générés depuis la sauvegarde a été prise; ou si vous essayez de restaurer à ce point dans le temps, vous pouvez ouvrir les données avec la directive RESETLOGS et perdre tous les changements de tous les journaux de rétablissement qui sont venus plus tard. Mais prenez vraiment des conseils plus éclairés que cela ...

Answer 2

Pour autant que je sache, il existe deux façons de "copier" des fichiers de données à partir d'une instance Oracle en cours d'exécution.

• Les fichiers de données sont copiées pour un tablespace lorsque le tablespace est en mode "BEGIN BACKUP".
• Vous utilisez un haut de gamme tourillonnement système de fichiers tels que Veritas qui peut bloc instantané et la piste changements sur le système de fichiers alors que la copie est en cours.

Answer 3

C'est possible. Vous devez être en mode ARCHIVELOG.

Un exemple de script serait pour le manuel:

Alter tablespace USERS begin backup; 
host cp -p /u02/oradata/PROD/users01.dbf /u03/backup/PROD/ 
host cp -p /u02/oradata/PROD/users02.dbf /u03/backup/PROD/ 
Alter tablespace USERS end backup; 

Cependant, je recommanderais simplement utiliser RMAN. RMAN est QUITE ROBUST, inclus gratuitement, et fera la sauvegarde à chaud, ainsi que le froid.Il clone vers une autre instance, clone comme un point dans le temps, récupère à un certain moment, etc. Toute procédure de sauvegarde manuelle doit être migrée vers l'utilisation de RMAN.

Si vous voulez sauvegarder la base de données entière alors qu'il est ouvert (je préfère comme Oracle avec DBA afin de vous éviter les mots de passe dans les scripts, mais YMMV):

$ ORAENV_ASK=NO 
$ ORACLE_SID=PROD 
$ . oraenv 
$ rman target=/ 

Recovery Manager: Release 10.2.0.4.0 - Production on Thu Oct 28 14:23:29 2010 

Copyright (c) 1982, 2007, Oracle. All rights reserved. 

connected to target database: PROD (DBID=x) 

RMAN> backup as compressed backupset database plus archivelog; 

... 

Backup Complete. 

Answer 4

Je l'ai fait efficacement cela avec un base de données non critique sur Amazon EC2. Ma stratégie de sauvegarde consiste à prendre périodiquement un instantané du volume EBS. Pour restaurer une sauvegarde, je crée un nouveau volume EBS à partir de l'instantané, démarre l'instance en l'utilisant, puis exécute RECOVER DATABASE.

Ceci perd toutes les transactions qui étaient en vol au moment où l'instantané a été pris, bien sûr.