Leider wird die Rolle von Experten für Leistungsoptimierung und Datenbank-Fehlerbehebung jetzt nur noch auf das Letzte reduziert - Fehlerbehebung: Sie wenden sich fast immer nur dann an Spezialisten, wenn die Probleme bereits einen kritischen Punkt erreicht haben und "erst gestern" gelöst werden müssen. Und selbst dann ist es gut, wenn sie sich wenden und das Problem nicht verzögern, indem sie eine noch teurere und leistungsstärkere Hardware ohne ein detailliertes Leistungsaudit und Stresstests kaufen. In der Tat sind Frustrationen oft genug: Sie kauften Geräte, die 2-5-mal teurer waren, und gewannen nur 30-40% an Leistung. Die gesamte Steigerung wird in wenigen Monaten entweder durch eine Zunahme der Benutzeranzahl oder durch eine exponentielle Zunahme der Daten in Verbindung mit einer Komplikation der Logik aufgezehrt.
Und jetzt, in einer Zeit, in der die Anzahl der Architekten, Tester und DevOps-Ingenieure schnell wächst und Java Core-Entwickler sogar die Arbeit
mit Zeichenfolgen optimieren, wird langsam aber sicher die Zeit für Datenbankoptimierer kommen. DBMS werden mit jeder Version so intelligenter und komplexer, dass das Studium sowohl dokumentierter als auch nicht dokumentierter Nuancen und Optimierungen viel Zeit in Anspruch nimmt. Eine große Anzahl von Artikeln wird monatlich veröffentlicht und große Konferenzen zu Oracle werden abgehalten. Entschuldigen Sie die banale Analogie, aber in dieser Situation, in der Datenbankadministratoren Flugzeugpiloten mit unzähligen Kippschaltern, Tasten, Lichtern und Bildschirmen ähnlich werden, ist es unanständig, sie mit den Feinheiten der Leistungsoptimierung zu laden.
Natürlich können DBAs wie Piloten in den meisten Fällen offensichtliche und einfache Probleme leicht lösen, wenn sie entweder leicht diagnostiziert werden oder in verschiedenen „Top“ (Top-Events, Top-SQL, Top-Segmente ...) erkennbar sind. Und die bei MOS oder Google leicht zu finden sind, auch wenn sie die Lösung nicht kennen. Es ist viel komplizierter, wenn selbst die Symptome hinter der Komplexität des Systems verborgen sind und unter den riesigen Diagnoseinformationen, die vom Oracle DBMS selbst gesammelt werden, herausgefischt werden müssen.
Eines der einfachsten und anschaulichsten Beispiele dieser Art ist die Analyse von Filter- und Zugriffsprognosen: In großen und geladenen Systemen kommt es häufig vor, dass ein solches Problem leicht übersehen wird, weil Die Last ist ziemlich gleichmäßig auf verschiedene Anforderungen verteilt (mit Verknüpfungen für verschiedene Tabellen, mit geringfügigen Unterschieden in den Bedingungen usw.), und die oberen Segmente zeigen nichts Besonderes. Sie sagen: "Nun ja, aus diesen Tabellen werden die Daten am häufigsten benötigt und es gibt mehr." . In solchen Fällen können Sie die Analyse mit Statistiken aus SYS.COL_USAGE $:
col_usage.sql startencol owner format a30 col oname format a30 heading "Object name" col cname format a30 heading "Column name" accept owner_mask prompt "Enter owner mask: "; accept tab_name prompt "Enter tab_name mask: "; accept col_name prompt "Enter col_name mask: "; SELECT a.username as owner ,o.name as oname ,c.name as cname ,u.equality_preds as equality_preds ,u.equijoin_preds as equijoin_preds ,u.nonequijoin_preds as nonequijoin_preds ,u.range_preds as range_preds ,u.like_preds as like_preds ,u.null_preds as null_preds ,to_char(u.timestamp, 'yyyy-mm-dd hh24:mi:ss') when FROM sys.col_usage$ u , sys.obj$ o , sys.col$ c , all_users a WHERE a.user_id = o.owner
Für eine vollständige Analyse dieser Informationen reicht dies jedoch nicht aus, da Es werden keine Kombinationen von Prädikaten angezeigt. In diesem Fall kann uns die Analyse von v $ active_session_history und v $ sql_plan helfen:
with ash as ( select sql_id ,plan_hash_value ,table_name ,alias ,ACCESS_PREDICATES ,FILTER_PREDICATES ,count(*) cnt from ( select h.sql_id ,h.SQL_PLAN_HASH_VALUE plan_hash_value ,decode(p.OPERATION ,'TABLE ACCESS',p.OBJECT_OWNER||'.'||p.OBJECT_NAME ,(select i.TABLE_OWNER||'.'||i.TABLE_NAME from dba_indexes i where i.OWNER=p.OBJECT_OWNER and i.index_name=p.OBJECT_NAME) ) table_name ,OBJECT_ALIAS ALIAS ,p.ACCESS_PREDICATES ,p.FILTER_PREDICATES
Wie Sie der Abfrage selbst entnehmen können, werden die Top-50-Suchspalten und die Prädikate selbst nach der Häufigkeit angezeigt, mit der ASH in den letzten 3 Stunden Treffer erzielt hat. Trotz der Tatsache, dass ASH nur Schnappschüsse pro Sekunde speichert, ist die Probenahme an geladenen Basen sehr repräsentativ. Es kann mehrere Punkte klarstellen:
- Das Spaltenfeld - zeigt die Suchspalten selbst an und total_by_cols - die Summe der Einträge im Kontext dieser Spalten.
- Ich denke, es ist ziemlich offensichtlich, dass diese Informationen an sich kein ausreichender Marker für das Problem sind, weil Beispielsweise können mehrere einmalige Fullscans die Statistik leicht ruinieren, sodass Sie die Abfragen selbst und ihre Häufigkeit auf jeden Fall berücksichtigen müssen (v $ sqlstats, dba_hist_sqlstat).
- Plan_hash_value ist wichtig für die Kombination von Index- und Tabellenprädikaten nach Objekt, da die Gruppierung nach OBJECT_ALIAS in SQL_ID wichtig ist Beim Zugriff auf die Tabelle über den Index werden die Prädikate in verschiedene Zeilen des Plans unterteilt:
Je nach Bedarf kann dieses Skript leicht geändert werden, um zusätzliche Informationen in anderen Abschnitten zu sammeln, z. B. unter Berücksichtigung der Partitionierung oder der Erwartungen. Nachdem Sie diese Informationen bereits analysiert haben, können Sie zusammen mit der Analyse der Tabellenstatistik und ihrer Indizes, des allgemeinen Datenschemas und der Geschäftslogik Empfehlungen an Entwickler oder Architekten weitergeben, um eine Lösung auszuwählen, z. B. Optionen für die Denormalisierung oder das Ändern des Partitionierungsschemas oder der Indizes.
Es wird auch häufig vergessen, den SQL * -Netzverkehr zu analysieren, und es gibt auch viele Feinheiten, z. B. Abrufgröße, SQLNET.COMPRESSION, erweiterte Datentypen, mit denen die Anzahl der Roundtripes reduziert werden kann usw. Dies ist jedoch ein Thema für einen separaten Artikel.
Abschließend möchte ich sagen, dass die Optimierung der Leistung jetzt, da die Benutzer weniger tolerant gegenüber Verzögerungen sind, zu einem Wettbewerbsvorteil wird.