Temat: Oracle Dictionary Cache Stats

Witam,

Mam dużą liczbę miss'ów dla parametru dc_files (ponad 88%):

Cache Get Requests Pct Miss Scan Reqs Pct Miss Mod Reqs Final Usage
dc_awr_control 60 0.00 0 2 1
dc_files 161 88.20 0 0 161
dc_global_oids 86,571 0.11 0 0 108
dc_histogram_data 83,238 0.85 0 0 6,640
dc_histogram_defs 80,470 2.02 0 0 7,781
dc_object_grants 10,803 0.81 0 0 28

Czy wie ktoś co to dokładnie oznacza, bo nigdzie nie ma opisów do tych parametrów. Dzięki

MR

Temat: Oracle Dictionary Cache Stats

Witam,
Wychodzi na to, że dc_files pojawia się w trakcie modyfikacji pliku danych - np. rozszerzania.

select  parameter, count, GETMISSES

from v$rowcache

where parameter='dc_files'







PARAMETER			      COUNT  GETMISSES

-------------------------------- ---------- ----------

dc_files				  1	     5



SQL> alter system flush shared_pool;



System altered.



SQL> alter database datafile 1 resize 325059590;



Database altered.



SQL> l

  1  select  parameter, count, GETMISSES

  2  from v$rowcache

  3* where parameter='dc_files'

SQL> /



PARAMETER			      COUNT  GETMISSES

-------------------------------- ---------- ----------

dc_files				  1	     6

Ja bym się w takim przypadku przyjrzał wielkości shared pool'a i definicjom plików danych - autoextend może odbywać się zdecydowanie za często.

Pozdrawiam,
Kamil.

Temat: Oracle Dictionary Cache Stats

Dzięki!

Teoretycznie wielkość shared_poola nie powinna być problemem przy włączonym AMM (oczywiście memory_target jest wystarczająco duże). Ale poleciłem ustawienie minimalnej wartośći dal shared poola. Przyjrzę się jeszcze plikom danych.

Temat: Oracle Dictionary Cache Stats

Marcin Romanowski:
Witam,

Mam dużą liczbę miss'ów dla parametru dc_files (ponad 88%):

To 88% nie ma znaczenia.
88.2% przy 161 requestach to 142 miss'y.
Dla porównania dc_histogram_defs 80470 requestów 2.02% pct miss daje to ~1625 miss'ów.

Zsumuj ilość miss'ów ze wszystkich kategorii związanych z dictionary cache i wyjdzie ci, że miss'y dla dc_files stanowią pewnie koło 1% całości.
Dopiero stosunek sumy miss'ów do sumy requestów da ci ratio, które będzie niosło ze sobą jakąś sensowną informację.

Jako, że z tymi miss'ami związane są odczyty z tabel systemowych to opóźnienia związane z pojedynczym miss'em dla wszystkich kategorii powinny być podobne. Czyli, nawet jeśli byś całkowicie wyeliminował miss'y w kategorii dc_files, to wpływ tego, na wydajność bazy, będzie najprawdopodobniej niezauważalny.

Czy wie ktoś co to dokładnie oznacza, bo nigdzie nie ma opisów do tych parametrów. Dzięki

Wnioskując z nazwy dc_files jest częścią dictionary cache, w której są przechowywane metadane dotyczące plików.

Pozdrawiam,
Sebastian

Temat: Oracle Dictionary Cache Stats

Sebastian Kolski:
Czyli, nawet jeśli byś całkowicie wyeliminował miss'y w kategorii dc_files, to wpływ tego, na wydajność bazy, będzie najprawdopodobniej niezauważalny.

Chyba, że statystyka wynika z ciągłego rozszerzania plików danych o np. 10m przy ładowaniu dużych paczek. Wtedy wyeliminowanie tego objawu będzie miało bardzo duże znaczenie wydajnościowe.

Pozdrawiam,
Kamil.

Temat: Oracle Dictionary Cache Stats

Kamil Stawiarski:

Sebastian Kolski:
Czyli, nawet jeśli byś całkowicie wyeliminował miss'y w kategorii dc_files, to wpływ tego, na wydajność bazy, będzie najprawdopodobniej niezauważalny.

Chyba, że statystyka wynika z ciągłego rozszerzania plików danych o np. 10m przy ładowaniu dużych paczek. Wtedy wyeliminowanie tego objawu będzie miało bardzo duże znaczenie wydajnościowe.

Mam wrażenie, że akurat rozszerzanie plików nie wpływa na statystyki dictionary cache dc_files.
Przy wykonywaniu operacji, które zmieniają metadane oracle aktualizuje to co siedzi w dc.
Wydaje mi się, że jedyny sposób aby pojawiły się miss'y przy dc_files to przy pierwszym ładowaniu danych o plikach do dc lub przy kolejnych jeśli dane zostały z niego usunięte na skutek długiego braku odwołań.
W przykładzie, który podawałeś wcześniej wzrost ilości miss'ów spowodowany był flushowaniem shared poola, a nie rozszerzaniem pliku.

Rozszerzanie plików powoduje powstawanie waitów data file init write. I to one były by objawem jeśli było by to problemem.

Przykład:

Database opened.

SQL> select  parameter, count, usage, gets, getmisses from v$rowcache where parameter='dc_files';



PARAMETER                             COUNT      USAGE       GETS  GETMISSES

-------------------------------- ---------- ---------- ---------- ----------

dc_files                                  0          0          0          0



SQL> select event, total_waits from v$system_event where event = 'Data file init write';



no rows selected



SQL> select file_name from dba_data_files;



FILE_NAME

--------------------------------------------------------------------------------

<ciach>



35 rows selected.



-- metadane o plikach siedzą teraz w dc



SQL> select  parameter, count, usage, gets, getmisses from v$rowcache where parameter='dc_files';



PARAMETER                             COUNT      USAGE       GETS  GETMISSES

-------------------------------- ---------- ---------- ---------- ----------

dc_files                                 35         35         35         35



-- tworzenie nowego pliku będzie nowy miss

SQL> create tablespace test datafile '/tmp/test.dbf' size 128k autoextend on next 8k;



Tablespace created.



SQL> select  parameter, count, usage, gets, getmisses from v$rowcache where parameter='dc_files';



PARAMETER                             COUNT      USAGE       GETS  GETMISSES

-------------------------------- ---------- ---------- ---------- ----------

dc_files                                 36         36         39         36



SQL> select bytes, blocks from dba_data_files where file_name = '/tmp/test.dbf';



     BYTES     BLOCKS

---------- ----------

    131072         16



-- generujemy wielokrotne rozszerzanie pliku - nie powoduje to powstania nowych miss'ów

-- za to pojawiają się wait'y data file init write



SQL> create table test tablespace test as select rownum n1, rpad('x',8000) padding 

  2  from all_objects where rownum < 100;



Table created.



SQL> select  parameter, count, usage, gets, getmisses from v$rowcache where parameter='dc_files';



PARAMETER                             COUNT      USAGE       GETS  GETMISSES

-------------------------------- ---------- ---------- ---------- ----------

dc_files                                 36         36         40         36



SQL> select bytes, blocks from dba_data_files where file_name = '/tmp/test.dbf';



     BYTES     BLOCKS

---------- ----------

    983040        120



SQL> select event, total_waits from v$system_event where event = 'Data file init write';



EVENT                                                            TOTAL_WAITS

---------------------------------------------------------------- -----------

Data file init write                                                      28

Pozdrawiam
Sebastian

Temat: Oracle Dictionary Cache Stats

Sebastian Kolski:
W przykładzie, który podawałeś wcześniej wzrost ilości miss'ów spowodowany był flushowaniem shared poola, a nie rozszerzaniem pliku.

>

Masz rację ale jeśli weźmiesz pod uwagę dużo rozszerzających się plików i dodasz do tego na tyle mały shared pool żeby informacje zdążyły wylecieć (lub na tyle dużo twardych parsowań, że library cache się rozpycha) to masz duże użycie na dc_files plus dużo miss'ów. Ostatnio w jednej zacnej instytucji miałem dosyć podobny problem, którego rozwiązanie zakończyło się zwykłą alokacją miejsca na plikach danych.

Pozdrawiam,
Kamil.