Instrumente de diagnosticare și utilitare de depanare în oracol - totul despre el și programare

CUPRINS

Fișiere Oracle Trace

Principalul este fișierul de alertă alertă (alert.log), care conține cele mai importante informații despre funcționarea bazei de date, în timpul diagnosticării ar trebui verificat mai întâi.

La începutul operării bazei de date, toți parametrii fișierului init.ora și mesajele despre începerea proceselor de fundal sunt introduse în alertă.log. De asemenea, înregistrează fluxul utilizat de acest exemplu și numărul de serie al jurnalului în care scrie procesul LGWR.

În general, informațiile despre baza de date pornesc și se opresc, crearea de spații de tabelă și segmente de rollback, precum și unele operațiuni de modificare sunt, de asemenea, introduse. comutatoare de jurnal și mesaje de eroare.

În plus față de alert.log, Oracle generează automat două fișiere de urmărire. Unul dintre ele este un fișier de urmărire de fond, este creat de procesele de fundal DBWR și LGWR. Aceste fișiere de urmărire nu pot fi create la pornirea sistemului, în funcție de disponibilitatea informațiilor pentru scriere.

Un fișier de urmărire al celui de-al doilea tip este creat de conexiunea unui utilizator la baza de date și se numește un fișier de urmărire personalizat.

Un astfel de fișier apare numai dacă sesiunea utilizatorului întâlnește o eroare.

Numele de fișiere de urmărire sunt de format standard și depind de sistemul de operare utilizat. Într-un mediu UNIX, fundal fișier de urmărire arată ORA_PID_PROCESS.trc, și fișierul utilizator - PROCESS_ID.trc. În acest caz, ORA_PID reprezintă identificatorul procesului Oracle, iar PROCESS_ID reprezintă procesul de sistem care a creat fișierul de urmărire.

Pentru depanare, sunt suportate diferite instrumente de diagnosticare. Pentru a încărca informațiile de diagnosticare în fișierele de urmărire, puteți conecta anumite evenimente. Pentru a diagnostica corupția discului și a memoriei, sunt utilizate câteva setări speciale. Acești parametri nu sunt specificați în timpul funcționării normale a bazei de date. ei își reduc productivitatea.

Setarea evenimentelor Trace

Iată câteva modalități de specificare a evenimentelor urmărite:

-descărcați starea sistemului pentru a diagnostica problemele de suspendare

-eroare de descărcare și stivă de proces (de exemplu, eroare ORA-00604)

Când specificați evenimentele utilizând init.ora, se utilizează următoarele rânduri:

EVENIMENT = „NUME ERRORSTACK 604 TRACE FOREVER“ - descărcat o eroare stivă de fiecare dată când procesul întâlnește o eroare ORA-00604;

EVENT = "10210 TRACE NAME CONTEXT FOREVER, LEVEL 10" - controlează integritatea fiecărui bloc atunci când citește de pe disc în cache.

Cele mai comune coduri de evenimente sunt:

10013 și 10015 - sunt folosite pentru a diagnostica problemele asociate cu deteriorarea segmentelor rollback.

event = "10015 urmăriți numele contextului pentru totdeauna"

10029 și 10030 - informații despre sesiunile de începere și de stop.

10210 și 10211 - blocurile de date citite în SGA

event = "10210 trace context name forever, level 10"

10231 și 10232 - săriți blocurile deteriorate în timpul scanării tabelului și încărcați-le în fișierul de urmărire

modificați evenimentele de setare a sesiunii "10231 contextul urmăririi denumirii";

event = "10231 urmăriți numele contextului pentru totdeauna, nivelul 10"

Prima declarație dezactivează verificarea blocului pentru această sesiune. Al doilea presupune verificarea tuturor blocurilor de baze de date citite de orice proces din zona SGA.

Analiza log cu LogMiner

Fișierele arhivate de redo log sunt foarte importante, în special pentru recuperarea bazei de date. Pentru a citi modificările efectuate în baza de date care sunt conținute în fișierul de arhivă al jurnalului de reîncercare, trebuie să deschideți fișierul specificat și să examinați conținutul acestuia.

Pentru aceasta, există un instrument special numit LogMiner.

Pentru a lucra cu acest instrument, aveți nevoie de:

1. Instalați utl_file_dir în init.ora

2. Rulați $ ORACLE_HOME / rdbms / admin / dbmslogmnrd.sql

3. SQL> EXECUTE dbms_logmnr_d.build ('dictionary.ora', '„);

4. SQL> EXECUTE DBMS_LOGMNR.ADD_LOGFILE (numefișierjurnal => '/oradata/test/arc/test454.arc', Options => dbms_logmnr.NEW);

pentru fiecare fișier jurnal pe care îl adăugați la listă, ștergeți

5. Executați DBMS_LOGMNR.START_LOGMNR (DictFileName =>

6. selectați scn, log_id, username, sql_redo, sql_undo din v $ logmnr_contents unde username = 'SCOTT';

lista tuturor modificărilor efectuate de utilizatorul SCOTT

7. SQL> EXEC DBMS_LOGMNR.END_LOGMNR;

Căutarea și repararea blocurilor de date corupte utilizând modulul DBMS_REPAIR

Pentru a elimina daunele în blocuri, tabele și indexuri, Oracle oferă instrumentul DBMS_REPAIR.

Acest modul vă permite:

- defectați ușor blocurile pentru a arăta că acestea sunt deteriorate;

- sări peste blocurile deteriorate în timpul scanării complete a tabelului sau indexului;

- indici de serviciu care nu sunt necesare, care indică blocuri de date corupte;

- reconstrui listele de memorie liberă pentru tabela sau indexul specificat.

Crearea tabelelor de administrare DBMS_REPAIR

1. sqlplus "/ ca sysdba"

2. Creați (dacă doriți) un spațiu de tabelă.

3. SQL> EXEC DBMS_REPAIR.ADMIN_TABLES ("REPAIR_ADMIN", 1, 1, "REPAIR_TS");

SQL> EXEC DBMS_REPAIR.ADMIN_TABLES ("ORPHAN_ADMIN" .2, 1, "REPAIR_TS");

Dacă doriți să ștergeți tabelul:

SQL> DBMS_REPAIR.ADMIN_TABLES EXEC ( 'ORPHAN_ADMIN' 2, 3, NULL.);

Pentru a șterge o tabelă (ștergerea tuturor rândurilor):

SQL> DBMS_REPAIR.ADMIN_TABLES EXEC ( 'ORPHAN_ADMIN' 2, 2, NULL.);

Scanarea unui anumit tabel sau index utilizând procedura DBMS_REPAIR.CHECK_OBJE

Vom verifica dacă există defecțiuni în tabela de date a schemei de produs. Să presupunem că tabela repair_admin a fost creată în schema sys.

1. sqlplus "/ ca sysdba"

SQL> NUMĂR VARIABIL;

2. SQL> EXEC DBMS_REPAIR.CHECK_OBJECT ("PROD", "DATA", NULL, 1,

'REPAIR_ADMIN'. NULL, NULL, NULL, NULL. A);

4. SELECTAREA RELATIVE_FILE_ID FILE,

MARKED_CORRUPT MARKED FROM REPAIR_ADMIN;

Corecția blocurilor deteriorate utilizând procedura DBMS_REPAIR.FIX_CORRUPT_BLOCKS

1. NUMĂR VARIABIL;

2. DBMS_REPAIR.FIX_CORRUPT_BLOCKS EXEC ( 'PROD', 'DATA', NULL, 1, 'REPAIR_ADMIN', A. NULL);

3. Verificați dacă elementele de bloc sunt etichetate ca deteriorate ale software-ului:

SELECT RELATIVE_FILE_ID FILE,

MARKED_CORRUPT MARKED FROM REPAIR_ADMIN;

Omiterea blocurilor deteriorate folosind procedura DBMS_REPAIR.SKIP_CORRUPT_BLOCKS

EXEC DBMS_REPAIR.SKIP_CORRUPT_BLOCKS ("PROD", "DATE", 1,1);

EXEC DBMS_REPAIR.DUMP_ORPHAN_KEYS ( 'PROD', 'SNO_IDX', NULL, 2, 'REPAIR_ADMIN',

'ORPHAN_ADMIN', NULL. A);

SELECTĂȚI SCHEMA_NAME, INDEX_NAME, INDEX_ID, TABLE_NAME, KEYROWID, KEY,

DUMP_TIME FROM ORPHAN_ADMIN;

Pentru a reconstrui lista de memorie liberă a tabelului DATA:

EXEC DBMS_REPAIR.REBUILD_FREELISTS ("PROD", "DATE", NULL, 1);

Instrumentul oradebug oferă acces la structurile de memorie Oracle, la stack-uri și așa mai departe. Folosindu-l, puteți genera o descărcare a stării procesului, precum și a descărca structurile zonei SGA. În plus, pentru un proces care rulează deja, puteți activa un eveniment.

Procesul de manager este atașat procesului Oracle sub numărul Unix 9431.

exemplu de ieșire: Oracle pid: 12, proces unix pid: 9431, imagine: oraclevk803

dimensiunea fișierului de urmărire este setată la nelimitat

declanșează un eveniment de urmărire SQL

resetați informațiile de urmărire pe disc nu se poate face pentru procesele de fundal - poate opri baza de date

Trebuie înțeles că fragmentarea tabelelor este diferită de fragmentarea fișierului. Atunci când o serie de operații DML sunt efectuate pe o masă, tabela este fragmentată deoarece DML nu eliberează spațiu pentru HWM.HWM este indicatorul de utilizare a blocului (BLOCURI UTILIZATE) din baza de date. Blocurile merg înainte.

Redenumirea implicit Permanent Tablespace prostranstvaTablichnoe spațiu tabelă SYSAUX TABLESPACE compozit TempDefault Permanent TablespaceOracle 9i a introdus conceptul unui spațiu de tabelă temporar în mod implicit (implicit TABLESPACE temporară), pentru a preveni accidentale.

ALTER nume_tabelă TABLE numai pentru citire; ALTER TABLE nume_tabelă Citire; Următorul script creează un tabel, populează cu câteva rânduri, apoi modul de masă ustanavilivaet "read-only" ro_tab TABLE .CREATE (ID NUMBER); INSERT INTO VALORI ro_tab (1); INSERT INTO VALORI ro_tab (2).

Procedura de creare este practic la fel ca versiunile anterioare - 9i și 10g. În baza de date vom crea următoarele opțiuni: OMF (Oracle Managed File) pentru fișiere de date, redo-log și fișiere de control. FRA (zona de recuperare flash) pentru arbori sau tăieturi de arhivă.

Nerespectarea faptului că toate modificările planului vor fi întotdeauna cele mai bune, au determinat anumiți clienți să își consolideze planurile de execuție (planurile stocate) sau să blocheze statisticile optimizatorului. Cu toate acestea, dacă acționăm în acest fel, ne lipsim de posibilitatea de ao folosi vreodată.