Da ich seit einigen Monaten wieder verstärkt mit RAC-Datenbanken (und überhaupt mit Oracle) zu tun habe, ist der folgende Hinweis von Jonathan Lewis für mich recht interessant: in einem RAC-System besitzt jede Instanz im Rahmen des ASSM-Speichermanagements ihren eigenen level 1 (L1) bitmap Block und schreibt neue Datensätze insofern auch in ihr zugeordnete Datenblöcke. Wenn konkurrierende Inserts über mehrere Instanzen hinweg erfolgen, landen die neusten Einträge daher in vielen unterschiedlichen Blocks, denn neben der Anzahl der Instanzen spielt dabei auch die Strategie von ASSM eine Rolle, Inserts auch in einer einzelnen Instanz auf 16 unterschiedliche Blocks zu verteilen. Der Clustering Factor eines Index würde unter diesen Umständen in nahezu jedem Fall extrem schlecht aussehen, wenn es nicht die Möglichkeit gäbe, mit Hilfe des Parameters table_cached_blocks dafür zu sorgen, dass Oracle ein gewisses Erinnerungsvermögen zeigt, wenn bestimmt wird, wie stark die Daten in der Tabelle im Hinblick auf einen Index geordnet sind. Ursprünglich wurde hier nur gezählt, wie oft sich die data block Adresse ändert, wenn man den sortiereten rowid-Verweisen der Index-Struktur folgt - was in Abwesenheit von RAC und ASSM immer noch eine plausible Strategie ist. Ausgehend von diesen Überlegungen schlägt der Herr Lewis als Ausgangswert für table_cached_blocks in einem RAC-System 16 * Anzahl Instanzen vor - und das ist angesichts dieser Überlegungen nachvollziehbar.
Keine Kommentare:
Kommentar veröffentlichen