Connexion interne au moteur
- Détails
- Catégorie : Retroracle
- Publié le mercredi 30 janvier 2013 20:31
- Écrit par Administrator
- Affichages : 9686
[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 doc
... mieux vaut tard que jamais
# 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é..