Discussion :

[matana]

Bonjour,
Je travaille sous une base de données Oracle 10g.
Un export est effectué chaque soir, et à la fin de celui-ci, toutes les données sont enregistrées sur une bande magnétique. C'est ainsi que nous sauvegardons la base (nous n'avons pas choisi d'être en mode archivlog, nous estimons qu'une perte d'une journée n'est pas catastrophique...)
Mon souci est qu'avant, sous Oracle 7, on fermait la base avant de lancer l'enregistrement sur bande, puis on la remontait le matin.
Or avec la 10g j'avais un souci de startup, que je n'avais pas réussi à résoudre, donc la sauvegarde sur bande se fait base montée (même si personne le soir ne travaille dessus), ma question est de savoir si c'est grave, ou dangereux, de ne pas descendre la base...
Merci de vos réponses

[orafrance]

si c'est bien le fichier export que tu sauvegardes, c'est complétement indépendant de ta base. Donc qu'elle soit démmarrée ou non n'a aucune espéce d'importance

par contre, la sauvegarde par export doit être réalisé alors qu'aucune donnée n'est modifiée dans la base sans quoi tu risques d'avoir des incohérences dans les données

[matana]

si c'est bien le fichier export que tu sauvegardes, c'est complétement indépendant de ta base. Donc qu'elle soit démmarrée ou non n'a aucune espéce d'importance

par contre, la sauvegarde par export doit être réalisé alors qu'aucune donnée n'est modifiée dans la base sans quoi tu risques d'avoir des incohérences dans les données

Je sauvegarde pas seulement l'export mais tout le disque sur lequel sont stockées les fichiers de la base, tous les datafiles etc... Est-ce qu'on peut base ouverte ?
Pour les incohérences... disons que j'exporte à 19h en supposant que plus personne n'utilise la base à cette heure-ci, et c'est pratiquement toujours le cas.

[orafrance]

bah dans ce cas tu peux pas le faire en NOARCHIVELOG et surtout sans un minimum de préparation... tu sais c'est bien de sauvegarder mais si tu ne testes jamais la restauration, ça ne sert à rien

pour info : http://download-uk.oracle.com/docs/c....htm#sthref111

[matana]

bah dans ce cas tu peux pas le faire en NOARCHIVELOG et surtout sans un minimum de préparation... tu sais c'est bien de sauvegarder mais si tu ne testes jamais la restauration, ça ne sert à rien

pour info : http://download-uk.oracle.com/docs/c....htm#sthref111

Merci pour tes réponses.
Oui je sais que je devrais faire des tests... Je ne suis pas dba moi comme tu peux le constater, et c'est pas trop ma tasse de thé... Je manque de temps, aussi...
Le mieux serait de descendre ma base donc, chaque soir après l'export et AVANT de sauvegarder sur bande, n'est-ce pas ?
Faut juste que je trouve comment la remonter après, car je ne sais pourquoi, lorsque je fais un startup, ça me dit pb d'instance ou de tns, je n'sais plus, ça ne veut pas marcher... Par contre si je redémarre le serveur, ça remonte la base parfaitement... et ce problème je ne l'ai que depuis la 10g...

[ducho]

Bonjour,

nous faisons de même ici,
c' est préférable d' exclure les datafiles et redo-logs de la sauvegarde
base ouverte .

il faut vérifier les logs de la sauvegarde ( tout dépends de l' outil)

soit les fichiers sont pris par oracle et ignorés par la sauvegarde
(meilleur des cas)

soit les fichiers sont sauvegardés (base ouvete ) et alors en général
ils sont pris en exclusivité par la sauvegarde : si oracle en a besoin
(en écriture) , oracle part en crash direct
(on a rencontré ce cas avec ntbackup !)

cdlt

PS : l' idéal c' était bien de fermer la base avant la sauvegarde
s' il n' y a pas de contrainte d' exploitation

[orafrance]

Sous windows ? Si oui alors redémarre le service Oracle tout simplement.

[matana]

Bonjour,

nous faisons de même ici,
c' est préférable d' exclure les datafiles et redo-logs de la sauvegarde
base ouverte .

il faut vérifier les logs de la sauvegarde ( tout dépends de l' outil)

soit les fichiers sont pris par oracle et ignorés par la sauvegarde
(meilleur des cas)

soit les fichiers sont sauvegardés (base ouvete ) et alors en général
ils sont pris en exclusivité par la sauvegarde : si oracle en a besoin
(en écriture) , oracle part en crash direct (on a rencontré ce cas avec ntbackup !)

cdlt

PS : l' idéal c' était bien de fermer la base avant la sauvegarde
s' il n' y a pas de contrainte d' exploitation

Ok ok merci, je commence à baliser là... surtout avec ton "oracle part en crash direct " !
Faut absolument que je règle ce problème... Merci en tout cas.

[matana]

Sous windows ? Si oui alors redémarre le service Oracle tout simplement.

Oui je suis sous windows.
Faut que je redémarre le service avant de faire le startup ? Et est-il possible de la faire en tâche planifiée ?
Le souci c'est que là je ne pourrais faire les tests que ce soir, quand tout le monde sera parti, pour ne pas déranger les utilisateurs...
Merci encore...

[ducho]

il ne faut pas dramatiser ...
si oracle part en crash parsqu' il ne peut pas écrire dans un de ses fichiers,
la base redémarrera soit aprés un recover soit sans rien faire si ses
fichiers sont libres ...

quel script utilises-tu pour arrêter la base ?
utilises-tu oradim (si ca existe toujours en oracle10) ou un script sqlplus
ou arrêtes-tu le service ?

cdlt

[orafrance]

nous faisons de même ici,
c' est préférable d' exclure les datafiles et redo-logs de la sauvegarde
base ouverte .

tu sauvegardes quoi dans ce cas ?

[matana]

il ne faut pas dramatiser ...
si oracle part en crash parsqu' il ne peut pas écrire dans un de ses fichiers,
la base redémarrera soit aprés un recover soit sans rien faire si ses
fichiers sont libres ...

quel script utilises-tu pour arrêter la base ?
utilises-tu oradim (si ca existe toujours en oracle10) ou un script sqlplus
ou arrêtes-tu le service ?

cdlt

J'utilise des scripts sql que j'exécute en tâche planifiée.
Pour descendre la base, je fais un shutdown immediate.
Je touche pas aux services... Devrais-je ?

[orafrance]

Oui je suis sous windows.
Faut que je redémarre le service avant de faire le startup ? Et est-il possible de la faire en tâche planifiée ?
Le souci c'est que là je ne pourrais faire les tests que ce soir, quand tout le monde sera parti, pour ne pas déranger les utilisateurs...
Merci encore...

En principe les services gérent aussi la base donc quand tu démarres le service ça démarre la base... mais de toute façon, le démarrage du service est un pré-requis au STARTUP. Ton problème de TNS venait de là. Quand tu redémarres le serveur, le service qui est probablement en automatique démarre et donc le STARTUP se passe bien

Oui tu peux le planifier grace à ORADIM -> recherche

il ne faut pas dramatiser ...
si oracle part en crash parsqu' il ne peut pas écrire dans un de ses fichiers,
la base redémarrera soit aprés un recover soit sans rien faire si ses
fichiers sont libres ...

et si tu n'es pas en archive log et qu'une transaction était en cours, tu as toutes les chances d'avoir un UNDO corrompu impossible à restaurer
en plus, Oracle ne supporte évidemment pas ce type de sauvegarde

[matana]

En principe les services gérent aussi la base donc quand tu démarres le service ça démarre la base... mais de toute façon, le démarrage du service est un pré-requis au STARTUP. Ton problème de TNS venait de là. Quand tu redémarres le serveur, le service qui est probablement en automatique démarre et donc le STARTUP se passe bien

Oui tu peux le planifier grace à ORADIM -> recherche

Ok merci, je vais chercher alors... (mais si je trouve pas je reviens

[ducho]

et si tu n'es pas en archive log et qu'une transaction était en cours, tu as toutes les chances d'avoir un UNDO corrompu impossible à restaurer
en plus, Oracle ne supporte évidemment pas ce type de sauvegarde

tout à fait d' accord, c' est le gros risque.

tu sauvegardes quoi dans ce cas ?

nous enlevons tous ces fichiers de nos sauvegardes pour sauvegarder tout le
disque (qui malheureusement contient aussi les exports des bases ) et
d' autres fichiers ...

[orafrance]

OK, donc sauvegarde système de laquelle tu enlèves Oracle qui ne servirait à rien pour la restauration

[matana]

OK, donc sauvegarde système de laquelle tu enlèves Oracle qui ne servirait à rien pour la restauration

Pour mon cas, si nous devions restaurer nous utiliserions le dump, et non la sauvegarde physique de la bande, que l'on fait qd même, juste au cas où, en plus quoi...

[ducho]

Pour mon cas, si nous devions restaurer nous utiliserions le dump, et non la sauvegarde physique de la bande, que l'on fait qd même, juste au cas où, en plus quoi...

nous somme bien d' accord mais la sauvegarde physique sur bande doit se faire soit sans les fichiers utilisés par oracle soit base fermée, sinon tu peux rencontrer les cas cités¨+ haut .

il faut regarder les logs de la sauvegarde pour être sur .

cdlt

[matana]

nous somme bien d' accord mais la sauvegarde physique sur bande doit se faire soit sans les fichiers utilisés par oracle soit base fermée, sinon tu peux rencontrer les cas cités¨+ haut .

il faut regarder les logs de la sauvegarde pour être sur .

cdlt

Justement, les fichiers logs de la sauvegarde allaient bien jusquà la semaine dernière, appremment au bout de 8 ou 9h il sature (la bande n'est sans doute pas assez grosse niveau stockage)... Je ne sais pas trop, mais déjà ce soir quand tout le monde sera parti j'essairais de descendre et remonter la base.
J'ai qq pistes, déjà voir le démarrage automatique du service, et puis peut-être ajouté à mon startup "starttype srvc" (j'ai lu ça mais je sais pas encore ce que c'est...) ou encore "net stop" "net start" à mettre avant le shutdown et le startup...

[orafrance]

Pour mon cas, si nous devions restaurer nous utiliserions le dump, et non la sauvegarde physique de la bande, que l'on fait qd même, juste au cas où, en plus quoi...

dans ce cas, attention. L'indisponibilité est plus longue qu'une seule journée. Il faut compter la création de la base (attention au init.ora entre autre) et des tablespaces ainsi que l'importation des données en espérant qu'il n'y a pas d'objets créés par mégarde sous SYS ou SYSTEM... autant dire que c'est plus que risqué comme sauvegarde surtout si le plan de restauration n'est pas maitrisé