select.

Oracle Locks

Manchmal kann es hilfreich sein direkt auf Datenbankebene zu schauen welche Session welchen Lock hält um zu sehen warum es wo genau klemmt und zum Beispiel ein Workprozess nicht weiter arbeiten kann oder die erwarteten Updates noch immer nicht fertig gestellt wurden.

Ich persönlich finde folgenden Statements dabei hilfreich.

Mit diesem Statement kann man schnell und einfach sehen, welche Session einen Lock hält und welche andere Session genau auf diesen Lock wartet:

SQL> set pages 200 lines 200
SQL> select HOLDING_SESSION, MODE_HELD, WAITING_SESSION from DBA_WAITERS order by HOLDING_SESSION;

HOLDING_SESSION MODE_HELD WAITING_SESSION
--------------- ---------------------------------------- ---------------
147 Exclusive 918
147 Exclusive 4621
147 Exclusive 4626
147 Exclusive 428
428 None 918
428 None 4621
428 None 4626
428 None 428
4621 None 4626
4621 None 4621
4621 None 918
4621 None 428
4626 None 4626
4626 None 4621
4626 None 918
4626 None 428

16 rows selected.

SQL>

[Read more…]

Oracle Sessions und der steinige Weg ins Nirvana

Manchmal kommt es vor, dass man eine Oracle Session beenden möchte ohne gleich die ganze Datenbank durchstarten zu müssen 😉

Zum Beispiel wenn ein Workprozess im SAP gekillt wird, die aktuell laufende Aktion allerdings innerhalb des Oracles noch weiter ausgeführt wird und damit nicht nur Ressourcen bindet, sondern ggf. auch Locks auf Objekte hält.

Zunächst muss man die Sessions, die man beenden möchte identifizieren. Zum Beenden der Session braucht man die Session ID (sid) sowie die Seriennummer der Aktion innerhalb der SID (serial#). Diese bekommt man recht einfach über den View v$session. Meist dürfte die Session ID bereits über die SAP Transaktion DB02 bekannt sein, so dass hier lediglich die entsprechende Serial zu der Session ID gefunden werden muss. Da macht es natürlich Sinn die Abfrage entsprechend auf eine sid einzugrenzen. In einer RAC Umgebung müsste man übrigens auch noch die Instanz ID (inst_id) des entsprechenden Nodes mitgeben. Da SAP-Systeme eher selten auf RAC Umgebungen betrieben werden gehe ich nicht weiter darauf ein.

Das könnte etwa so aussehen:
[Read more…]

Invaild Objects nach einem Oracle Upgrade

Während eines Oracle Upgrades kann es vorkommen, dass nach dem Upgrade Objekete ungültig sind. Das ist normal und das kennt man (eigentlich) auch.

Während der PRE Upgrade Phase wird quasi einen Bestandsaufnahme der (ungültigen) Objekte vorgenommen, die nach dem Upgrade mit dem dann vorherrschenden Objektzustand verglichen wird (Post Upgrade Phase). Sollte es hier zu einer Differenz kommen so muss diese bearbeitet werden.

Dies wird normaler weise über das Script $ORACLE_HOME/rdbms/admin/utlrp.sql erledigt. Wenn die entsprechenden Objekte hier jedoch nicht berücksichtigt werden und man trotzdem Meldungen wie unten gezeigte bekommt muss eine andere Lösung her. Mit den Standardscripten kommt man hier leider nicht weiter.

Der View ist nicht mehr gültig, damit ist dann auch das Synonym, das auf den View zeigt, defekt. Das Einfachste ist jetzt auf den View zuzugreifen. In der Regel wird er dann – wenn noch nicht geschehen – kompiliert. Funktionier dies nicht wird der View eben neu kompiliert.
[Read more…]

SAP und die Suche der Passworthistorie

Wenn man wissen möchte, wie es um das Passwort eines Benutzers steht, wann er es das letzte mal geändert hat oder wann ein Account gelöscht worden ist hat man zwei Möglichkeiten:

1) Man(n) bedient sich der Tools, die SAP hierfür bereit stellt (TA: SU01 etc.)
2) Man(n) wirft einen schnellen Blick in die Datenbank

Zu 1) muss ich glaube ich nichts schreiben, die Transaktion als eine der Standard Transkation im SAP sollte hinläufig bekannt sein.

Bei 2) sieht die Sache ggf. schon wieder ganz anders aus. Wir orientieren uns hier zunächst an der Tabelle USR02. Kurz mit der Datenbank verbinden und erst mal schauen was in der Tabelle so alles drin steht:

SQL> descr <SCHEMA>.USR02
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 MANDT                                     NOT NULL VARCHAR2(9)
 BNAME                                     NOT NULL VARCHAR2(36)
 BCODE                                              RAW(8)
 GLTGV                                     NOT NULL VARCHAR2(24)
 GLTGB                                     NOT NULL VARCHAR2(24)
 USTYP                                     NOT NULL VARCHAR2(3)
 CLASS                                     NOT NULL VARCHAR2(36)
 LOCNT                                     NOT NULL NUMBER(3)
 UFLAG                                     NOT NULL NUMBER(3)
 ACCNT                                     NOT NULL VARCHAR2(36)
 ANAME                                     NOT NULL VARCHAR2(36)
 ERDAT                                     NOT NULL VARCHAR2(24)
 TRDAT                                     NOT NULL VARCHAR2(24)
 LTIME                                     NOT NULL VARCHAR2(18)
 OCOD1                                              RAW(8)
 BCDA1                                     NOT NULL VARCHAR2(24)
 CODV1                                     NOT NULL VARCHAR2(3)
 OCOD2                                              RAW(8)
 BCDA2                                     NOT NULL VARCHAR2(24)
 CODV2                                     NOT NULL VARCHAR2(3)
 OCOD3                                              RAW(8)
 BCDA3                                     NOT NULL VARCHAR2(24)
 CODV3                                     NOT NULL VARCHAR2(3)
 OCOD4                                              RAW(8)
 BCDA4                                     NOT NULL VARCHAR2(24)
 CODV4                                     NOT NULL VARCHAR2(3)
 OCOD5                                              RAW(8)
 BCDA5                                     NOT NULL VARCHAR2(24)
 CODV5                                     NOT NULL VARCHAR2(3)
 VERSN                                     NOT NULL VARCHAR2(9)
 CODVN                                     NOT NULL VARCHAR2(3)
 TZONE                                     NOT NULL VARCHAR2(18)
 ZBVMASTER                                 NOT NULL VARCHAR2(3)
 PASSCODE                                           RAW(20)
 PWDCHGDATE                                NOT NULL VARCHAR2(24)
 PWDSTATE                                  NOT NULL NUMBER(3)
 RESERVED                                  NOT NULL NUMBER(3)
 PWDHISTORY                                NOT NULL NUMBER(3)
 PWDLGNDATE                                NOT NULL VARCHAR2(24)
 PWDSETDATE                                NOT NULL VARCHAR2(24)
 PWDINITIAL                                NOT NULL NUMBER(3)
 PWDLOCKDATE                               NOT NULL VARCHAR2(24)
 PWDSALTEDHASH                             NOT NULL VARCHAR2(765)
 SECURITY_POLICY                           NOT NULL VARCHAR2(120)

[Read more…]

LONG-Field Tabellen und die online Reorganisation

Wenn man einen Tablespace reorganisieren möchte kann man dies in der Regel online als auch offline tun. Beide Verfahren haben ihre Vor- und Nachteile. Bei der online Reorganisation von Tabellen gibt es jedoch eine Einschränkung bzgl. Tabellen mit Feldern vom Typ LONG. Diese können nicht online reorganisiert werden. Bei moderneren Systemen (Neuinstallation >= Kernel 7.00) kommen LONG-Fields nicht mehr vor bzw. die Systeme werden ohne LONG-Felder ausgeliefert. Bei älteren Systemen muss man sich entweder mit einem Export/Import der Tabellen behelfen oder aber die LONG-Fields in LOBs umwandeln. Aber Achtung, je nach Release kann es hier zu Nebeneffekten kommen. Sofern man ein historisch gewachsenes System hat, das über einen Kernel >= 7.00 sowie Oracle 10g verfügt kann man die LONG-Fields jedoch einfach konvertieren. Das geht sogar online und muss lediglich einmal gemacht werden. Der online Reorganisation von Tabellen steht dann nichts mehr im Wege.

Zunächst kann man recht einfach prüfen ob es denn überhaupt LONG-Fields in den Tabellen gibt, die umgesetzt werden müssen.

SQL> select TABLE_NAME, COLUMN_NAME from dba_tab_columns where owner='<Schema-Owner>' and data_type = 'LONG';

TABLE_NAME                     COLUMN_NAME
------------------------------ ------------------------------
GVD_OBJECT_DEPEN               TO_NAME
GVD_SQL                        SQL_TEXT
GVD_SQLAREA                    SQL_TEXT
ORA_RESUMABLE                  SQL_TEXT
PLAN_TABLE                     OTHER

SQL>

[Read more…]

Oracle! Wie lange brauchst du denn noch?

Wenn eine Aktion im Oracle mal wieder länger dauert (select, update, insert, delete, rman-Backup etc.) kann man in den v$-Tabellen von Oracle sehr einfach und schnell sehen was gerade gemacht wird und wie lang die Aktion geschätzt noch dauern wird. Das alles verbrigt sich hinter der Tabelle v$session_longops.

SQL> descr v$session_longops
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 SID                                                NUMBER
 SERIAL#                                            NUMBER
 OPNAME                                             VARCHAR2(64)
 TARGET                                             VARCHAR2(64)
 TARGET_DESC                                        VARCHAR2(32)
 SOFAR                                              NUMBER
 TOTALWORK                                          NUMBER
 UNITS                                              VARCHAR2(32)
 START_TIME                                         DATE
 LAST_UPDATE_TIME                                   DATE
 TIMESTAMP                                          DATE
 TIME_REMAINING                                     NUMBER
 ELAPSED_SECONDS                                    NUMBER
 CONTEXT                                            NUMBER
 MESSAGE                                            VARCHAR2(512)
 USERNAME                                           VARCHAR2(30)
 SQL_ADDRESS                                        RAW(8)
 SQL_HASH_VALUE                                     NUMBER
 SQL_ID                                             VARCHAR2(13)
 SQL_PLAN_HASH_VALUE                                NUMBER
 SQL_EXEC_START                                     DATE
 SQL_EXEC_ID                                        NUMBER
 SQL_PLAN_LINE_ID                                   NUMBER
 SQL_PLAN_OPERATION                                 VARCHAR2(30)
 SQL_PLAN_OPTIONS                                   VARCHAR2(30)
 QCSID                                              NUMBER

SQL>

Mich interessieren hierbei primär die Felder SID, OPNAME, TARGET, SOFAR, TOTALWORK, ELAPSED_SECONDS sowie TIME_REMAINING.

Das ganze sieht dann z.B. so aus:

SQL> set lines 200 pages 200
SQL> select SID,OPNAME,TARGET,SOFAR,TOTALWORK,ELAPSED_SECONDS,TIME_REMAINING from v$session_longops where TIME_REMAINING > 0;

       SID OPNAME                                                           TARGET                                                                SOFAR  TOTALWORK ELAPSED_SECONDS TIME_REMAINING
---------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------- ---------- --------------- --------------
       837 Index Fast Full Scan                                             SAPERP.IHPA                                                           60505     161488              11             18

SQL>

Wenn man die die where-Klausel aus dem Statement entfernt bekommt man eine Übersicht über die letzten Aktionen der aktiven Sessions und bei dem gezeigten Statement ihrer Laufzeit.

Nützliche Sybase Helferlein

Hier eine kleine Sammlung an nützlichen Tipps rund um die Sybase Datenbank für die alltägliche Benutzung. Ist man bereits an Oracle gewöhnt kommt man mit ein bisschen Eingewöhnung auch ganz gut mit der Sybase Datenbank zurecht 😉

Datenbanken in der Systemumgebung aufspüren per dblocate:

[sybase@server]$ dblocate
SQL Anywhere Server Enumeration Utility Version 16.0.0.807
Server Name        Address
-----------        -------
sapdb01            sybaseprod.domain.org:2640
sapdb02            sybasekons.domain.org:2650
sapdb03            sybaseentw.domain.org:2640

Sybase Shell Login ähnlich sqlplus bei Oracle:

dbisql -d1 -nogui -c "uid=;pwd=;dbn=sapdb03;eng=sapb01;links=tcpip"

Systable auslesen und die Ausgabe in eine Datei umlenken:

(DBA)> select * from sys.systable; output to systable.txt;
Execution time: 0.015 seconds
Exporting data to "/sybase/systable.txt.txt"
428 rows written to "/sybase/systable.txt.txt"
Execution time: 0.44 seconds

(DBA)> exit

Systembenutzer auslesen und die Ausgabe in eine Datei umlenken:

(DBA)> select * from sys.sysuser; output to syuser.txt
Execution time: 0.016 seconds
Exporting data to "/sybase/syuser.txt"
118 rows written to "/sybase/syuser.txt"
Execution time: 0.033 seconds

(DBA)> exit

[Read more…]

SAP BDLS Umsetzungen direkt über Oracle mit sqlplus – schneller gehts immer!

Beim Umsetzen von logischen Systemnamen im SAP mittels der Transaktion BLDS kann es trotz Indizes vorkommen, dass ein Lauf einfach zu lange benötigt – oder im Extremfall (gerade erlebt) der Rückgabewert der Menge der umzusetzenden logoischen Systemnamen so groß ist, dass die Variable die Zahl nicht aufnehmen kann und die BLDS mit einem Kurzdump einfach aussteigt. Es muss also nicht immer an der Größe der Datenbank oder der Systemperformance liegen wenn die BLDS streikt. Das komplette Vorgehen kann man extrem beschleunigen wenn man an der BDLS Funktionalität vorbei direkt auf der Datenbank die Umsetzung der Tabelle vorgenommen wird. Im sqlplus kommt man jedoch mit einem einfachen Update Statement nicht schneller als die BDLS selbst ans Ziel. Das Zaubertool der Wahl heißt in diesem Fall CTS – create table as.

Das Vorgehen ist recht einfach aber sehr effektiv und schnell. Man teilt dem Oracle lediglich mit, dass man eine neue Tabelle erstellen möchte und gibt die Referenzen auf eine bestehende Tabelle an. Den Rest erledigt das System selbst – parallelisiert und sehr schnell. Das Updaten einer Tabelle mit mehreren Milliarden Einträgen und einer größe von mehr als einem TB kann schon mal Tage benötigen. Mit dem CTS hat man die Tabelle in wenigen Stunden neu aufgebaut und auch gleich die gewünschten Feldinhalte verändert.

Das Vorgehen sieht inetwa so aus:

1) Ermitteln der Quelltabelle mit den Feldnamen für die logischen Systeme
2) Neuaufbau der Tabelle
3) Nacharbeiten an der Tabelle
4) Umbennen/Ersetzen der Tabellen
5) Neuaufbau der Indizes zu den Tabellen
6) Löschen der alten Tabelle

Ermitteln der Quelltabelle mit den Feldnamen für die logischen Systeme:
Aus den BDLS Protokollen weiß man jetzt zum Beispiel, dass im BW eine Tabelle mit über 2 MRD Einträgen existiert, die umgesetzt werden soll:
„/BIC/ZPWE“ mit den Feldern LOGSYS und AWSYS, die die logischen Systemnamen beinhalten und umgesetzt werden sollen.

Neuaufbau der Tabelle:
Das Statement zum Neuaufbau könnte dann so aussehen:
[Read more…]

Userexport und Userimport per SAP R3trans

Zuweilen kommt es immer mal wieder vor, dass man einzelne Benutzer aus einem System in ein Anderes übernehmen möchte oder einfach nur einen Benutzer aus einem Mandanten auf einem lokalen System in einem anderen Mandanten kopieren möchte.

Ein kompletter Mandantenexport wäre hier eine Möglichkeit. Quick und Dirty geht es allerdings per R3trans.

Hierzu legen wir uns zunächst zwei Dateien an:

userexport.exp
export
client=100
file="/tmp/userexport.dat"
compress=no
select * from usr01 with key '000USER'
select * from usr02 with key '000USER'
select * from usr04 with key '000USER'
select * from ust04 with key '000USER'

[Read more…]