Comment faire pour que l'instance Oracle ne locke pas le file system ?

Bonjour a tous.

J'administre plusieurs databases Oracle 11g et le reload de ces databases s'effectue a l'aide de snapshots (au sens lvm du terme, auparavant nous utilisions les snapshots Veritas) afin d'economiser de l'espace disque.
J'explique en detail le reload:
- Sun une instance reference, nous avons un shema complet avec ses tablespaces et ses datafiles.
- Nous lancons un Datapump export sur ce shema en ne creant que les metadatas.
- Sun une autre instance, nous lancons un Datadump import a l'aide des metadatas creees, creons un lvm snapshot du file system contenant les datafiles (duplication virtuelle du FS) du shema complet et "rattachons" les datafiles aux tablespaces par un jeu de liens symboliques.
Tout fonctionne tres bien.
Mon probleme arrive au reload suivant, qui consiste a tout supprimer a l'aide d'un script shell : droper les foreign keys, contraintes et index, puis les tablespaces, supprimer le snapshot afin de pouvoir lancer un autre reload en utilisant un nouveau shema complet.
Quand arrive le moment de supprimer l'ancien snapshot, certains process oracle y sont encore attaches, il y a des sessions d'utilisateurs que je tue, mais il y a aussi, et ca a l'air de dependre de l'activite recente de la base, des process internes a oracle : DB writer, LOG Writer et autres ...
J'ai bien essaye le flush de la SGA, histoire qu'oracle ecrive tout ce qui devait etre ecrit, mais le DB Writer est toujours la, et si ce n'est pas lui, c'est le LOGW...
Mon probleme est avec les snapshots, mais je pense qu'il serait le meme avec un file system "normal" que je devrais pouvoir demonter.
Auriez-vous des propositions a me faire afin que mon snapshot soit libre de tout acces/locks afin qu'il puisse etre demonte dans probleme.
J'ai bien pense arreter et redemarrer la base, mais ca reste pour moi la solution ultime si il n'y a pas moins violent.
Je tiens a preciser que le snapshot ne contient que les datafiles des datas/index, tout ce qui est control files, logs and co se trouvent dans une autre file system, qui ne bouge pas au moment du reload.

D'avance merci
DD

Bonjour,
En mettant les tablespace offline, les fichiers devraient sont fermés.
Cordialement,
Franck.

Hello Franck,

D'abord, merci de ta reponse, mais comme je le disais, apres avoir drope les foreign keys, contraintes et index, je drop egalement les tablespaces apres les avoir passes offline donc ils ne sont plus la.
Par contre, je les drop including contents and datafiles ...
Peut-etre que si je les drop en laissant les datafiles, je reduis les chances d'acceder au snapshot et donc de le locker.
Apres tout, ca ne sert pas a grand chose de virer les datafiles, puisque de toutes facons je degage sans finesse tout le snapshot qui les contient ...

Par contre, j'ai bien l'impression qu'un shutdown/startup de l'instance me libere de tout ces locks ... Qu'est-ce que pourrais bien faire le shutdown de plus que ce que je fais deja ??

Cordialement.
DD

Citation:

---

Qu'est-ce que pourrais bien faire le shutdown de plus que ce que je fais deja ??

---

Tuer tous les process. Donc plus de handle ouvert.

Tu peux vérifier les process qui on un fichier ouvert, avec fuser ou lsof.

Mais c'est vrai que l'inconvénient du 'including datafiles' c'est qu'après il n'y a plus l'entrée dans le directory, donc plus possible de vérifier.

Donc l'idée serait de mettre les tablespace offline, puis killer les process qui ont toujours un fichier ouvert, puis drop tablespace.

Cordialement,
Franck.

Justement, quand je fais le fuser, c'est la que je prends peur en voyany tous les process Oracle qui y sont attaches:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

oracle@a237 /disk=> fuser -cv data02_FUNC3 USER PID ACCESS COMMAND data02_FUNC3: root kernel mount /mnt/nfs/disk/data02_FUNC3 oracle 3979 F.... oracle oracle 3981 F.... oracle oracle 3983 F.... oracle oracle 3985 F.... oracle oracle 7342 F.... oracle oracle@a237 /disk=> ps -edf | grep 3979 3016 3979 1 0 16:24 ? 00:00:05 ora_dbw0_dbfunc3 oracle@a237 /disk=> ps -edf | grep 3981 3016 3981 1 1 16:24 ? 00:00:06 ora_lgwr_dbfunc3 oracle@a237 /disk=> ps -edf | grep 3983 3016 3983 1 0 16:24 ? 00:00:00 ora_ckpt_dbfunc3 oracle@a237 /disk=> ps -edf | grep 3985 3016 3985 1 0 16:24 ? 00:00:00 ora_smon_dbfunc3 oracle@a237 /disk=> ps -edf | grep 7342 3016 7342 7341 89 16:32 ? 00:03:42 oracledbfunc3 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

---

Quand je vois ca, il me vient plusieurs questions:
- que fait le log writer attache a ce snapshot? ce snapshot est cense ne contenir que les datas de la base, tout ce qui est control et management se trouve sur un autre filesystem qui n'est pas physiquement touche par le reload...
- meme question avec smon et ckpt

Si je commence a sortir l'artillerie et killer les lgwr, dbwr et autres processes attaches, ca ne risque pas de mettre mon instance a mal? Par ce qu'il ne faudrait pas qu'elle soit dans un etat second et ne fasse pas tout ce qu'elle a a faire quand je vais creer les nouveaux tablespace et importer le contenu de mon nouveau snapshot dedans ...
Et si je kille ces process, Oracle ne va pas s'en apercevoir et m'en relancer un dans la foulee?

Cordialement.
DD

Citation:

---

que fait le log writer attache a ce snapshot?

---

Je pense que tous les process background ont un handle sur tous les datafiles.
C'est vrai que je ne vois pas ce que fait logwriter sur un datafile.
Par contre, smon oui (il est amené à faire du ménage dans les tablespaces) et ckpt aussi (mise à jour des headers des datafiles).

Par contre, les background process ne devraient plus avoir le fichier ouvert si le datafile est passé offline. C'est pour ça que je proposais un kill: seulement des process de sessions. Il ne faut pas killer les process background (ora_xxx_sid) sinon autant faire un shutdown.

Est-ce que dans le résultat du fuser le datafile était offline ?

Bonjour,

Je n'ai rien compris à votre manip.

De plus, cela me paraît excessivement dangereux de killer des process.

Pour moi, une base de données Oracle est un ensemble de fichiers (datafiles, tempfiles, redo logs files, archive log files et control files) qui forme un tout cohérent.

Lorsque l'on arrête une base Oracle, ces fichiers sont cohérents, et contiennent dans leurs entêtes des SCN gérés par Oracle.

Au démarrage d'une base, si ces SCN diffèrent, alors la base ne s'ouvre pas.

Le pire dans votre message, c'est que vous précisez bien que les snapshots ne contiennent que les données / index, et que le reste (control file, tablespaces SYSTEM et temporaire, redo log) sont dans un autre file System qui selon vous ne bouge pas.

Ce n'est pas vrai : même si il n'y a pas d'activités SQL sur la base en provenance des utilisateurs ou de batchs, une base Oracle vit, notamment avec ses checkpoints et autres tâches automatisées.

Pour moi, si l'on effectue un Snapshot d'une base Oracle, alors ce Snapshot contient toute la base.

De plus, ce Snapshot se fait base fermée.

Ou alors, si la base est ouverte, c'est comme une sauvegarde à chaud (comme on le faisait avait qu'il n'y ait RMAN), à savoir :
- la base est en mode Archivelog
- les tablespaces sont en mode Begin Backup.

@rouardg

Bonjour,

Ce que j'ai compris dans le premier message, c'est qu'ils rafraîchissent certains tablespaces par Transportable Tablespaces. Les metadata sont amenées par DataPump, les datafiles par des snapshots de filesystem.

Leur seul soucis, c'est que même lorsque le tablespace est offline et droppé (pas de pb de cohérence à ça) il reste des process qui gardent un handle sur les fichiers ce qui empêche de démonter le filesystem.

Cordialement,
Franck.

Citation:

---

C'est vrai que je ne vois pas ce que fait logwriter sur un datafile.

---

Les transactions ne reposent pas uniquement sur les redo
si le redo est de 2 MB et vous faites 10MB de modifs où vont les 8 MB ?
les datafiles contiennent des transactions non commitées

vous pouvez créer une table supérieure à la taille de la SGA et faire un update de tous les rows, oracle ne vous bloquera pas

pour revenir au post original je trouve la manip très risquée ..
c'est comme si vous faites une copie à froid
moi je ferais shutdown

Citation:

---

Envoyé par Oratorio

les datafiles contiennent des transactions non commitées

---

Bien sûr mais logwriter n'a rien à voir là dedans. Les datafiles sont écrits par dbwriter.

Citation:

---

Envoyé par pachot

Bien sûr mais logwriter n'a rien à voir là dedans. Les datafiles sont écrits par dbwriter.

---

la fonction officielle de dbwriter est de flusher les dirty blocks des redo et les écrire dans les datafiles pour libérer l'espace
alors je me demande si cette tâche est dans ses cordes car pas documentée

j'ai pensé que le logwriter lui-même qui s'en charge quand il n'y a pas d'espace dans les logs

de toute façon il n'y a que lui qui peut libérer le lock sur les blocks non commités dans les datafiles (ou l'inverse dans le cas de rollback)

Citation:

---

Envoyé par Oratorio

la fonction officielle de dbwriter est de flusher les dirty blocks des redo et les écrire dans les datafiles pour libérer l'espace
alors je me demande si cette tâche est dans ses cordes car pas documentée

j'ai pensé que le logwriter lui-même qui s'en charge quand il n'y a pas d'espace dans les logs

---

Ce que vous dites est proche de l'incompréhensible.
Pitié, relisez-vous lentement, ajoutez les majuscules, les points, les mots qui manquent, et passez tout ça en français.
"flusher les dirty blocks des redo" est un exemple de franglais spécialement immonde, en plus d'être faux.