Performance Tuning · ASPICON Newsarchiv

DBA Tipp: Tablespacefreiplatz und Buffer Cache Hit Ratio erhöhen durch Defragmentierung von Tabellen

Thilo Solbrig, Oracle Certified Master — Wed, 04 Jun 2025 07:40:01 +0000

Home → Performance Tuning

DBA Tipp: Tablespacefreiplatz und Buffer Cache Hit Ratio erhöhen durch Defragmentierung von Tabellen

Verfasst von Thilo Solbrig, Oracle Certified Master
04 Juni 2025
09:40
Datenbank, DBA Tipp, Oracle, Performance Tuning, Praxistipp

Nach größeren Löschoperationen entstehen Lücken in Datenblöcken, die sich negativ auf Performance und Platzbelegung auswirken. Werden sie in der Tabelle nicht zeitnah durch neue Daten aufgefüllt, empfiehlt sich ein Online-Shrink der betroffenen Tabellen. Ein Ansatz zur Abschätzung stark fragmentierter Tabellen wird in diesem DBA-Tipp vorgestellt.

Warum überhaupt defragmentieren?

Das Löschen einer größeren Menge von Zeilen aus einer Tabelle führt in aller Regel dazu, dass die Datenblöcke der Tabelle stark fragmentiert werden. Das heißt es gibt dann also viele Blöcke, die nur wenige Daten enthalten. Diese Fragmentierung hat zwei wesentliche Nachteile:

Verschwendung von Speicherplatz, wenn die Lücken nicht im Laufe der Zeit wieder durch neue Zeilen gefüllt werden. Da der Freiplatz fest von einer bestimmten Tabelle allokiert ist, steht er auch keinen anderen Objekten in der Datenbank zur Verfügung.
Auch wenn der Platz nach und nach wiederverwendet wird, wirkt sich diese Fragmentierung bis dahin negativ auf die Performance aus. Der Buffer Cache der Datenbank, eine der wichtigsten Komponenten im Bezug auf Datenbankperformance, arbeitet rein blockbasiert. Folglich verschwenden Datenblöcke einer Tabelle Platz im Buffer Cache, wenn sie fragmentiert sind, da auch der leere Anteil im Block auf den Buffer Cache angerechnet wird. Die „Nutzdatenrate“ ist damit schlechter als bei unfragmentierten Blöcken, die Performance sinkt durch eine geringere Buffer Cache Hit Ratio.

Es kann also nach größeren Löschoperationen interessant sein, welche Tabellen mittels:

alter table … shrink space cascade;

geshrinkt werden können, um zum einen unbelegten Platz freizugeben und zum anderen die Buffer Cache Effizienz hoch zu halten. Dafür kannst du dir zwei Tabellenstatistiken zu Nutze machen – die Zeilenzahl und die durchschnittliche Zeilenlänge – und diese mit der tatsächlichen Platzbelegung in Bezug setzen. Es ist zu beachten, dass es sich dabei nicht um exakte Werte handelt. Wenn die Statistiken jedoch aktuell sind, stellen sie für diesen Zweck recht zuverlässige Schätzungen dar. Grundsätzlich kannst du davon ausgehen, dass Tabellen, in denen große Datenmengen gelöscht wurden, auch vom nächtlichen Autotask „auto optimizer stats collection“ erkannt und analysiert wurden. Andernfalls rechnest du mit geeigneten Prozeduren des dbms_stats-Package die Statistiken einfach selbst neu.

Vergleich erwarteter Platzbedarf und tatsächlich belegter Platz

Zur Abschätzung des Platzes, den wir durch das Shrinken voraussichtlich einsparen, stellen wir nun einen Vergleich zwischen dem erwarteten Platzbedarf (Zeilenzahl * durchschnittliche Zeilenlänge) und dem tatsächlich belegten Platz (Summe der Segmentgrößen) an:

WITH table_subset AS
( SELECT owner,table_name
FROM dba_tables
WHERE owner='SOE'
)
SELECT exp.owner,
exp.table_name,
ROUND((used_space-expected_space)/power(1024,2)) estimated_savings_mb,
used_space,
expected_space,
ROUND((1-expected_space/used_space)*100) estimated_savings_pct
FROM
(SELECT owner,
table_name,
num_rows*avg_row_len expected_space
FROM dba_tables t
WHERE (owner,table_name) IN
(SELECT * FROM table_subset s)
AND num_rows IS NOT NULL
AND avg_row_len IS NOT NULL
) exp,
(SELECT owner,
segment_name,
SUM(bytes) used_space
FROM dba_segments
WHERE (owner,segment_name) IN
(SELECT * FROM table_subset s)
GROUP BY owner,
segment_name
HAVING SUM(bytes)>0
) used
WHERE exp.owner =used.owner
AND exp.table_name=used.segment_name
ORDER BY estimated_savings_mb DESC

Wie wir sehen, hat in unserem Beispiel die Tabelle SOE.ORDER_ITEMS ein Einsparungspotenzial von ca. 1.1GB. Sie belegt aktuell 1.4 GB Platz, obwohl sie gemäß ihrer Statistiken nur 209 MB belegen müsste. Wir können sie also als einen geeigneten Kandidaten für eine Online-Shrink-Operation ansehen:

ALTER TABLE SOE.ORDER_ITEMS ENABLE ROW MOVEMENT;
ALTER TABLE SOE.ORDER_ITEMS SHRINK SPACE CASCADE;

Eine erneute Auswertung zeigt, dass die Tabelle, wie erwartet, ihren ungenutzten Platz freigegeben hat. Im Tablespace stehen nun 1.1GB mehr Platz zur freien Verfügung.

Am Beginn des SELECT-Statements findest du die Inline-View

WITH table_subset AS
( SELECT owner,table_name
FROM dba_tables
WHERE owner='SOE'
)

Hierüber kannst du einstellen, welche Tabellen in die Betrachtung einbezogen werden sollen. Wir beschränken uns hier zum Beispiel auf das Schema SOE. Eine Auswertung über alle Tabellen einer Datenbank dürfte meist zu lange dauern und auch nur selten erforderlich sein. So ist zum Beispiel das Shrinken von SYS-Objekten ohnehin nicht empfohlen und in vielen Fällen auch nicht möglich.

Fazit

Größere Löschoperationen führen häufig zu Fragmentierung in Oracle-Tabellen – mit negativen Auswirkungen auf Speicherplatz und Performance. Der vorgestellte Ansatz ermöglicht es dir als DBA, stark fragmentierte Tabellen systematisch zu identifizieren und gezielt per Online-Shrink zu optimieren. So lassen sich ungenutzte Reserven im Tablespace freigeben und die Effizienz des Buffer Caches nachhaltig verbessern.

Hier findest du weitere Infos rund um Oracle aus unserem News & Insights Bereich.

Share this article

Der Beitrag DBA Tipp: Tablespacefreiplatz und Buffer Cache Hit Ratio erhöhen durch Defragmentierung von Tabellen erschien zuerst auf ASPICON.

DBA Tipp: Cursor-Sharing-Kandidaten in der Anwendung identifizieren

Thilo Solbrig, Oracle Certified Master — Fri, 07 Feb 2025 10:55:58 +0000

Home → Performance Tuning

DBA Tipp: Cursor-Sharing-Kandidaten in der Anwendung identifizieren

Verfasst von Thilo Solbrig, Oracle Certified Master
07 Februar 2025
11:55
Datenbank, DBA Tipp, Oracle, Performance Tuning, Praxistipp

Cursor Sharing hat zweifellos eine große Bedeutung für die Performance, insbesondere das Vermeiden des Hard Parsing. Auf den ersten Blick nicht offensichtlich, kann das Vorhalten vieler nicht-wiederverwendbarer Statements im Library Cache aber auch zur Verschwendung von Buffer Cache führen. Wie du Cursor-Sharing-Kandidaten in deiner Datenbank findest und welche zwei Möglichkeiten dir zur Optimierung zur Verfügung stehen, zeigt dieser DBA Tipp.

Cursor-Sharing datenbankweit erzwingen

Oracles Diagnosetools AWR und statspack speichern in ihren Repositories neben Ausführungsstatistiken auch Ausführungspläne ab. Diese werden regulär per INSERT-SELECT aus entsprechenden Data Dictionary-Views in die Repositories übertragen. Je mehr Statements sich im Shared Pool befinden, desto mehr SELECT-Statements werden ausgeführt und entsprechend Datenblöcke durch den Buffer Cache geschleust. Das verdrängt unter Umständen in großem Umfang Datenblöcke, die für die eigentliche Datenbankanwendung dort gepuffert waren und performancerelevant wären.

Zudem haben wir oft beobachtet, dass vergleichsweise große Shared Pools mit sehr vielen nicht-wiederverwendbaren Statements zu einer erhöhten Anzahl von „library cache: mutex X“ oder „library cache pin“ Wait-Events führen. Du kannst Cursor Sharing an der Anwendung vorbei datenbankweit mit dem Parameter CURSOR_SHARING=FORCE erzwingen. In diesem Fall ersetzt die Datenbank von sich aus Literale in SQL-Statements durch Bindevariablen.

Anpassung über Anwendungshersteller

Nicht alle Anwendungshersteller gestatten das jedoch. Zum Teil gibt es auch Ressentiments gegen diese Einstellung, die aus sogenannten bind peeking Problemen aus Versionen vor 11.2.0.4, herrühren. Hat man entsprechenden Zugang zum Support des Anwendungsentwicklers, kann es daher von Interesse sein, ihm die konkreten Statements mitzuteilen, die wegen Verzicht auf Bindevariablen den Library Cache besonders exzessiv verschwenden. Diese können dann in puncto Bindevariablen im Code angepasst werden.

Zu Demonstrationszwecken gehen wir von einem Szenario aus, in dem ein SELECT-Statement 10.000 Mal ausgeführt wird – jedes Mal mit einer anderen ID:

SELECT ADDRESS_ID, CUSTOMER_ID, DATE_CREATED, HOUSE_NO_OR_NAME, STREET_NAME, TOWN, COUNTY, COUNTRY, POST_CODE, ZIP_CODE FROM ADDRESSES WHERE CUSTOMER_ID = 1;
SELECT ADDRESS_ID, CUSTOMER_ID, DATE_CREATED, HOUSE_NO_OR_NAME, STREET_NAME, TOWN, COUNTY, COUNTRY, POST_CODE, ZIP_CODE FROM ADDRESSES WHERE CUSTOMER_ID = 2;
...
SELECT ADDRESS_ID, CUSTOMER_ID, DATE_CREATED, HOUSE_NO_OR_NAME, STREET_NAME, TOWN, COUNTY, COUNTRY, POST_CODE, ZIP_CODE FROM ADDRESSES WHERE CUSTOMER_ID = 9999;
SELECT ADDRESS_ID, CUSTOMER_ID, DATE_CREATED, HOUSE_NO_OR_NAME, STREET_NAME, TOWN, COUNTY, COUNTRY, POST_CODE, ZIP_CODE FROM ADDRESSES WHERE CUSTOMER_ID = 10000;

NAME                                                VALUE

---------------------------------------------- ----------
execute count                                       10351
parse count (describe)                                  0
parse count (failures)                                  0
parse count (hard)                                  10037
parse count (total)                                 10200
parse time cpu                                        677
parse time elapsed                                    648

Wiederverwendbare Statements erstellen

Wie unschwer zu erkennen ist, könnte dieses Statement durch Ersetzen des Literals für CUSTOMER_ID zu einem wiederverwendbaren Statement abgeändert werden. Statt 10.000 Hard Parses mit je einer Ausführung, wäre dann nur noch 1 Hard Parse erforderlich. Das geparste Statement könnte dann die nächsten 9999 Mal wiederverwendet werden und würde erheblich ressourcensparender arbeiten. Ob das über den Datenbankparameter CURSOR_SHARING=FORCE oder durch Änderung der Anwendung erfolgt, ist hierbei letztlich unerheblich.

SELECT ADDRESS_ID, CUSTOMER_ID, DATE_CREATED, HOUSE_NO_OR_NAME, STREET_NAME, TOWN, COUNTY, COUNTRY, POST_CODE, ZIP_CODE FROM ADDRESSES WHERE CUSTOMER_ID = :ID;

NAME                                                 VALUE
----------------------------------------------- ----------
execute count                                        10015
parse count (describe)                                   0
parse count (failures)                                   0
parse count (hard)                                      39
parse count (total)                                  10201
parse time cpu                                          81
parse time elapsed                                      67

Auffinden der Cursor-Sharing-Kandidaten

Zum Auffinden solcher „tunenswerter“ Statements in einer Datenbank bedient man sich der Data-Dictionary-View v$sql. Sie führt zu jedem gecachten Statement in der Spalte FORCE_MATCHING_SIGNATURE eine Signatur seines Äquivalents bei Verwendung von CURSOR_SHARING=FORCE mit. Die Anzahl der Einträge in v$sql mit jeweils gleicher Signatur ist also ein gutes Maß dafür, wie viele Ausprägungen eines Statements im Cache liegen, nur weil unterschiedliche Literale verwendet wurden.

In unserem Beispiel würde das Ergebnis aus der v$sql ohne Cursorsharing in etwa so aussehen:

select force_matching_signature,count(*) anzahl
from v$sql
group by force_matching_signature
order by 2;


FORCE_MATCHING_SIGNATURE 	ANZAHL
------------------------ ----------
 	1253587301725552198     2
 	7928100255923163774     2
	17867806445150202466    3
	10927028642624449365    3
 	5494157341192764346     3
	11682584117507924582    3
	17301900507670644855    3
	17274913944183326537    3
   	    	0    121
 	8094602905134864270  	10000

In unserem Testfall ist das unterste Statement mit der höchsten Ausprägung (10.000 Einträge mit der gleichen FORCE_MATCHING_SIGNATURE 8094602905134864270) vordergründig interessant. Mit einigen Samples könnten wir uns jetzt ein ungefähres Bild verschaffen, um welche Statements es sich handelt:

select sql_text from v$sql
where force_matching_signature=8094602905134864270
fetch first 5 rows only;


SQL_TEXT
----------------------------------------------------------------------------------------------------
SELECT ADDRESS_ID, CUSTOMER_ID, DATE_CREATED, HOUSE_NO_OR_NAME, STREET_NAME, TOWN, COUNTY, COUNTRY,
POST_CODE, ZIP_CODE FROM ADDRESSES WHERE CUSTOMER_ID =9933


SELECT ADDRESS_ID, CUSTOMER_ID, DATE_CREATED, HOUSE_NO_OR_NAME, STREET_NAME, TOWN, COUNTY, COUNTRY,
POST_CODE, ZIP_CODE FROM ADDRESSES WHERE CUSTOMER_ID =8082


SELECT ADDRESS_ID, CUSTOMER_ID, DATE_CREATED, HOUSE_NO_OR_NAME, STREET_NAME, TOWN, COUNTY, COUNTRY,
POST_CODE, ZIP_CODE FROM ADDRESSES WHERE CUSTOMER_ID =2080


SELECT ADDRESS_ID, CUSTOMER_ID, DATE_CREATED, HOUSE_NO_OR_NAME, STREET_NAME, TOWN, COUNTY, COUNTRY,
POST_CODE, ZIP_CODE FROM ADDRESSES WHERE CUSTOMER_ID =6237


SELECT ADDRESS_ID, CUSTOMER_ID, DATE_CREATED, HOUSE_NO_OR_NAME, STREET_NAME, TOWN, COUNTY, COUNTRY,
POST_CODE, ZIP_CODE FROM ADDRESSES WHERE CUSTOMER_ID =7514

Fazit

Statements, die Literale statt Bindvalues verwenden, können sich durch erhöhten Parseaufwand und Verschwendung von Library und auch Buffer Cache negativ auf die Performance auswirken. Ist eine globale Lösung durch Verwendung des Datenbankparameters CURSOR_SHARING=FORCE nicht möglich, können die potentiell problematischen Statements dynamisch ermittelt und so dem Anwendungshersteller für eine gezielte Anpassung mitgeteilt werden.

Hier findest du weitere Infos rund um Oracle aus unserem News & Insights Bereich.

Share this article

Der Beitrag DBA Tipp: Cursor-Sharing-Kandidaten in der Anwendung identifizieren erschien zuerst auf ASPICON.

Automatische SQL-Planverwaltung in Oracle Datenbanken

Jens Böttcher — Tue, 21 May 2024 09:00:39 +0000

Home → Performance Tuning

Automatische SQL-Planverwaltung in Oracle Datenbanken

Verfasst von Jens Böttcher
21 Mai 2024
11:00
Datenbank, Hidden Feature, Oracle, Oracle Database, Oracle Datenbank 12c /18c /19c /21c, Oracle Datenbank 23ai, Performance Tuning

Die automatische SQL-Planverwaltung steht seit kurzem für die Enterprise Edition der Oracle Database 23ai bereit. Eine weitere gute Nachricht ist, dass diese Änderung auch in Oracle Database 19c (ab 19.22) zurück portiert wurde und Oracle nicht abgeneigt ist, auf noch weitere Patch-Versionen zurückzugehen. (Quelle: https://blogs.oracle.com/optimizer/post/license-change-for-auto-spm)

Aber was ist eigentlich die SQL-Planverwaltung, wann brauchst du sie möglicherweise und was solltest du bei der Nutzung beachten? Lies weiter, dann erfährst du mehr.

Vorteile und Anwendungsfälle der automatischen SQL-Planverwaltung

Die automatische SQL-Planverwaltung (SPM) in Oracle Datenbanken ist ein intelligentes Feature, das die Leistung und Skalierbarkeit von Anwendungen durch Optimierung der Ausführungspläne für SQL-Abfragen verbessert. Du als Datenbankadministrator musst dich nicht mehr manuell um die Optimierung jedes einzelnen Plans kümmern, da die SPM diese Aufgabe proaktiv übernimmt und dafür sorgt, dass die Abfragen mit maximaler Effizienz ausgeführt werden.

Die Vorteile sind:

Verbesserte Performance
SPM kann die Ausführungszeit von Abfragen erheblich verkürzen, indem es suboptimale Pläne erkennt und optimierte Alternativen generiert. Dies führt zu einer spürbaren Steigerung der Anwendungsleistung und Reaktionszeiten, insbesondere bei komplexen Abfragen oder hohen Datenmengen.
Geringerer Administrationsaufwand
DBAs werden von der zeitraubenden manuellen Planoptimierung entlastet und können sich so auf wichtigere Aufgaben konzentrieren. SPM automatisiert die Planverwaltung und sorgt dafür, dass die Datenbank immer optimal läuft.
Skalierbarkeit
SPM passt sich automatisch an Änderungen in der Arbeitslast und den Datenstrukturen an. Dies gewährleistet, dass die Abfragen auch bei steigenden Anforderungen effizient ausgeführt werden und Engpässe vermieden werden.
Vereinfachte Fehlersuche
SPM protokolliert detaillierte Informationen zu den verwendeten Plänen und deren Leistung. Diese Daten können zur Analyse von Performanceproblemen und zur Identifizierung von Engpässen herangezogen werden.

Besonders hilfreich kann das Feature in Produktionsumgebungen mit hohen Anforderungen an die Performance und Skalierbarkeit, in Umgebungen mit komplexen Abfragen und großen Datenmengen sowie in Umgebungen mit häufigen Änderungen an der Anwendungslogik oder den Datenstrukturen sein.

Was du beachten solltest und wie du das Feature aktivieren kannst

Bei der Nutzung der automatischen SQL-Planverwaltung solltest du folgende Punkte beachten:

SPM ist kein Ersatz für eine gute Datenbankarchitektur und ein effizientes Datenmodell.
Die Aktivierung von SPM kann in einigen Fällen zu einem leichten Leistungsabfall führen, da die Optimierung der Pläne zusätzliche Ressourcen benötigt.
Bei komplexen Anwendungen kann es ratsam sein, SPM in Zusammenarbeit mit einem erfahrenen Oracle DBA zu implementieren und zu optimieren.

Um zu überprüfen, ob SPM aktiviert ist, kannst du folgendes Skript ausführen:

SQL> SELECT parameter_value spm_status FROM dba_sql_management_config WHERE parameter_name = 'AUTO_SPM_EVOLVE_TASK';
SPM_STATUS
----------
OFF

Aktivieren kannst du das Feature mit:

SQL> BEGIN
 DBMS_SPM.CONFIGURE('AUTO_SPM_EVOLVE_TASK','ON');
END;
/

Fazit

Die automatische SQL-Planverwaltung ist ein wertvolles Werkzeug für die Optimierung der Leistung und Skalierbarkeit von Oracle Datenbanken. Sie kann dich bei deiner Arbeit als Datenbankadministrator entlasten, die Performance deiner Systeme verbessern und die Stabilität von Anwendungen in komplexen Umgebungen gewährleisten.

Beachte jedoch, dass die Optimierung der Pläne zusätzliche Ressourcen benötigt. Solltest du Unterstützung benötigen, ruf uns gern an.

Hier findest du weitere Features und Infos aus der Welt von Oracle aus unserem News & Insights Bereich.

Share this article

Der Beitrag Automatische SQL-Planverwaltung in Oracle Datenbanken erschien zuerst auf ASPICON.

DBA Tipp: Frühjahrsputz im Index-Tablespace

Thilo Solbrig, Oracle Certified Master — Mon, 17 Apr 2023 06:03:00 +0000

Home → Performance Tuning

DBA Tipp: Frühjahrsputz im Index-Tablespace

Verfasst von Thilo Solbrig, Oracle Certified Master
17 April 2023
08:03
Datenbank, DBA Tipp, Oracle, Oracle Database, Performance Tuning, Praxistipp

Bei unserem internen “Frühjahrsputz” sind wir auf einen Beitrag von Oracle Certified Master Thilo aus dem Jahr 2020 zu genau diesem Thema gestoßen. Konkret geht es hier um den Frühjahrsputz im Index-Tablespace und warum es sich lohnt, diesen ab und zu mal aufzuräumen. Die Grundsätze und Queries treffen heute noch genauso zu wie damals, also Ärmel hochkrempeln und los geht’s!

Während Indizes grundsätzlich wichtig für eine performante Ausführung von DML und Queries sind, haben sie gleichzeitig auch Nachteile, denn:

Jeder Index verursacht durch den impliziten Pflegeaufwand Overhead bei DML-Operationen.
Jeder Index belegt wertvollen Platz in der Datenbank und im Backup.
Die Berechnung von Indexstatistiken verbraucht Zeit und verursacht Last in der Datenbank.

Ziel sollte es daher sein, nicht mehr Indizes vorzuhalten, als für eine performante Abwicklung der typischen Workload erforderlich sind.

Im Rahmen von Performanceuntersuchungen und Healthchecks unserer Kundensysteme treffen wir häufig auf Indizes, die vom Grundsatz her nicht erforderlich sind. Zwei häufige Fälle – und Queries zum Auffinden entsprechender „Kandidaten“ – werden in diesem DBA Tipp vorgestellt.

Fall 1 – vertauschte Spaltenreihenfolge

In Abbildung 1 siehst du die Indizes NDX_NAME_OWN_OBJECTS und NDX_OWN_NAME_OBJECTS, welche dieselben Spalten in unterschiedlicher Reihenfolge indizieren. Hintergrund einer derartigen Indizierung ist wahrscheinlich die falsche Annahme, damit sowohl für die Query

SELECT *
FROM scott_objects
WHERE object_name='EMP'
AND owner='SCOTT'

als auch für

SELECT *
FROM scott_objects
WHERE owner='SCOTT'
AND object_name='EMP'

jeweils auf einen Index zurückgreifen zu können. Tatsächlich reicht einer der beiden Indizes vollkommen aus. Der Optimizer tauscht bei Bedarf die beiden WHERE-Attribute aus, sodass er auch bei (vermeintlich) falscher Attributreihenfolge vom Index Gebrauch machen kann (Abbildung 2).

Den hier beschriebenen Fall einer Indizierung desselben Satzes von Spalten in unterschiedlicher Reihenfolge findest du über folgende Query heraus (hier eingeschränkt auf das Schema SCOTT):

WITH column_list AS
  ( SELECT DISTINCT index_owner, index_name,
    listagg(column_name,', ') within GROUP (
  ORDER BY column_name) over (partition BY index_name) cols
  FROM dba_ind_columns
  )
SELECT DISTINCT fst.index_owner,
  fst.index_name,
  snd.index_owner,
  snd.index_name,
  snd_cols.cols
FROM dba_ind_columns fst,
  dba_ind_columns snd,
  column_list fst_cols,
  column_list snd_cols
WHERE fst.table_owner  =snd.table_owner
AND fst.table_name     =snd.table_name
AND fst.index_owner    =fst_cols.index_owner
AND fst.index_name     =fst_cols.index_name
AND snd.index_owner    =snd_cols.index_owner
AND snd.index_name     =snd_cols.index_name
AND fst_cols.cols      =snd_cols.cols
AND fst.index_owner    ='SCOTT'
AND fst.index_name!    =snd.index_name

Fall 2 – Index als linksbündiges Spalten-Subset eines anderen Indexes

In der Regel sind auch Indizes unnötig, die ein linksbündiges Subset eines anderen Indexes sind.

In Abbildung 3 ist der Index NDX_OWN_NAME_OBJECTS ein linksbündiges Subset von NDX_OWN_NAME_STAT_OBJECTS, da er komplett und in identischer Reihenfolge seiner Spalten Bestandteil des Indexes NDX_OWN_NAME_STAT_OBJECTS ist (beides muss erfüllt sein). Grundsätzlich würde der Index NDX_OWN_NAME_OBJECTS zwar für die Query

SELECT *
FROM scott_objects
WHERE owner='SCOTT'
AND object_name='EMP'

gegenüber NDX_OWN_NAME_STAT_OBJECTS bevorzugt werden (Abbildung 4), da der Leseaufwand geringer ist (in NDX_OWN_NAME_STAT_OBJECTS müssten mehrere Leaf-Blocks gelesen werden).

Allerdings könnte dieselbe Query ebenso NDX_OWN_NAME_STAT_OBJECTS nutzen, auch wenn nur ein Teil der Attribute dieses Indexes in der Query angegeben ist (Abbildung 5).

Achte aber bitte darauf, dass diese Regel nur für linksbündige Subsets gilt. Auf NDX_NAME_STAT_OBJECT z.B. kann nicht ohne Weiteres zugunsten NDX_OWN_NAME_STAT_OBJECTS verzichtet werden. Letzterer stimmt mit ersterem nämlich erst ab der zweiten Spalte überein (Abbildung 6).

Das würde bei Abfragen ohne OWNER-Attribut in der WHERE-Klausel dazu führen, dass gar kein Index genutzt oder bestenfalls ein INDEX SKIP SCAN durchgeführt wird. Dieser ist jedoch erheblich „teurer“ und langsamer als der INDEX RANGE SCAN auf dem ursprünglichen Index (siehe Abbildung 7 vs. Abbildung 8).

Alternativ kannst du auch auf den „breiteren“ Index NDX_OWN_NAME_STAT_OBJECTS zugunsten des „schmaleren“ NDX_OWN_NAME_OBJECTS verzichten, da der schmalere Index per se kleiner als der breitere ist. Hier solltest du allerdings drei nicht unwesentliche Dinge im Hinterkopf behalten:

Du kannst nicht auf Indizes verzichten, die unique- oder primary key Constraints durchsetzen.
Der Verzicht auf eine Spalte, die im verworfenen Index noch enthalten war, erhöht die CPU-Last, da nach dem Indexzugriff jetzt noch ein Filtern in der Tabelle erforderlich wird (Abbildung 9 vs. Abbildung 10).
Queries, die bislang die angefragten Spalten schon im Index finden konnten, müssen nun neben dem Index auch noch auf die Tabelle zugreifen und werden folglich teurer und langsamer (Abbildung 11 vs. Abbildung 12).

Indizes, die linksbündige Subsets anderer Indizes und damit Löschkandidaten im Sinne dieses DBA Tipps sind, findest du mit folgender Query (ebenfalls eingeschränkt auf das Schema SCOTT):

WITH column_list AS
  ( SELECT DISTINCT index_owner,
    index_name,
    listagg(column_name,', ') within GROUP (
  ORDER BY column_position) over (partition BY index_name) cols
  FROM dba_ind_columns
  )
SELECT DISTINCT fst.index_owner superset_owner,
  fst.index_name superset_index,
  fst_cols.cols superset_columns,
  snd.index_owner subset_owner,
  snd.index_name subset_index,
  snd_cols.cols subset_columns
FROM dba_ind_columns fst,
  dba_ind_columns snd,
  column_list fst_cols,
  column_list snd_cols
WHERE fst.table_owner=snd.table_owner
AND fst.table_name   =snd.table_name
AND fst.index_owner  =fst_cols.index_owner
AND fst.index_name   =fst_cols.index_name
AND snd.index_owner  =snd_cols.index_owner
AND snd.index_name   =snd_cols.index_name
AND fst_cols.cols LIKE snd_cols.cols||',_%'
AND fst.index_owner ='SCOTT'
AND fst.index_name! =snd.index_name

Wahrscheinlich ist es dir bereits in diversen Screenshots aufgefallen: Die bessere Alternative zum Löschen der überflüssigen Indizes ist in diesem Fall das Ändern des Indexstatus auf „invisible“. Unsichtbare Indizes werden vom Optimizer nicht in Betracht gezogen, aber im Hintergrund weiter aktuell gehalten. Sollte sich herausstellen, dass du mit einer Annahme „schwer daneben gelegen hast“ und einen Index wieder aktivieren musst, dann muss er in diesem Fall nur „visible“ gesetzt werden und ist sofort wieder verfügbar. Ein gelöschter (oder unusable gesetzter) Index hingegen müsste erst neu aufgebaut werden. Selbstverständlich sollten die invisible gesetzten Indexes nach angemessener Zeit letztendlich dann doch gelöscht werden, denn nur so bekommst du den ganz oben erwähnten Overhead tatsächlich auch los.

Fazit

Indizes haben konträre Auswirkungen auf eine Datenbank. Auf der einen Seite beschleunigen sie DML und Queries, auf der anderen Seite erhöhen sie den Platzbedarf und DML-Overhead. Daher sollten nicht mehr Indizes als absolut nötig in der Datenbank vorhanden sein. Mit Hilfe der oben erwähnten Queries lassen sich Indizes identifizieren, die Duplikate oder Subsets anderer Indizes sind. Diese Duplikate können tendenziell aus der Datenbank entfernt werden.

Übrigens: Informationen zum Indexmonitoring findest du in unserem DBA-Tipp » Index-Monitoring – Aufspüren und Droppen von ungenutzten Indizes in Datenbanken. Index Monitoring hilft dir, Indizes aufzuspüren, die zwar existieren, aber tatsächlich gar nicht benutzt werden.

Hier findest du weitere interessante Posts zum Thema Oracle aus unserem News und Insights Bereich.

Share this article

Der Beitrag DBA Tipp: Frühjahrsputz im Index-Tablespace erschien zuerst auf ASPICON.

DBA Tipp: Index-Monitoring – Aufspüren und Droppen von ungenutzten Indizes in Datenbanken

Thilo Solbrig, Oracle Certified Master — Mon, 03 Apr 2023 06:06:00 +0000

Home → Performance Tuning

DBA Tipp: Index-Monitoring – Aufspüren und Droppen von ungenutzten Indizes in Datenbanken

Verfasst von Thilo Solbrig, Oracle Certified Master
03 April 2023
08:06
Datenbank, DBA Tipp, Oracle, Oracle Database, Performance Tuning, Praxistipp

In komplexen Datenbanksystemen existieren häufig eine Vielzahl von Indizes. Teilweise nehmen sie mehr Platz in Anspruch als die eigentlich indizierten Daten selbst. Indizes müssen bei jeder DML-Operation aktualisiert werden, belegen Platz im Buffer Cache, auf dem Storage der Datenbank und letztendlich auch im Backup. Daher ist es durchaus ratsam, sie von Zeit zu Zeit auf ihre Daseinsberechtigung hin zu prüfen. Denn ungenutzte Indizes bringen faktisch nur Nachteile mit sich.

Für dieses Indexmonitoring kannst du als DBA auf den Befehl “alter index … monitoring usage” zurückgreifen. Ein mit “monitoring” markierter Index erscheint daraufhin in der v$object_usage View des Indexowners:

[oracle@dr-02(db19c orcl2) ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Thu Mar 23 18:02:31 2023
Version 19.10.0.0.0

Copyright (c) 1982, 2019, Oracle. All rights reserved.


Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.10.0.0.0


SQL> ALTER INDEX HR.EMP_DEPARTMENT_IX MONITORING USAGE;

Index altered.

SQL> connect hr/hr
Connected.
SQL> select * from v$object_usage;

INDEX_NAME                TABLE_NAME           MON USE START_MONITORING    
------------------------- -------------------- --- --- -------------------
EMP_DEPARTMENT_IX         EMPLOYEES            YES NO  02/01/2023 12:00:20

Die Spalte MON(ITORING) zeigt an, dass der Index EMP_DEPARTMENT_IX gemonitort wird, entsprechend der Information in USE(D) allerdings bislang noch nicht verwendet wurde. Greift nun eine Abfrage auf den Index zu, ändert sich das USED-Flag entsprechend:

SQL> select last_name from employees where department_id=110;

LAST_NAME
-------------------------
Higgins
Gietz

SQL> select * from v$object_usage;

INDEX_NAME            TABLE_NAME           MON USE START_MONITORING    
--------------------- -------------------- --- --- -------------------
EMP_DEPARTMENT_IX     EMPLOYEES            YES YES 02/01/2023 12:00:20

Lässt du das Indexmonitoring nun über einen repräsentativen Zeitraum laufen, erhältst du ein gutes Gefühl dafür, welche Indizes wahrscheinlich ohne Nutzen für die Datenbank sind und gedroppt werden können. Das Monitoring übersteht im Übrigen auch den Neustart der Datenbank. Es muss also am Ende des gewünschten Monitoringzeitraumes explizit wieder abgeschaltet werden:

SQL> ALTER INDEX HR.EMP_DEPARTMENT_IX NOMONITORING USAGE;

Index altered.

SQL> select * from v$object_usage;

INDEX_NAME            TABLE_NAME           MON USE START_MONITORING    END_MONITORING
--------------------- -------------------- --- --- ------------------- -------------------
EMP_DEPARTMENT_IX     EMPLOYEES            NO  YES 02/01/2023 12:00:20 02/01/2023 12:08:08

Das USED-Flag wird zurückgesetzt, wenn das Monitoring für den betreffenden Index wieder aktiviert wird. Es gibt alternativ zum sofortigen Löschen (vermeintlich) ungenutzter Indizes noch die charmante Alternative einer Karenzzeit mit Nutzung des “alter index … invisible”. Damit wird der betreffende Index für den Optimizer “unsichtbar” und damit nicht mehr genutzt. Der Index selbst wird allerdings weiterhin aktuell gehalten. Zeigt die Praxis, dass der Index tatsächlich noch erforderlich ist, kann er mittels “alter index … visible” sofort wieder aktiviert werden, ohne dass du ihn neu aufbauen musst. Das Löschen eines Index dagegen sollte wohl überlegt sein, da seine Wiederherstellung im Falle großer Indizes oder auf stark frequentierten Tabellen in der Standard Edition nur schwer im laufenden Betrieb und in der Enterprise Edition (alter index … rebuild online) nur mit erheblichen Performanceeinbußen erfolgen kann.

Fazit

Indizes sind für die Leseperformance einer Datenbank elementar wichtig. Da ihre Haltung und Pflege auf der anderen Seite aber auch einen nennenswerten Aufwand generiert, gilt beim Einsatz von Indizes der Grundsatz: So viel wie nötig, so wenig wie möglich. Diesem Ziel kann man mit Index-Monitoring ein gutes Stück näher kommen.

Hier findest du weitere interessante Posts zum Thema Oracle aus unserem News und Insights Bereich.

Share this article

Der Beitrag DBA Tipp: Index-Monitoring – Aufspüren und Droppen von ungenutzten Indizes in Datenbanken erschien zuerst auf ASPICON.

DBA Tipp: SQL-Statements mit Syntax-Fehlern (Failed Parses) identifizieren

Jens Böttcher — Tue, 13 Sep 2022 08:01:03 +0000

Home → Performance Tuning

DBA Tipp: SQL-Statements mit Syntax-Fehlern (Failed Parses) identifizieren

Verfasst von Jens Böttcher
13 September 2022
10:01
Datenbank, DBA Tipp, Oracle Database, Performance Tuning

Das Debugging von fehlerhaften SQL-Statements in einer Anwendung kann, insbesondere bei größeren Applikationen, ziemlich aufwendig sein, solange keine Protokollierung der fehlerhaften Statements erfolgt. Dabei lohnt es sich, SQL-Statements mit Syntax-Fehlern zu identifizieren.

Standardmäßig werden in einer Oracle Datenbank keine fehlerhaften Statements festgehalten. Es werden aber, zumindest für Statements mit Syntaxfehlern, die Zähler „parse count (failures)“, „parse count (hard)“ und „parse count (total)“ für jedes fehlerhafte Statement um eins erhöht.

Der Wert für diese Zähler kann z.B. mit dem folgenden Statement ermittelt werden:

COLUMN NAME FORMAT A30
SET PAGES 400
SELECT INST_ID, NAME, VALUE
FROM GV$SYSSTAT
WHERE NAME IN (
  'parse count (total)',
  'parse count (hard)',
  'parse count (failures)'
);

Im Folgenden werden wir das einmal an einem Beispiel erläutern.

Das fehlerhafte SQL-Statement lautet:

SELECT FIRST_NAME, LAST_NAME FROM HR.EMPLOYEES WHERE EMPLOYEE__ID = 100;

Korrekterweise müsste das Statement aber so lauten:

SELECT FIRST_NAME, LAST_NAME FROM HR.EMPLOYEES WHERE EMPLOYEE_ID = 100;

Mit diesem PL/SQL-Skript werden wir das fehlerhafte SQL-Statement 10000 mal ausführen:

SET TIMING ON;
SET SERVEROUTPUT ON;
DECLARE
  I NUMBER := 1;
  I_MAX NUMBER := 10000;
  FAIL_CNTR NUMBER := 0;
  EXEC_CNTR NUMBER := 0;
BEGIN
  WHILE I <= I_MAX LOOP
    BEGIN
      EXEC_CNTR := EXEC_CNTR + 1;
      EXECUTE IMMEDIATE '
SELECT FIRST_NAME, LAST_NAME FROM HR.EMPLOYEES WHERE EMPLOYEE__ID=100
';
    EXCEPTION
      WHEN OTHERS
      THEN FAIL_CNTR := FAIL_CNTR + 1;
    END;
    I := I + 1;
  END LOOP;
  DBMS_OUTPUT.PUT_LINE(CHR(10) || FAIL_CNTR || ' / ' || EXEC_CNTR || ' statements failed.');
END;
/
SET TIMING OFF;

Vorher sind die Werte für Parse count Total/Hard/Failures so verteilt:

   INST_ID NAME                                VALUE
---------- ------------------------------ ----------
         1 parse count (total)                  5909
         1 parse count (hard)                   1444
         1 parse count (failures)                  0

Nachdem das korrekte SQL-Statement 10000 mal ausgeführt wurde (Dauer: 0,28 Sekunden):

   INST_ID NAME                                VALUE
---------- ------------------------------ ----------
         1 parse count (total)                  7162
         1 parse count (hard)                   1740
         1 parse count (failures)                  0

Nachdem das fehlerhafte SQL-Statement 10000 mal ausgeführt wurde (Dauer: 2,69 Sekunden):

   INST_ID NAME                                VALUE
---------- ------------------------------ ----------
         1 parse count (total)                 17195
         1 parse count (hard)                  11746
         1 parse count (failures)              10000

Man sieht, dass für die Ausführung des korrekten SQL-Statements kein Parse mehr notwendig ist, weil das Statement schon im Library Cache vorhanden ist. Das schlägt sich auch in einer schlechteren Performance nieder, da für das Parsing der 10000 Statements 2,41 Sekunden (2,69 – 0,28) benötigt werden.

Um jetzt die Sessions zu ermitteln, die für die vielen Failed Parses verantwortlich sind, kann die View gv$sesstat verwendet werden:

SELECT S.INST_ID, S.SID, S.SERIAL#, STATN.NAME, STAT.VALUE
FROM GV$SESSION S
JOIN GV$SESSTAT STAT
  ON S.SID = STAT.SID AND S.INST_ID = STAT.INST_ID
JOIN GV$STATNAME STATN
  ON STAT.STATISTIC# = STATN.STATISTIC# AND STAT.INST_ID = STATN. INST_ID
WHERE STATN.NAME = 'parse count (failures)' AND STAT.VALUE > 0
ORDER BY STAT.VALUE DESC;

   INST_ID        SID    SERIAL# NAME                                VALUE
---------- ---------- ---------- ------------------------------ ----------
         1        386      42069 parse count (failures)              30000

Mit Hilfe der SID und der SERIAL# kann man die SQL-Statements mit den Syntaxfehlern ermitteln, in dem man für die betroffene Session ein Tracing einrichtet. Anhand des Beispiels wird das Tracing wie folgt eingerichtet.

EXECUTE DBMS_MONITOR.SESSION_TRACE_ENABLE(386, 42069, waits => false, binds => true);

Damit wird eine Trace-File auf dem Datenbankserver im Trace-Verzeichnis erstellt. Für jeden fehlgeschlagenen Parse wird ein Log-Eintrag in der folgenden Form erzeugt:

PARSE ERROR #140737352601368:len=70 dep=1 uid=0 oct=3 lid=0 tim=3707057109080 err=904
SELECT FIRST_NAME, LAST_NAME FROM HR.EMPLOYEES WHERE EMPLOYEE__ID=100

Nachdem die betroffenen Statements ermittelt wurden, empfehlen wir das Tracing wieder zu deaktivieren, um nicht unnötig viele Log-Einträge zu erzeugen.

EXECUTE DBMS_MONITOR.SESSION_TRACE_DISABLE(386, 42069);

Fazit

Syntaktisch fehlerhafte SQL-Statements können gut über die Bordmittel der Oracle Datenbank ermittelt werden. Dabei zeigt sich auch, dass ein Ignorieren dieser Statement für einen erhöhten Parseaufwand sorgt und dadurch die Performance leidet.

Es lohnt sich also, SQL-Statements mit Syntax-Fehlern zu identifizieren.

Hier findest du weitere interessante Posts zu den Themen SQL Tuning oder DBA Tipps aus unserem News und Insights Bereich.

Share this article

Der Beitrag DBA Tipp: SQL-Statements mit Syntax-Fehlern (Failed Parses) identifizieren erschien zuerst auf ASPICON.

SQL Tuning Tipp: Bindevariablen

Thilo Solbrig, Oracle Certified Master — Sun, 24 Oct 2021 06:00:38 +0000

Home → Performance Tuning

SQL Tuning Tipp: Bindevariablen

Verfasst von Thilo Solbrig, Oracle Certified Master
24 Oktober 2021
08:00
Datenbank, DBA Tipp, Oracle Database, Performance Tuning, SQL Tuning

Die Nutzung von Literalen führt dazu, dass an sich gleiche (d.h. sich nur durch Literale unterscheidende) Statements nicht als solche erkannt, sondern jeweils einzeln behandelt. Und dann werden sie auch jeweils im Shared Pool gepuffert. Daraus ergeben sich folgende Nachteile:

Es fällt für jedes Statement CPU-Aufwand für Hard Parsing an, das im Ergebnis aber nur zu bereits bekannten Ausführungsplänen führt.
Die Pufferung dieser Statements und Ausführungspläne im Shared Pool bringt keinen Mehrwert, da die Wiederverwendung der Statements unwahrscheinlich ist.
Im Regelfall sind Oracle-Datenbanken auf Automatisches (Shared) Memory Management konfiguriert. Daher geht verschwendeter Shared Pool zu Lasten des Buffer Caches. Das zieht wiederum erhöhten I/O‑Aufwand zum Nachladen verdrängter Datenblöcke nach sich.
Diagnosetools wie AWR, Statspack oder Spotlight übertragen Statements, Ausführungspläne und ‑statistiken aus dem Shared Pool in ihr Repository. Ein mit unnötigen Statements gefüllter Shared Pool führt damit zu

* überproportional längeren Laufzeiten für die Diagnosesnapshots,

* überproportional höherem Platzbedarf in den Diagnoserepositories,

* überproportional höherem Verdrängen von Applikationsdaten aus dem Buffer Cache durch das Übertragen von Diagnosedaten in die Repositories.
Im Extremfall kann die so mittelbar von Diagnosetools verursachte Last erhebliche Performanceprobleme nach sich ziehen. Die eigentliche Überwachung der Performance wird so zum Problem für die Performance.
Sofern eine Verbesserung der Applikation nicht (mehr) oder nicht mit vertretbarem Aufwand möglich ist, kann die Ersetzung von Literalen durch Bindevariablen datenbankseitig erzwungen werden.

Hier findest du weitere Posts zu den Themen SQL Tuning bzw. Performance Tuning aus unserem News Bereich.

Share this article

Der Beitrag SQL Tuning Tipp: Bindevariablen erschien zuerst auf ASPICON.

SQL Tuning Tipp: Subquery in SELECT-Klausel

Thilo Solbrig, Oracle Certified Master — Fri, 10 Sep 2021 06:00:26 +0000

Home → Performance Tuning

SQL Tuning Tipp: Subquery in SELECT-Klausel

Verfasst von Thilo Solbrig, Oracle Certified Master
10 September 2021
08:00
Datenbank, DBA Tipp, Oracle Database, Performance Tuning, SQL Tuning

Im Rahmen von SQL-Tuning-Maßnahmen sieht man zuweilen, dass Subqueries zur Ermittlung von Spaltenwerten direkt in der SELECT-Klausel verwendet werden. Obwohl syntaktisch korrekt, ist das regelmäßig ein Stolperstein für den Optimizer. Er kommt offenkundig mit der Abschätzung “echter” Joins besser zurecht.

Da der Rückgabewert der Subquery nur ein einzeiliger Skalar oder NULL sein kann (da andernfalls die Query fehlschlagen würde), erreicht man mit Umstellung auf LEFT OUTER JOIN das selbe Ergebnis. Aus dem genannten Grund sind weder mehr als eine Zeile auf der “rechten” Seite des Joins zu erwarten noch besteht die Gefahr der Eliminierung von Ergebniszeilen der “linken” Seite durch den Join, da es sich ja um einen OUTER Join handelt.

Subquery in der SELECT-Klausel

SELECT first_name, last_name,
  (SELECT department_name
  FROM departments
  WHERE department_id = e.department_id)
FROM employees e;

-------------------------------------------------------------------------------------------
| Id  | Operation                   | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |             |   107 |  1926 |    14   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| DEPARTMENTS |     1 |    16 |     1   (0)| 00:00:01 |
|*  2 |   INDEX UNIQUE SCAN         | DEPT_ID_PK  |     1 |       |     0   (0)| 00:00:01 |
|   3 |  TABLE ACCESS FULL          | EMPLOYEES   |   107 |  1926 |     3   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------

Die ursprüngliche Query wird ähnlich einem NESTED LOOP ausgeführt. Für jede der 107 Zeilen aus EMPLOYEES wird über je einen INDEX UNIQUE SCAN der Indexeintrag des zugehörigen Departments gesucht und über je einen weiteren ROWID-Zugriff der department_name aus der DEPARTMENTS-Tabelle ermittelt. Das kann bei ausreichend großer “äußerer” Tabelle ein sehr unperformanter Zugriffspfad sein. NESTED LOOPs performen nur bei geringer Kardinalität der “äußeren” Tabelle gut.

Ersetzung durch einen Join

SELECT first_name, last_name, department_name
FROM employees e 
  LEFT JOIN departments d using (department_id);

----------------------------------------------------------------------------------
| Id  | Operation          | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |             |   107 |  3638 |     6   (0)| 00:00:01 |
|*  1 |  HASH JOIN OUTER   |             |   107 |  3638 |     6   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| EMPLOYEES   |   107 |  1926 |     3   (0)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| DEPARTMENTS |    27 |   432 |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------

Der LEFT OUTER JOIN hingegen wird über einen (outer) HASH JOIN abgewickelt, der insbesondere bei großer “äußerer” Tabelle viel besser performt, als ein NESTED LOOP. Das spiegelt sich im angegebenen Beispiel vor allem in der Cost-Schätzung wider.

Hier findest du weitere Posts zu den Themen SQL Tuning bzw. Performance Tuning aus unserem News Bereich.

Share this article

Der Beitrag SQL Tuning Tipp: Subquery in SELECT-Klausel erschien zuerst auf ASPICON.