Discussion :

[phil4444]

tu as pas tout à fait tord, mais tu n'as pas tout à fait raison à la différence près que lorsque je suis dans une fenêtre dos et que je lance sqlplus, je peux chaîner mon shutdown, les commandes sql et à la fin faire un startup et ça fonctionne très bien

[philcero]

Tu es dans le même mode de connexion dans tes deux tests (L'un semble en mode client/serveur, l'autre en mode direct/local) ?

[phil4444]

les deux sont en direct/local dans un cas je lance au travers d'une console cygwin dans l'autre cas avec une console sqlplus

apparemment il perd le tns

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
ORA-12514: TNS : le processus d'Úcoute ne conna¯t pas actuellement le service d
mandÚ dans le descripteur de connexion
ORA-24324: descripteur de service non initialisÚ
ORA-01041: erreur interne. extension hostdef n'existe pas

C'est cygwin qui pose problème, j'essais de voir ça

[phil4444]

j'ai vérifié le tnsnames.ora, le sqlnet.ora et le listener.ora tout est conforme et je ne vois pas pourquoi dans le script il perd le listener alors qu'il est démarré et donc par le faite je n'arrive pas a redémarrer ma base avec la commande startup après le shutdown immediate ou abort ça change rien

[phil4444]

j'ai une erreur ORA-19909 incarnation orpheline "SYSTEM01.DBF"
comment je peux rattraper le coup

[philcero]

Là tu atteints mais limites...

[orafrance]

tu ne peux pas, tu as restauré un fichier d'une autre incarnation de la base et c'est le system... donc tu es cuis. Il faut que tu remettes une sauvegarde de l'incarnation courrante.

[phil4444]

Ce que je ne comprends pas, c'est que j'ai fais une sauvegarde à froid aussi et que je pensais en copiant tous les fichiers de la base dans le répertoire et avec les des archived redo logs j'aurais pu remettre ma base d'équerre

[orafrance]

une sauvegarde à froid permet d'être sûr d'avoir une base cohérente. Les archives logs ou redos sont alors inutiles puisque tout est écrit dans les fichiers qui sont synchronisés à l'arrêt de l'instance.

[phil4444]

ça serait les redo logs alors qui feraient que ma base n'est pas cohérente.
Pour faire cette sauvegarde à froid, je fais un shutdown immediate et je fais un copie des tous les fichiers, il faut plus que je sauvegarde les redo logs dans ce cas alors

[Milo59000]

Oui,
Lors d'une sauvegarde à froid, tu dois sauvegarder DATAFILES, CONTROL FILES et REDO LOGS.

[Milo59000]

Par contre j'aurai une question comme ca parle de backup ici.

Lors d'une sauvegarder à froid (c'est-à-dire base éteinté et copie des DATA, CONTROL et REDO), à quoi ca sert de sauvegarder les ARCHIVED REDO LOG ?

Comme de toute façon on ne les utilisera pas vu que la sauvegarde est cohérente et que les informations contenues dasn les ARCHIVED sont déjà dans les DATA.

[Jaouad]

Par contre j'aurai une question comme ca parle de backup ici.

Lors d'une sauvegarder à froid (c'est-à-dire base éteinté et copie des DATA, CONTROL et REDO), à quoi ca sert de sauvegarder les ARCHIVED REDO LOG ?

Comme de toute façon on ne les utilisera pas vu que la sauvegarde est cohérente et que les informations contenues dasn les ARCHIVED sont déjà dans les DATA.

Bonjour ,

C 'est trés utile , car si vous devez restaurer la base de données sans les redo , il faut les re créer et puis Reseter les logs : Ce n'est pas une opération anodine puisque c'est une nouvelle instanciation de la base de données

De plus si vous avez correctement arrêtés votre base de données, il se peut qu'il y ai des opérations qui ne sont pas encore dans les archives logs

[Jaouad]

Ce que je ne comprends pas, c'est que j'ai fais une sauvegarde à froid aussi et que je pensais en copiant tous les fichiers de la base dans le répertoire et avec les des archived redo logs j'aurais pu remettre ma base d'équerre

Peux tu essayer cette commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

recover database

Il peut s'agir juste du SCN qui est désynchroniser , si tu as de la chance ...

[Milo59000]

Bonjour ,

C 'est trés utile , car si vous devez restaurer la base de données sans les redo , il faut les re créer et puis Reseter les logs : Ce n'est pas une opération anodine puisque c'est une nouvelle instanciation de la base de données

De plus si vous avez correctement arrêtés votre base de données, il se peut qu'il y ai des opérations qui ne sont pas encore dans les archives logs

???? Si on fait une sauvegarde à froid en arrêtant correctement la base de données (avec un shutdown immediate, donc on attends la fin des transactions), on aura les info dans les redo logs que l'on sauvegarde et toutes autres modifications apportées sur la base seront présent dans les data files. Dans ce cas je ne vois pas l'intérêt de sauvegarder les archived logs vu que les informations qu'ils contiennent sont déjà présentes dans les fichiers de données...

[Jaouad]

Tu fais une sauvegarde quotidienne ou tu sauvegares ta base de données + tes archives logs

Jour J tu veux restaurer la base de données à l'état de J -1 ( à 16 heures ) pour reproduire un Bug suite à un chargement de données ( et avant que les batchs de traitement commencent ) par exemple.

Tu es bel et bien obligé de restaurer la base de données à J-2 puis appliquer les journaux pour effectuer une restauration icompléte ou PITR.

A moins que tu sois en 10G et que tu es activé la nouvelle fonctionnalité Recovery. Mais le principe demeure le même , tu n'as plus besoin de tes archives Logs mais tu as besoin de tes Journaaux (Pas les Redo)

http://jaouad.developpez.com/highdisponibility/#LIII

On définit également sa stratégie de sauvegarde en fonction de l'eventuelle restauration

[Milo59000]

Ok... dis comme ca... donc les archived log doivent être sauvegardés.

C'est ce que je disais

En fait, j'ai comme projet l'études des moyens de sauvegarde/restauration au travers des versions 9i, 10g et 11g d'oracle database. Donc je dois regarder toutes les technologies disponibles, créer des scripts afin de pouvoir résoudre rapidement n'importe quel problème (perte de lignes, perte de tables, datafiles, ctl etc...).

Et je me rends compte que pour tout ce qui est sauvegarde à froid/à chaud et restauration, la création de script n'est pas évident... même pratiquement impossible vu le nombre de situation différentes qui peut y avoir. Donc du coup je fais des scripts qui serviront plus, à mon avis, de templates.

En tout cas merci pour la précision que tu as apportés ^^.

Quoiqu'une autre question a surgi de mon esprit, si tu fais des backup à chaud, faut-il également inclure les archived redo logs ? Et une fois que tu as sauvegardé tes archived redo logs (à chaud ou à froid), peux-tu les supprimer de ton disque et des vues oracle (log_history) sans passer par Rman ?

[orafrance]

ça serait les redo logs alors qui feraient que ma base n'est pas cohérente.
Pour faire cette sauvegarde à froid, je fais un shutdown immediate et je fais un copie des tous les fichiers, il faut plus que je sauvegarde les redo logs dans ce cas alors

pas la peine, les redos sont nécessaires uniquement pour un shutdown abort puisque dans ce cas Oracle n'aura pas fait l'étape de synchro des fichiers

Mais faudrait vraiment que tu lises la doc sur LOGWR

[orafrance]

Quoiqu'une autre question a surgi de mon esprit, si tu fais des backup à chaud, faut-il également inclure les archived redo logs ? Et une fois que tu as sauvegardé tes archived redo logs (à chaud ou à froid), peux-tu les supprimer de ton disque et des vues oracle (log_history) sans passer par Rman ?

oui, tu peux les supprimé s'ils sont sauvé mais pas dans le dictionnaire. Log_history n'est vidé que lors de la création d'une nouvelle incarnation (RESETLOGS)

[Jaouad]

Et je me rends compte que pour tout ce qui est sauvegarde à froid/à chaud et restauration, la création de script n'est pas évident... même pratiquement impossible vu le nombre de situation différentes qui peut y avoir. Donc du coup je fais des scripts qui serviront plus, à mon avis, de templates.

Le plus important dans une politique de sauvegarde/Bakup ce n'est pas les scripts mais bel et bien de définir cette politique. Dés que tu as effectué cette étape, il est par la suite assez d'aiser de developper des scripts qui vont générer de maniére dynamique la base de données :

Il suffit pour ca de requêter sur les vues systémes
DBA_DATA_FILES
DBA_TEMP_FILES
V$LOGFILE
(...)

Quoiqu'une autre question a surgi de mon esprit, si tu fais des backup à chaud, faut-il également inclure les archived redo logs ? Et une fois que tu as sauvegardé tes archived redo logs (à chaud ou à froid), peux-tu les supprimer de ton disque et des vues oracle (log_history) sans passer par Rman ?

Si tu fais des bakup à chaud , tu es obligé de sauvegarder les archivedLogs car sinon ton bakup ne sert à rien : Comment resynchroniser ta base de données execptés avec la archied Log , ou alors tu as une chance incroyable et dans tes REDO tu as tout tes séries de synchro de SCN de tes datafiles.

Aprés sauvegarde, tu peux les supprimer de ton disque, mais il me semble que seul un resetlog vident les vues archived_log etc ..;