Dans le cas où une base est sauvegardée via RMAN, peut on sans risque faire
des arrets demarrage de la base sans que ça pose de probleme à RMAN?
Je m'explique :
- je demarrage la base
- je fais une sauvegarde full via RMA
- la nuit suivante sauvegarde incrementale ou différentielle avec RMAN
- le lendemain je fait un arrêt relance de la base
- puis je encore faire une sauvegarde incrementale ou differentielle suite a
cet arrêt ou suis je dans ce cas obligé de me refaire une full avec RMAN?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Che Averell
"ici eat là" écrit :
Bonjour à tous,
Hello,
Dans le cas où une base est sauvegardée via RMAN, peut on sans risque faire des arrets demarrage de la base sans que ça pose de probleme à RMAN?
Non, pas de soucis. On peut sans problème arrêter la base sans qu'rman ne se mélange les pinceaux. Si bien entendu on n'arrête pas la base pendant qu'rman tourne !
Le seul soucis concernant la sauvegarde à chaud, c'est de garder la cohérence des données et en particulier des séquences. Explications : il commence par dumper les séquences. Ensuite il s'occupe des tables. Si après avoir fait les séquences et avant qu'il ne dumpe la table, on fait plein d'insert dans la table dont la pk est la valeur issue de la séquence, alors on va avoir dans la pk des valeurs qui ne seront pas considérées comme consommées dans la séquence.
Il vaut mieux essayer de prévoir une période calme pour faire sa sauvegarde, et si possible ne pas le faire « à chaud ».
- puis je encore faire une sauvegarde incrementale ou differentielle suite a cet arrêt ou suis je dans ce cas obligé de me refaire une full avec RMAN?
Oui, on peut, et non, on n'a pas besoin de refaire une full.
Merci pour vos retours
Ah mais de rien.
"ici eat là" <ici_et_la@free.fr> écrit :
Bonjour à tous,
Hello,
Dans le cas où une base est sauvegardée via RMAN, peut on sans risque faire
des arrets demarrage de la base sans que ça pose de probleme à RMAN?
Non, pas de soucis. On peut sans problème arrêter la base sans qu'rman
ne se mélange les pinceaux. Si bien entendu on n'arrête pas la base
pendant qu'rman tourne !
Le seul soucis concernant la sauvegarde à chaud, c'est de garder la
cohérence des données et en particulier des séquences. Explications :
il commence par dumper les séquences. Ensuite il s'occupe des tables.
Si après avoir fait les séquences et avant qu'il ne dumpe la table, on
fait plein d'insert dans la table dont la pk est la valeur issue de
la séquence, alors on va avoir dans la pk des valeurs qui ne seront
pas considérées comme consommées dans la séquence.
Il vaut mieux essayer de prévoir une période calme pour faire sa
sauvegarde, et si possible ne pas le faire « à chaud ».
- puis je encore faire une sauvegarde incrementale ou differentielle suite a
cet arrêt ou suis je dans ce cas obligé de me refaire une full avec RMAN?
Oui, on peut, et non, on n'a pas besoin de refaire une full.
Dans le cas où une base est sauvegardée via RMAN, peut on sans risque faire des arrets demarrage de la base sans que ça pose de probleme à RMAN?
Non, pas de soucis. On peut sans problème arrêter la base sans qu'rman ne se mélange les pinceaux. Si bien entendu on n'arrête pas la base pendant qu'rman tourne !
Le seul soucis concernant la sauvegarde à chaud, c'est de garder la cohérence des données et en particulier des séquences. Explications : il commence par dumper les séquences. Ensuite il s'occupe des tables. Si après avoir fait les séquences et avant qu'il ne dumpe la table, on fait plein d'insert dans la table dont la pk est la valeur issue de la séquence, alors on va avoir dans la pk des valeurs qui ne seront pas considérées comme consommées dans la séquence.
Il vaut mieux essayer de prévoir une période calme pour faire sa sauvegarde, et si possible ne pas le faire « à chaud ».
- puis je encore faire une sauvegarde incrementale ou differentielle suite a cet arrêt ou suis je dans ce cas obligé de me refaire une full avec RMAN?
Oui, on peut, et non, on n'a pas besoin de refaire une full.
Merci pour vos retours
Ah mais de rien.
ici eat là
"Che Averell" a écrit dans le message de news:
"ici eat là" écrit :
Bonjour à tous,
Hello,
Dans le cas où une base est sauvegardée via RMAN, peut on sans risque faire des arrets demarrage de la base sans que ça pose de probleme à RMAN?
Non, pas de soucis. On peut sans problème arrêter la base sans qu'rman ne se mélange les pinceaux. Si bien entendu on n'arrête pas la base pendant qu'rman tourne !
Le seul soucis concernant la sauvegarde à chaud, c'est de garder la cohérence des données et en particulier des séquences. Explications : il commence par dumper les séquences. Ensuite il s'occupe des tables. Si après avoir fait les séquences et avant qu'il ne dumpe la table, on fait plein d'insert dans la table dont la pk est la valeur issue de la séquence, alors on va avoir dans la pk des valeurs qui ne seront pas considérées comme consommées dans la séquence.
Il vaut mieux essayer de prévoir une période calme pour faire sa sauvegarde, et si possible ne pas le faire « à chaud ».
- puis je encore faire une sauvegarde incrementale ou differentielle suite a cet arrêt ou suis je dans ce cas obligé de me refaire une full avec RMAN?
Oui, on peut, et non, on n'a pas besoin de refaire une full.
Merci pour vos retours
Ah mais de rien.
Arf c'est sur cette histoire de sequence? Les nouvelles valeurs de la sequence ne se retrouve pas dans les archivelog que l'on sauvegarde à la fin pour avoir un système cohérent? Sinon ça me semble bizarre, la probabilité d'avoir des sequences incoherentes avec les données me semblent énorme.
"Che Averell" <averell@dalton-brothers.org> a écrit dans le message de news:
ygevdn1wzex.fsf@nospam.fr.eu.org...
"ici eat là" <ici_et_la@free.fr> écrit :
Bonjour à tous,
Hello,
Dans le cas où une base est sauvegardée via RMAN, peut on sans risque
faire
des arrets demarrage de la base sans que ça pose de probleme à RMAN?
Non, pas de soucis. On peut sans problème arrêter la base sans qu'rman
ne se mélange les pinceaux. Si bien entendu on n'arrête pas la base
pendant qu'rman tourne !
Le seul soucis concernant la sauvegarde à chaud, c'est de garder la
cohérence des données et en particulier des séquences. Explications :
il commence par dumper les séquences. Ensuite il s'occupe des tables.
Si après avoir fait les séquences et avant qu'il ne dumpe la table, on
fait plein d'insert dans la table dont la pk est la valeur issue de
la séquence, alors on va avoir dans la pk des valeurs qui ne seront
pas considérées comme consommées dans la séquence.
Il vaut mieux essayer de prévoir une période calme pour faire sa
sauvegarde, et si possible ne pas le faire « à chaud ».
- puis je encore faire une sauvegarde incrementale ou differentielle
suite a
cet arrêt ou suis je dans ce cas obligé de me refaire une full avec RMAN?
Oui, on peut, et non, on n'a pas besoin de refaire une full.
Merci pour vos retours
Ah mais de rien.
Arf c'est sur cette histoire de sequence? Les nouvelles valeurs de la
sequence ne se retrouve pas dans les archivelog que l'on sauvegarde à la fin
pour avoir un système cohérent?
Sinon ça me semble bizarre, la probabilité d'avoir des sequences
incoherentes avec les données me semblent énorme.
Dans le cas où une base est sauvegardée via RMAN, peut on sans risque faire des arrets demarrage de la base sans que ça pose de probleme à RMAN?
Non, pas de soucis. On peut sans problème arrêter la base sans qu'rman ne se mélange les pinceaux. Si bien entendu on n'arrête pas la base pendant qu'rman tourne !
Le seul soucis concernant la sauvegarde à chaud, c'est de garder la cohérence des données et en particulier des séquences. Explications : il commence par dumper les séquences. Ensuite il s'occupe des tables. Si après avoir fait les séquences et avant qu'il ne dumpe la table, on fait plein d'insert dans la table dont la pk est la valeur issue de la séquence, alors on va avoir dans la pk des valeurs qui ne seront pas considérées comme consommées dans la séquence.
Il vaut mieux essayer de prévoir une période calme pour faire sa sauvegarde, et si possible ne pas le faire « à chaud ».
- puis je encore faire une sauvegarde incrementale ou differentielle suite a cet arrêt ou suis je dans ce cas obligé de me refaire une full avec RMAN?
Oui, on peut, et non, on n'a pas besoin de refaire une full.
Merci pour vos retours
Ah mais de rien.
Arf c'est sur cette histoire de sequence? Les nouvelles valeurs de la sequence ne se retrouve pas dans les archivelog que l'on sauvegarde à la fin pour avoir un système cohérent? Sinon ça me semble bizarre, la probabilité d'avoir des sequences incoherentes avec les données me semblent énorme.
Che Averell
"ici eat là" écrit :
Arf c'est sur cette histoire de sequence? Les nouvelles valeurs de la sequence ne se retrouve pas dans les archivelog que l'on sauvegarde à la fin pour avoir un système cohérent?
Si. Imaginons une table t_test, avec une séquence s_test. La table t_test contient une colonne id_test, qui est la PK de la table, et dont la valeur est toujours le nextval de la séquence s_test. C-à-d que les insert sont toujours de la forme : insert into (t_test, ...) values (s_test.nextval, ...); .
Oracle commence toujours par sauvegarder les séquences, et fait ensuite les tables. Mais si on fait des inserts entre le moment où Oracle sauve la séquence, et le moment où Oracle sauve la table, la valeur de la séquence sera désynchronisées avec le contenu dans la table.
Imaginons qu'Oracle sauve dans son dump la valeur de la séquence 50, qu'on fasse un insert (valeur 51), et qu'ensuite il sauvegarde la table avec la valeur de id_test 51. Lorsque l'on remonte le dump, et que l'on refait un insert, il va ressortir de la séquence la valeur 51. Mais comme cette valeur est déjà dans la table, il va nous sortir une exception pour PK violée. Et paf la base.
Et encore, je ne parle pas des probables incohérences dans les données entre les tables.
Sinon ça me semble bizarre, la probabilité d'avoir des sequences incoherentes avec les données me semblent énorme.
Ça m'est déjà arrivé. C'est pourquoi je remonte toujours avec un script les valeurs des séquences après avoir remonté un dump.
Maintenant, tous les problèmes soulevés ici doivent normalement être démerdables avec le rejeu du journal après remonté du dump RMAN.
"ici eat là" <ici_et_la@free.fr> écrit :
Arf c'est sur cette histoire de sequence? Les nouvelles valeurs de la
sequence ne se retrouve pas dans les archivelog que l'on sauvegarde à la fin
pour avoir un système cohérent?
Si. Imaginons une table t_test, avec une séquence s_test. La table
t_test contient une colonne id_test, qui est la PK de la table, et
dont la valeur est toujours le nextval de la séquence s_test. C-à-d
que les insert sont toujours de la forme :
insert into (t_test, ...) values (s_test.nextval, ...);
.
Oracle commence toujours par sauvegarder les séquences, et fait
ensuite les tables. Mais si on fait des inserts entre le moment où
Oracle sauve la séquence, et le moment où Oracle sauve la table, la
valeur de la séquence sera désynchronisées avec le contenu dans la
table.
Imaginons qu'Oracle sauve dans son dump la valeur de la séquence 50,
qu'on fasse un insert (valeur 51), et qu'ensuite il sauvegarde la
table avec la valeur de id_test 51. Lorsque l'on remonte le dump, et
que l'on refait un insert, il va ressortir de la séquence la valeur
51. Mais comme cette valeur est déjà dans la table, il va nous sortir
une exception pour PK violée. Et paf la base.
Et encore, je ne parle pas des probables incohérences dans les données
entre les tables.
Sinon ça me semble bizarre, la probabilité d'avoir des sequences
incoherentes avec les données me semblent énorme.
Ça m'est déjà arrivé. C'est pourquoi je remonte toujours avec un
script les valeurs des séquences après avoir remonté un dump.
Maintenant, tous les problèmes soulevés ici doivent normalement être
démerdables avec le rejeu du journal après remonté du dump RMAN.
Arf c'est sur cette histoire de sequence? Les nouvelles valeurs de la sequence ne se retrouve pas dans les archivelog que l'on sauvegarde à la fin pour avoir un système cohérent?
Si. Imaginons une table t_test, avec une séquence s_test. La table t_test contient une colonne id_test, qui est la PK de la table, et dont la valeur est toujours le nextval de la séquence s_test. C-à-d que les insert sont toujours de la forme : insert into (t_test, ...) values (s_test.nextval, ...); .
Oracle commence toujours par sauvegarder les séquences, et fait ensuite les tables. Mais si on fait des inserts entre le moment où Oracle sauve la séquence, et le moment où Oracle sauve la table, la valeur de la séquence sera désynchronisées avec le contenu dans la table.
Imaginons qu'Oracle sauve dans son dump la valeur de la séquence 50, qu'on fasse un insert (valeur 51), et qu'ensuite il sauvegarde la table avec la valeur de id_test 51. Lorsque l'on remonte le dump, et que l'on refait un insert, il va ressortir de la séquence la valeur 51. Mais comme cette valeur est déjà dans la table, il va nous sortir une exception pour PK violée. Et paf la base.
Et encore, je ne parle pas des probables incohérences dans les données entre les tables.
Sinon ça me semble bizarre, la probabilité d'avoir des sequences incoherentes avec les données me semblent énorme.
Ça m'est déjà arrivé. C'est pourquoi je remonte toujours avec un script les valeurs des séquences après avoir remonté un dump.
Maintenant, tous les problèmes soulevés ici doivent normalement être démerdables avec le rejeu du journal après remonté du dump RMAN.
see
Che Averell wrote:
Maintenant, tous les problèmes soulevés ici doivent normalement être démerdables avec le rejeu du journal après remonté du dump RMAN.
Je ne vois pas comment on peut remonter une sauvegarde RMAN à chaud sans rejouer les archivelogs ?
-- Bruno http://errance.lirano.net (photographies)
Che Averell <averell@dalton-brothers.org> wrote:
Maintenant, tous les problèmes soulevés ici doivent normalement être
démerdables avec le rejeu du journal après remonté du dump RMAN.
Je ne vois pas comment on peut remonter une sauvegarde RMAN à chaud sans
rejouer les archivelogs ?
--
Bruno
http://errance.lirano.net (photographies)
