Unterstützung für Index-Komprimierung in BRSPACE 7.20

BRSPACE 7.20 unterstützt ab Patch 3 die Verwaltung der Index-Komprimierung sowohl bei Oracle 10g als auch bei Oracle 11g.


Mit Index-Komprimierung kann wesentlich Speicherplatz für Indizes gespart werden. Allerdings sind nicht alle Indizes für eine Komprimierung geeignet, zum Beispiel nicht sehr kleine Indizes und keine Indizes, deren Werte in den Schlüsselfeldern sich stets unterscheiden. Für die Qualität der Index-Komprimierung spielt auch die Entscheidung darüber eine wichtige Rolle, welche Index-Spalten in die Komprimierung einbezogen werden.

Weitere Informationen zur Index-Komprimierung und ihren Vor- und Nachteilen finden Sie im Hinweis 1109743 und in der Oracle-Dokumentation.

Beispiel - habe eine Datenbank mit 500GB Indizes komprimiert - danach waren es noch 300GB Indizes!

hab die Variante

brspace -u / -c force -f idrebuild -o sapsr3 -s PSAPSR3 -i allsel -c cind -ic ora_proc -p 4


verwendet - also die konservativer Methode!

QUELLE SAP HINWEIS
 

Index-Komprimierung im SAP-Umfeld

Index-Komprimierung wird im SAP-Umfeld ab Oracle 10g unterstützt. Es können nur B*TREE-Indizes komprimiert werden, aber keine Bitmap-Indizes (die ja durch Verwendung von Bitmaps schon platzsparend angelegt sind). Beachten Sie auch Hinweis 1109743

Index-Komprimierung lohnt sich besonders dann, wenn es führende Index-Spalten gibt, die wenige Ausprägungen haben und für einen relativ großen Anteil der gesamten Index-Spalten-Länge verantwortlich sind. Die optimale Anzahl der zu komprimierenden Spalten kann standardmäßig gemäß Hinweis 1109743 ermittelt werden. Dieser Ansatz hat den Vorteil, dass er auf CBO-Statistiken basiert und daher ziemlich schnell ist und keine Sperren erfordert.

Alternativ kann in bestimmten Situationen auch ANALYZE INDEX VALIDATE STRUCTURE wie im folgenden beschrieben verwendet werden. Beachten Sie aber, dass VALIDATE STRUCTURE zu Sperren führt und daher nicht parallel zum Produktivbetrieb durchgeführt werden sollte. Außerdem kann diese Operation nicht parallelisiert werden, weshalb es zu langen Laufzeiten kommen kann:
ANALYZE INDEX "" VALIDATE STRUCTURE;

Anschließend kann der Tabelle INDEX_STATS die Komprierungsinformation entnommen werden, z.B.:
SELECT OPT_CMPR_COUNT, OPT_CMPR_PCTSAVE FROM INDEX_STATS;
OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
-------------- ----------------
2 22

In diesem Fall schlägt Oracle eine Komprimierung der zwei führenden Indexspalten vor und erwartet dadurch eine Reduzierung der Netto-Indexdaten um 22 Prozent.

Mit aktuellen BRSPACE-Versionen können mit Hilfe der "-CBB"-Option ebenfalls INDEX REBUILDs mit integriertem COMPRESS durchgeführt werden. Beispiel für eine Komprimierung der ersten zwei Indexspalten:
brspace -f idrebuild -i INDEXNAME -CBB 2

Populäre Irrtümer im Oracle-Umfeld

Es gibt von der SAP den HW 825653 zum Thema Populäre Irrtümer im Oracle-Umfeld!

Dieser ist wirklich sehr Interessant und kann einige Fragen im Oracle Umfeld klären - hier ein paar Bespiele aus dem HW:

1. Der Oracle Cost Based Optimizer wählt immer den Zugriff mit den niedrigsten errechneten Kosten.

Dies ist nicht allgemein richtig, da auch der Cost Based Optimizer in bestimmten Situationen regelbasierte Entscheidungen trifft. So kann es sein, dass ein Zugriff mit hundertmal besseren Kosten nicht verwendet wird, weil die erste Indexspalte nicht mit "=" in der WHERE-Bedingung angegeben ist und der Zugriff dadurch als "Guess" bewertet wird. Beachten Sie dazu auch die Informationen aus Hinweis 176754.

2. Indizes sollten so aufgebaut werden, so dass die selektiven Felder ganz vorne stehen.

Es ist aus Performancegesichtspunkten egal, ob selektive oder unselektive Felder (wie MANDT) am Anfang eines Indexes stehen. Viel wichtiger ist, dass Felder, die in WHERE-Bedingungen nicht mit "=" angegeben werden und einen großen Wertebereich abdecken, möglichst weit hinten im Index zu finden sind. Außerdem muss vermieden werden, dass es Lücken im Index gibt, die nicht in der WHERE-Bedingung angegeben sind. Beachten Sie auch Hinweis 766349.

3. Indizes, die nur Spalten mit wenigen Ausprägungen indizieren, sind überflüssig.

Die Anzahl der Distinct Values einer Spalte kann in vielen Fällen nicht mit der Selektivität bestimmer Bedingungen auf dieser Spalte gleichgesetzt werden. Es kommt oft vor, dass Bedingungen für Spalten mit wenigen Ausprägungen sehr selektiv sind. Daher tragen auch Indizes auf Spalten mit wenigen Distinct Values oft zu einer großen Performancesteigerung bei. Ein detailliertes Beispiel zu Selektivität vs. Distinct Values ist in Hinweis 766349 zu finden.

4. Histogramme unterstützen den CBO im R/3-Umfeld bei der Auswahl des optimalen Zugriffspfades, weil Sie Informationen über die Werteverteilung von Spalten enthalten.

Histogramme können im R/3-Umfeld nicht sinnvoll ausgewertet werden, weil SAP beim Parsen Bind-Variablen verwendet und Bind Value Peeking standardmäßig deaktiviert ist. Beachten Sie dazu auch Hinweis 797629.

5. Um zu ermitteln, wie viel Memory durch Oracle allokiert wird, muss man nur die Größe der SGA bestimmen.

Die SGA ist zwar ein wichtiger Memory-Bereich, aber auch die PGA und das Prozess-Memory können signifikante Größen erreichen. Im Einzelfall kann der durch die PGA allokierte Memory-Bereich sogar größer als die SGA werden. Daher sind auch PGA und Prozess-Memory in die Kalkulation des Oracle-Speicherverbrauchs mit einzubeziehen. Für weitere Informationen beachten Sie Hinweis 789011.

usw..... weiter geht es im HW 825653

Der Oracle Alertlog in einem SAP Umfeld

- Wo finde ich das Oracle-Alertlog?

Du findest das Alertlog im R/3-Umfeld im Verzeichnis:

UNIX: $SAPDATA_HOME/saptrace/background

Der Dateiname ist alert_. log, alrt.log oder ähnlich.

- Wieso werden manche Oracle-Fehler nicht im Alertlog protokolliert?

Oracle protokolliert nur "kritische" Fehler im Alertlog. Die Mehrheit der Oracle-Fehlercodes (darunter leider auch wirklich kritische) wird nicht geloggt. Es ist daher normal, dass Du in der Oracle-Anwendung Fehler finden, die im Alertlog nicht zu sehen sind.

- Wie kann ich vermeiden, dass das Alertlog sehr groß wird?

Hinweis 786032 beschreibt, wie die Größe des Alertlogs in Grenzen gehalten werden kann, indem das File regelmäßig umbenannt wird.

Oracle bugfixes - welche sind bereits installiert?

Sie haben ein Problem mit der Datenbank und finden im Marketplace einen Hinweis das dieser Bug mit einen Oracle Patch erledigt ist. Nun fragt man sich aber ob man nicht vielleicht den Patch schon installiert hat bzw. welche Patches sind in einer Oracle Datenbank bereits installiert?!

Seit 7.00 kann man die Patches auch mit dem brconnect abfragen:

brconnect -F lsinv

bzw wenn man genau eine Patchnummer checken möchte dann:

brconnect -F lsinv | grep NUMMER

Oracle Parameter Empfehlung für ein SAP System

Es gibt von der SAP den Hinweis 1171650 mit dem ein Script ausgeliefert wird zur Überprüfung

der Oracle Parameter eines SAP Systems.

Dabei werden die aktuellen Empfehlungen des relevanten Parameterhinweises (abhängig vom Oracle Release, Patchset und/oder Systemtyp) mit den konkreten DB Parametern verglichen.

Wichtig ist bevor man ein System auf deren Parameter überprüft immer den HW 1171650 zu checken ob es nicht ein Update vom Script gibt!

Kennwort vom Datenbank User ändern

Es gibt aus Securitygründen immer wieder die Anfrage das der SAP User einer Datenbank geändert werden muss. Im SAP Umfeld lässt sich das sehr leicht mit den brtools bewerkständigen!

BRTOOLS -> 8 – Additional functions -> 4 – Change password of database user -> continue

und einfach das neue Kennwort vergeben - das war's auch schon!

Weiters kann man das auch in einer Zeile eingeben:

brconnect [-u system/] –f chpass –u

oder direkt im SQL

sqlplus “/as sysdba”
alter user ‘username’ identified by ‘password’;

Online Reorg von einzelnen Tabellen

Es kommt immer wieder vor das man z.B. vergisst einen Trace zu deaktivieren und dadurch wird eine Tabelle unnötig aufgeblasen und der Platz in der Datenbank verschwendet.

Hat man nun den Inhalt der Tabelle wieder geleert möchte man gerne den Platz in der Datenbank zu der leeren Tabelle wieder freibekommen - das geht nun wie folgt:

Zuerst prüfen wir ob auf unserem SAP System die neuesten brtools installiert sind -
dann meldet wir uns mit putty (oder einem anderen ssh produkt) am Server als sidadm an
führen den Befehl

brspace -f tbreorg -t tabelname

aus - weiters folgen wir einfach den nächsten Schritten mit c (continue)

das wars auch schon - die Tabelle wurde online reorganisiert

wichtig - das geht nicht mit Tabellen die LANG RAWS haben - diese müssen vorher in LOBS migriert werden - aber auch das geht mit brspace :

brpspace -f tbreorg -a long2lob -t tabelname