Connexion interne au moteur

[MAJ 31/01/2014 : ajout de la version 12c]

Qui se souvient de la façon de se connecter en interne sur le moteur Oracle antérieur à la version 7 ?... pas moi. En revanche je me souviens du svrmgrl et même du sqldba de la version 7.

A travers les versions,  les méthodes et/ou utilitaires pour se connecter en interne, c'est-à-dire sans passer par un user oracle qui nécessite donc que la base soit ouverte, ont changées.  Voyons comment cela a changé à travers les versions. Encore un article qui ne fera pas avancer le schmilblick mais qui je suis sûr va vous  passionner !

 

ORACLE 6

Je ne connais pas cette version, mais d’après la documentation Oracle7_ Installation Guide for AIX Release 7.3.4 ( document oracle :November 1997 Part No. A57643–01 page 183), il semble que pour se connecter en interne sur une version 6 la commande à utiliser soit sqldba :

# sqldba lmode=y
SQLDBA> connect internal

 

ORACLE 7 et 8.0

En version 7, il fallait utiliser la commande sqldba (SQL*DBA) ou bien la commande svrmgrl (Server Manager in Line). Cela dépendait de la version de la 7. En 8.0 c’était svrmgrl.

Sur UNIX, pour la 7.1 et 7.2, comme pour la version 6 c’est sqldba :

# sqldba lmode=y
SQLDBA> connect internal

 

Toujours sur UNIX pour la version 7.3 et 8.0, c’est svrmgrl :

# svrmgrl
SVRMGR> connect internal

 

Mais pour Windows se rajoutait  une complexité supplémentaire. Le principe cité ci-dessus restait vrai (sqldba ou svrmgrl), mais la fin du nom l’exécutable changeait.

Pour les versions 7.x :

7.1.x à sqldba71

7.2.x à sqldba72

7.3.x à svrmgr23

 

Pour la version 8.0.x :

DOS> svrmgr30
SVRMGR> connect internal

 

Cette différence entre UNIX et Windows, venait du fait que sur Windows, il ne pouvait y avoir qu’un seul répertoire ORACLE_HOME (vrais  jusqu’en 8.0 inclus), donc les noms d’exécutable devaient se différentier par leur nom. Par exemple svrmgr23 c’est la version 2.3 du server manager.

 

Remarque :
Comme aujourd’hui avec la connexion sysdba, si le compte authentifié sur l’OS appartenait au groupe dba, la commande « connect internal » ne demandait pas de mot de passe, sinon il exigeait un  mot de passe stocké dans le fichier orapwd.

 

ORACLE 8i

Avec la 8i, Oracle supporte l’installation de plusieurs moteurs sur Windows dans plusieurs ORACLE_HOME.  Du coup sous Windows, comme déjà sous UNIX, l’exécutable  « server manager » , se nomme svrmgrl, il ne porte plus sa version dans son nom.

La commande « connect internal » ne devait plus être utilisé mais  elle était encore supportée pour compatibilité (Administrator’s Guide Release 2 (8.1.6) December 1999 Part No. A76956-01)… je ne le savais même pas… je viens de le découvrir en lisant la docEmbarassed... mieux vaut tard que jamaisTongue Out

# svrmgrl
SVRMGR> connect sys/xxxx as sysdba

Cependant la version Oracle8i Personal Edition, se distingue avec un son « server manager » nommé svrmgr (pas de la l).

Depuis au moins cette version, il existe un deuxième rôle pour se connecter à la base c'est sysoper. Il existait sur la 8i cela est sûr mais peut être aussi sur les versions précédentes. Ce rôle a moins de droits que sysdba, il peut manager la base au niveau opérateur système (stop start de la base par exemple) mais n’a aucun droit au niveau des objets applicatifs, il hérite juste des droits PUBLIC sur la base.

# svrmgrl
SVRMGR> connect oper1/xxxx as sysoper

 

ORACLE 9i

En 9i, svrmgrl est abandonné, et la connexion « connect internal » devient définitivement obsolète.

Maintenant tout se fait sous sqlplus :

# sqlplus /nolog
SQL> connect /  as sysdba

La connexion en interne peut se faire directement en une seule commande:

# sqlplus « / as sysdba »

(guillemets obligatoires)

 

ORACLE 10g et 11g

Le seul changement par rapport à la 9i est que les guillemets ne sont plus obligatoires :

# sqlplus / as sysdba

Mais la commande avec les guillemets fonctionne toujours.

 

ORACLE 12c

Avec la 12c, il n’y a pas de nouveauté sur la « technique » de se connecter au moteur  cela reste toujours sous sqlplus

La grosse nouveauté  par rapport aux anciennes versions c’est l’arrivée de 3 nouveaux « rôles » en plus des anciens sysdba et sysoper : SYSBACKUP, SYSDG et SYSKM.  

Pour se connecter avec un rôle d’administrateur de backup :

# sqlplus / as sysbackup

Pour se conencter avec un rôle d’admnistrateur de dataguard :

# sqlplus / as sysdg

Pour se connecter avec un rôle d’administrateur de clefs

# sqlplus / as syskm

 

Passionnant non? ce retour dans le passé..