CREATE USER user
IDENTIFIED {BY passwort | EXTERNALLY}
[ DEFAULT TABLESPACE tablespace ]
[ TEMPORARY TABLESPACE tablespace ]
[ QUOTA {integer [K | M] | UNLIMITED } ON tablespace
[ QUOTA {integer [K | M] | UNLIMITED } ON tablespace
] ... ]
[ PASSWORT EXPIRE ]
[ ACCOUNT { LOCK | UNLOCK} ]
[ PROFILE { profile | DEFAULT } ]
;
BY passwort - Die Authentifizierung erfolgt mittels Passwort.
create user name identified by password default tablespace tbs_1 default temporary tablespace temp quota 10M on tbs_1 qutoa 10M on index_tbs password expire ;
OS_AUTTHENT_PREFIX =OPS$"
create user "OPS$domain\user" identified externally;Unix-Shell
sqlplus /
Um die Nutzung der Passwortdatei einzurichten, ist es notwendig, den Initialisierungsparameter REMOTE_LOGIN_PASSWORDFILE zu ändern. Normalerweise zeigt dieser den Wert NONE an. Für die Nutzung der Passwortdatei muss er den Wert EXCLUSIVE aufweisen. Dieser Parameter ist nicht dynamisch. Ändern Sie den Initialisierungsparameter, indem Sie den Befehl
ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE SCOPE=SPFILE;eingeben. Starten Sie Ihre Instanz neu.
Melden Sie sich nunmehr mit dem Privileg SYSDBA an. Verschieben Sie Ihre Passwortdatei pwdSID.ora an einen beliebigen anderen Ort (den Sie sich natürlich merken). Melden Sie sich nun von Ihrer Datenbank ab und erneut als SYSDBA an. Ohne Passwortdatei haben Sie nun ein Problem, obwohl Sie über das Privileg SYSDBA verfügen. Eine Meldung, dass Sie nicht über die notwendigen Berechtigungen verfügen verdeutlicht Ihnen die unschöne Situation.
Kopieren Sie die Passwortdatei wieder an Ihren ursprünglichen Ort. Wenn Sie neue Benutzer anlegen und Ihnen das Privileg SYSDBA zuweisen, übernimmt die Passwortdatei die Authentifizierung der Benutzer - aber nur derer, denen das Privileg SYSDBA oder SYSOPER zugewiesen wurde. Gibt es keine Passwortdatei, stehen Ihnen die Privilegien SYSDBA und SYSOPER nicht zur Verfügung und können auch nicht Benutzern zugewiesen werden (unter Privilegien tauchen sie gar nicht auf). Eine Passwortdatei erstellen Sie auf BETRIEBSSYSTEMEBENE - also nicht unter SQL - mit dem Befehl
$orapwd file=$ORACLE_HOME/dbs/orapwDB01 password=orapass entries=5Die Passwortdatei muss immer im Verzeichnis $ORACLE_HOME/dbs liegen, um genutzt werden zu können. Der Name ist festgelegt auf pwdSID.ora - also pwdtestdb.ora.
Der Parameter password = gibt das Kennwort an, das in der Datei gespeichert wird. Die Wahl des Kennwortes ist beliebig (also z.B. password=geheim). Dieses Passswort wird nicht bei der Anmeldung eingegeben. Es wird nur intern verwendet. Der Parameter entries = legt fest, wie viele Passworteinträge in diese Datei vorgenommen werden können. In unserem Beispiel liegt die Obergrenze bei 20. Mehr SYSDBAs oder SYSOPERs darf es also nicht geben.
Bitte planen Sie Ihre Passwortdatei so, dass alle Benutzer hineinpassen, die als SYSDBA oder SYSOPER fungieren sollen. Eine Erweiterung der Passwortdatei um weitere Einträge ist nämlich nicht möglich. Sollten die möglichen Einträge (entries) nicht ausreichen, müssen Sie eine neue Datei erstellen! Bitte beachten Sie auch, dass dann alle SYSDBA und SYSOPER-Privilegien neu zugewiesen werden müssen. Die bereits bestehenden Privilegien verlieren ihre Gültigkeit. Problematisch stellt sich auch immer die Änderung der Privilegien für den Benutzer SYS dar.
Folgende Reihenfolge ist bei Erstellung einer Passwortdatei zwingend:
sqlplus "/as sysdba"Diese Berechtigung wird primär über die Zugehörigkeit zur Unix-Gruppe der DBAs geregelt. Der Name dieser Gruppe ist in den meisten Fällen dba. Im Zweifel sieht man sich die Zugehörigkeit der Dateien unterhalb von $ORACLE_HOME an, der Besitzer der Dateien ist fast sicher der administrative Datenbankbenutzer. Die genaue Bezeichnung der DBA-Gruppe findet sich in
/* SS_DBA_GRP defines the UNIX group ID for adminstrative access. */
/* Refer to the Installation and User's Guide for further information. */
#define SS_DBA_GRP "dba"
#define SS_OPER_GRP "dba"
char *ss_dba_grp[] = {SS_DBA_GRP, SS_OPER_GRP};
Lösungsvarianten
Active Directory
Domain
Users
ORA_DBA -- hau weg
Deshalb sollten, ausser auf Undo- und Temporary-Tablespace, Quotas immer angeben werden.
alter user anna quota 0 on tbs_1;Wenn Quota verkleinert wird, werden Daten aber nicht gelöscht.
drop user anna cascade;cascade - Alle Objekte des Schemas werden auch gelöscht.
describe dba_users; select username,default_tablespace from dba_users;DBA_TS_QUOTAS
select * from DBA_TS_QUOTAS where username ='anna';
Stefan Hietel dama.go GmbH, Robert Warnke http://rowa.giso.de