Ca de obicei, de obicei, o interogare lentă care nu întoarce rânduri este încetinită încet: (:
În același timp, interogarea este executată încet la diferite instanțe în moduri diferite, pe prima:
Cu un plan de execuție la fel de frumos:
Statisticile de execuție din cea de-a doua instanță arată direct motivul citirilor multiple ale blocului de index și, prin urmare, executarea lentă a interogării:
- și într-adevăr, în revizuirile gv $ session și gv $ este ușor să găsești 4 tranzacții pe mai multe ore lansate pe instanța a doua și schimbând activ blocurile tabelului și indexul corespunzător
Cum Oracle restaurează versiunea de grăsime a blocului de date, modificată în mod repetat tranzacția deschisă (așa cum este reflectată de blocuri de date statistici coerente citește - undo înregistrările aplicate) descrise perfect Dzh.Lyuisom:
Este interesant faptul că statisticile și așteptările primelor instanțe pentru executarea lentă de mai sus pot părea fie neadecvate (în sensul că nu este permisă determinarea motivului pentru performanța scăzută a interogării):
sau indicați ca motiv pentru încetinirea așteptării pentru blocul CC cr ocupat:
legate în mod oficial de evenimentele de așteptare legate de contenție. care, de asemenea, nu este complet clară indică sursa problemei
În mod alternativ, evenimentul ocupat de gc cr bloc, în plus față de problemele de concurență, afișează întârzierile de fuziune cache. Recuperarea versiunii CR a blocului pe o instanță la distanță
Apropo, în cele de mai sus 4 LP tranzacțiile pe două Instance efectua aceste cereri pentru același motiv în timp incetineste judecând în mod semnificativ de Tracy, tkprof tratate:
- din 332/9570
35 ms în medie, în prima parte a unui proces de tranzacție / afacere lung
63 ms sau mai mult în viitor
Același comportament, dacă se dorește, poate fi observat pe traseul brut de cuvântul cheie FETCH - Acesta este modul în care versiunea CR a blocului index se reflectă în urmă:
- la începutul uneia dintre lungi tranzacții simultane pe FETCH sql_id = 2kdudjnay024c să-și petreacă nu mai mult de 98 ms (maxim e = 97709 microsecunde):
- în timp, ca urmare a acumulării de înregistrări necondiționate - limita superioară a duratei de execuție (de fapt, durata FETCH) a crescut la aproape 500 ms (e = 479399):
În execuția necompetitivă, o singură tranzacție pe termen lung este efectuată semnificativ mai rapid datorită unui timp de execuție mai scurt (din nou aproape echivalentul timpului FETCH) al acestor interogări mici - nu mai mult de 14 ms:
- în absența tranzacțiilor concurente care modifică în mod repetat aceleași blocuri, nu sunt necesare anularea înregistrărilor aplicate
Trimiteți-le prietenilor: