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
 

Neue Connect-Methode des AS ABAP an Oracle per SSFS

Bisher funktioniert die Verbindung des SAP-Systems (Application Server ABAP) und der SAP-Tools, die die ABAP-Datenbankschnittstelle verwenden (R3trans, R3load, ...), zur Datenbank über SQLNet (per DB-Aliasname, z.B. TNS), indem zunächst eine durch den Betriebssystem-Nutzer adm authorisierte sog. OPS$-Verbindung (mit dem DB-Nutzer OPS$ADM) hergestellt wird ("connect /@TNS"). Dies gestattet den Zugriff auf die Tabelle OPS$ADM.SAPUSER und nur auf diese Tabelle. Darin ist das Paßwort für die eigentliche DB-Verbindung des SAP-Datenbankbenutzers (Standardname SAPSR3) verschlüsselt enthalten.




Der OPS$-Remote-Connect (per TNS-Aliasnamen) wird von künftigen Oracle-Versionen nach Release 11g nicht mehr unterstützt. SAP führt deshalb ab Kernel-Release 7.20 eine neue Methode zur sicheren Speicherung des Datenbank-Paßwortes und für die Verbindung zur DB ein, den "Sicheren Speicher im Dateisystem" ("Secure Storage in File System", SSFS). Das verschlüsselte Paßwort für den SAP-Datenbankbenutzer wird dann nicht mehr in der Datenbank, sondern im Dateisystem gespeichert.

Mit der Übernahme des Kernels 7.20 (11/2011) als abwärtskompatibler Kernel (AKK für 7.x) steht die neue Methode auf allen 7.x-Systemen (ab SAP 7.00) zur Verfügung. SAP empfiehlt, aus Sicherheitsgründen die neue Methode zu verwenden.





Achtung:

Die neue Connect Methode (SSFS) steht derzeit nur für auf Unicode basierende 7.x-Systeme zur Verfügung. Nach aktueller Planung sollen Nicht-Unicode-7.x-Systeme bis Ende März 2012 ebenfalls den SSFS-Connect unterstützen.





Zwecks Rückwärtskompatibilität wird die herkömmliche Connect-Methode für alle SAP-Systeme mit Oracle bis Version 11.2 weiter unterstützt.

Alle SAP-Systeme ab Kernel 7.20, die zukünftige Oracle-Versionen nach 11g benutzen, können nur noch mit der neuen Methode betrieben werden.


Hinweis 1622837 - Neue Connect-Methode des AS ABAP an Oracle per SSFS

Oracle Index Komprimierung II

Dazu gibt es schon einen Post  - doch der  Hinweis 1109743 - Komprimierung von Indexschlüsseln für Oracle-Datenbanken enthält nun ein SQL Script mit Erfahrungswerten vieler Kunden welche Indizes auf einem ERP System komprimiert werden sollten!

Weiters gibt es im SDN noch ein SQL Skript mit dem man die Indizes ermitteln kann
welche relevant für eine Komprimierung sind!

Link: SND

Index Compression Overview


Being able to compress indexes has many advantages:

Less space consumption on disk

Less space consumption in buffer pool

Less I/O activities

Better performance due to less disk reads and buffer gets

Less CPU consumption (because the small compression related CPU overhead is smaller than the CPU savings due to less disk reads and buffer gets)

The main problem of index compression is that an optimal amount of leading index columns (prefix) has to be found that can be compressed

An exact analysis (e.g. via VALIDATE STRUCTURE or provided PL/SQL scripts) needs to scan a lot of data and runs a long time

The following SQL command can be used to determine an acceptable index compression prefix and the expected minimum space gain quickly based on CBO statistics.

AnalysisSQL Command: Space_IndexCompression.txt


Purpose:

Conservative index compression analysis based on CBO statistics

Features:

Threshold value for minimum amount of saved data space

Analysis can be restricted to particularly large or I/O intensive segments (focus on space or performance)

Generation of Oracle or BRSPACE index rebuild command for compression activation possible

Restrictions:

Result can„t be 100 % precise because correlation of leading index columns is not visible in CBO statistics, script assumes worst case scenario of uncorrelated columns, in about 20 % of all indexes this can lead to a suggested prefix length that is smaller than the optimal prefix length

Prerequisites:

Regular BRCONNECT statistic run must be scheduled (recommendation: daily)

Indexbeschädigung/falsche Ergebn. nach ONLINE-Indexneuaufbau

Da gibt es doch einen ordentlichen BUG unter 10.2.0.4!

Betrifft alle die sich die Mühe genommen haben und Ihre Indizes ONLINE reorganisiert haben...

bzw. wenn folgendes gemacht wurde:

Wenn beim Online-Indexneuaufbau eine Änderung einer hohen Parallelverarbeitung in der Tabelle durchgeführt wird, KANN der Index durch fehlende Schlüssel beschädigt werden

sie SAP NOTE 1413928

Automatisierte Oracle-10g-Patch-Prüfung

Einmal habe ich zu diesem Thema bereits kurz einen Blog erfasst - in diesem konnte man mit einem brconnect Befehlt prüfen welche Patches man installiert hat - doch mit diesem SAP Hinweis kann man seinen aktuell installierten Patchstand mit dem aktuellsten Patchstand vom SAP Markteplace quer prüfen und die neuesten Patches installieren!

Link zur Patchcheck Tool

https://service.sap.com/~sapidb/012003146900000618932009E/sap_patchcheck.htm

Symptom

Sie möchten die installierten Oracle-10g-Patches mit den erforderlichen Patches für SAP vergleichen.
Weitere Begriffe

Patch-Überprüfung, Oracle
Ursache und Voraussetzungen

Sie verwenden Oracle 10g.
Sie haben eine Liste der installierten Patches und die Ausgabe eines der folgenden Befehle:

o opatch lsinventory

o RSORAPATCHINFO

o brconnect -u / -c -F lsinv

Lösung

Diesem SAP-Hinweis ist eine HTML-Seite mit einem JavaScript-Programm beigefügt, das eine automatische Prüfung durchführt.

Das Programm wird synchron zu den Patch-Hinweisen gepflegt.
Aktuell

* SAP-Hinweis 871735 Version 45

* SAP-Hinweis 871096 Version 189 (10.2.0.2)

* SAP-Hinweis 1137346 Version 78 (10.2.0.4 und Windows-Mini-Patches)


Gehen Sie folgendermaßen vor, um die Prüfung durchzuführen:

o Öffnen Sie die beigefügte HTML-Seite in einem Browser, der JavaScript unterstützt (getestet wurde dies bisher in Firefox 3.0, 3.5, Safari 4.0 und Internet Explorer 7, sollte aber problemlos in allen neueren Browsern funktionieren).

o Geben Sie an, ob Sie eine kurze Ausgabe (lediglich fehlende und veraltete Patches) oder eine lange (alle zugehörigen Patches und SAP-Hinweise) benötigen.

o Wählen Sie das Datenbank-Betriebssystem aus.

o Fügen Sie die Liste der abgerufenen Patches mit einem der erwähnten Befehle in das Textfeld ein.

o Wählen Sie die Drucktaste zum Prüfen ("Check").



Daraufhin wird ein neues Fenster mit Informationen zur Prüfung geöffnet.

Einzelne Tabellen auf Ihre Platzauslastung prüfen

Wenn Sie wissen möchten wieviel Platz in einer Tabelle wirklich verwendet wir dann können Sie diese SQL Statement verwenden:

SELECT
TO_CHAR(SPACE_ALLOCATED / 1024 / 1024,
999990.99) GROSS_MB,
TO_CHAR(SPACE_USED / 1024 / 1024, 999990.99) NET_MB,
TO_CHAR((SPACE_ALLOCATED - SPACE_USED) / 1024 / 1024,
999990.99) UNUSED_MB,
CHAIN_PCENT CHAIN_PERCENT
FROM
TABLE(DBMS_SPACE.OBJECT_SPACE_USAGE_TBF('SAPER3',
'MARA', 'TABLE', NULL ))

Als Beispiel wird hier die Tabelle MARA im Schema SAPER3 überprüft - das sind auch die einzigen beiden Werte die sie gemäß ihrer Datenbank anpassen müssen!

Das Ergebnis sieht dann wie folgt aus (Bespiel MARA):

GROSS_MB	NET_MB	UNUSED_MB
279.00	263.28	15.72

GROSS MB = die tatsächliche Grösse der Tabelle MB
NET_MB = der Inhalt der Tabelle im MB
UNUSED_MB = der nicht verwendete Platz in der Tabelle in MB

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!