Hallo Kollegen,

ich stehe hier vor 2 Problemen und würde gerne wissen ob man das irgendwie über Oraclemittel lösen kann...

1) Die Dirty Blocks aus dem Buffer Cache werden ja in die Datenfiles geschrieben, wenn ein Checkpoint erfolgt. (z.B. Füllgrad der Redlogs, etc..) Kann man irgendwie auch ein zeitliches Intervall vorgeben? D.h. ich möchte das z.B. alle 3 Sekunden die Dirty Blocks in die Datenfiles geschrieben werden. (ohne einen Redologswitch, etc. zu tun)

2) Kann man mit Oracle 9i irgendwie eine Lock(Enqueue) History anzeigen lassen? Denn in v$lock sehe ich ja nur die aktuellen. Problem ist, das eine Anwendung einen Exclusive Lock auf Tabellenebene setzt und somit die Anwendung zum Stillstand bringt. Bis ich mich allerdings angemeldet habe, und geschaut habe ist der Lock wieder weg. Dies tritt auch nur relativ sporadisch auf. Mit dem STATSPACK und Tracelevel 0 gibt es ja ne Möglichkeit die Enqueues über einen Zeitraum anzeigen zu lassen, aber beinhaltet diese Statistik auch den User, OS-Process ID, etc.. oder nur die Dauer?

Würdet mir wirklich helfen

Danke

1) Die Dirty Blocks aus dem Buffer Cache werden ja in die Datenfiles geschrieben, wenn ein Checkpoint erfolgt. (z.B. Füllgrad der Redlogs, etc..) Kann man irgendwie auch ein zeitliches Intervall vorgeben? D.h. ich möchte das z.B. alle 3 Sekunden die Dirty Blocks in die Datenfiles geschrieben werden. (ohne einen Redologswitch, etc. zu tun)

nun, ja, wenn du das unbedingt willst: init-parameter log_checkpoint_timeout / log_checkpoint_interval

2) Kann man mit Oracle 9i irgendwie eine Lock(Enqueue) History anzeigen lassen? Denn in v$lock sehe ich ja nur die aktuellen. Problem ist, das eine Anwendung einen Exclusive Lock auf Tabellenebene setzt und somit die Anwendung zum Stillstand bringt. Bis ich mich allerdings angemeldet habe, und geschaut habe ist der Lock wieder weg. Dies tritt auch nur relativ sporadisch auf. Mit dem STATSPACK und Tracelevel 0 gibt es ja ne Möglichkeit die Enqueues über einen Zeitraum anzeigen zu lassen, aber beinhaltet diese Statistik auch den User, OS-Process ID, etc.. oder nur die Dauer?

eine history an sich kenne ich nicht. macht auch keinen sinn, da locks sehr häufig gesetzt werden.

entweder mit 'alter table x disable table lock' locking verbieten und warten bis die applikation einen fehler meldet oder mit logminer die redologs durchforsten.

-j

Hallo Jasper,

erstmal vielen Dank!

nun, ja, wenn du das unbedingt willst: init-parameter log_checkpoint_timeout / log_checkpoint_interval

Dann werde ich es über FAST_START_MTTR_TARGET lösen. Danke!

eine history an sich kenne ich nicht. macht auch keinen sinn, da locks sehr häufig gesetzt werden.

entweder mit 'alter table x disable table lock' locking verbieten und warten bis die applikation einen fehler meldet oder mit logminer die redologs durchforsten.

Naja im meinen Fall macht es eben Sinn ;-)

Das mit dem Logminer hört sich vielversprechend an. Meine Frage hierzu.

Ich habe einen Datenbank A bei der dieser Fehler auftritt und eine Datenbank B auf der ich testen kann.

Kann ich den Logminer auf Datenbank B installieren und dort die Archivelogs von Datenbank A analysieren? Denn ich lese immer nur von Redologs, leider steht nie dabei ob online oder "offline". Wenn man damit die Archivelogs auch analysieren könnte (in anderen DBs) dann wäre das optimal.

Vielen Dank :uli

Kann ich den Logminer auf Datenbank B installieren und dort die Archivelogs von Datenbank A analysieren? Denn ich lese immer nur von Redologs, leider steht nie dabei ob online oder "offline". Wenn man damit die Archivelogs auch analysieren könnte (in anderen DBs) dann wäre das optimal.

ja , das geht. es gibt ein paar vorraussetzungen wie gleiche version und gleiche hardwareplattform. am besten das dictionary als flat_file auf db a generieren und im logminer auf db b verwenden.

-j

ja , das geht. es gibt ein paar vorraussetzungen wie gleiche version und gleiche hardwareplattform. am besten das dictionary als flat_file auf db a generieren und im logminer auf db b verwenden.

-j

Hi Jasper,

alles klar.. Danke!

Ich werde es morgen gleich mal ausprobieren....