sayso Geschrieben 25. November 2006 Teilen Geschrieben 25. November 2006 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Jasper Geschrieben 25. November 2006 Teilen Geschrieben 25. November 2006 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
sayso Geschrieben 26. November 2006 Autor Teilen Geschrieben 26. November 2006 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Jasper Geschrieben 26. November 2006 Teilen Geschrieben 26. November 2006 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
sayso Geschrieben 26. November 2006 Autor Teilen Geschrieben 26. November 2006 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.... Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.