Oracle et les paramètres cachés...

Oracle est un petit cachottier qui comporte des paramètres "cachés". Il s'agit de tous les paramètres dont le nom commence par _.
En théorie, on ne doit setter ces paramètres que sur demande du support, mais j'ai découvert que parfois une simple note metalink suggère de setter l'un ou l'autre de ces paramètres...
Or, je n'aime pas setter un paramètre si je ne sais pas quelle valeur il a auparavant.

Consulter les paramètres cachés

J'ai trouvé une petite requête sur internet que j'ai améliorée à ma sauce pour donner ceci :

set lines 200
set pages 100
col NAME format a20
col TYPE format 9999
col VALUE format a20
col ISDEFAULT format a20
SELECT ksppinm AS NAME,ksppity AS TYPE,ksppstvl AS VALUE,ksppstdf AS ISDEFAULT
FROM x$ksppi x INNER JOIN x$ksppcv y ON (x.indx = y.indx)

Finalement, le TYPE n'est pas une info très intéressante, ou alors il faudrait refaire une jointure avec la table des types pour savoir ce qu'elle vaut vraiment.
Il n'y a plus qu'à rajouter votre clause 'WHERE ksppinm LIKE '''.
Les noms de paramètres sont stockées en minuscules.

Setter un paramètre caché

Comme pour un paramètre normal, il faut utiliser l'ordre ALTER SYSTEM SET... Il suffit de penser à mettre le nom du paramètre caché entre double quotes.

Faire redémarrer l'observer au reboot de la machine

Ben oui, c'est bête. Vous avez installé votre Data Guard, votre observer est démarré, tout baigne! Mais la machine reboot et l'observer ne se lance pas automatiquement! Ben oui, vous avez oublié ce point de détail.

Scripter

On commence par faire un script pour démarrer l'observer. (Appelons-le start_observer.sh, au hasard.)

export PATH="$PATH:oracle_home/bin";
export ORACLE_HOME="oracle_home";

dgmgrl -logfile logfile  << eof
connect /@alias
stop observer;
start observer;
eof

Tant qu'on y est, on va aussi scripter l'arrêt :

export PATH="$PATH:oracle_home/bin";
export ORACLE_HOME="oracle_home";

dgmgrl -logfile logfile  << eof
connect /@alias
stop observer;
eof

On remarquera l'utilisation intelligente des wallets ;-).

init.d

On va ensuite dans le magnifique répertoire init.d et on y met notre superbe script (dont on est très fier(e)), son petit nom est oraobserver chez moi) :

#!/bin/bash
### BEGIN INIT INFO
# Provides: oraobserver
# Required-Start:
# Required-Stop:
# Default-Start:  3 4 5
# Default-Stop: 0 1 6
# Short-Description: Lance l'observer Oracle
# Description: Lance l'observer de la config Data Guard
### END INIT INFO
#
# source function library
. /etc/rc.d/init.d/functions


RETVAL=0


start() {
echo -n $"Starting Oracle Observer : \n"
nohup /home/oracle/start_obs.sh &
}


stop() {
echo -n $"Stopping Oracle Observer: \n"
/home/oracle/stop_obs.sh
RETVAL=$?
}


restart() {
stop
start
}


case "$1" in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
*)
echo $"Usage: $0 {start|stop|restart}"
exit 1
esac


exit $RETVAL

On n'oublie pas de rendre le fichier exécutable.

Test

On peut tester le script en faisant :

/etc/init.d/oraobserver stop
/etc/init.d/oraobserver start
/etc/init.d/oraobserver restart

chkconfig

Ensuite, il suffit de dire à chkconfig d'ajouter ce service au démarrage :

chkconfig --add oraobserver

On peut ensuite vérifier les niveaux de démarrage en faisant :

chkconfig --list

Jouer avec les Wallet

Oracle permet de stocker les mots de passe dans des "wallets" sécurisés ce qui permet par la suit de se connecter sans saisir ni login ni mot de passe.

Création du Wallet

On commence par créer le wallet et son mot de passe. (Il faut que le mot de passe satisfasse les conditions de sécurité Oracle)

mkstore -wrl "dir" -create

dir est le répertoire où vous allez stocker tous les fichiers du Wallet

Ajout d'un alias

On ajout un alias au Wallet ainsi :

mkstore -wrl dir -createCredential ALIAS user psswd

Au prompt, il faut donner le mot de passe du wallet.

Il faut ensuite rajouter une entrée dans le tnsnames qui comporte l'alias donné au Wallet.

Liste des alias

Pour lister les alias déjà connus :

mkstore -wrl dir -listCredential

Au prompt, il faut donner le mot de passe du wallet.

Supprimer un alias

C'est tout simplement :

mkstore -wrl dir -deleteCredential ALIAS

Au prompt, il faut donner le mot de passe du wallet.

Créer un user en lecture seule sur un autre schéma

C'est une demande fréquente : les développeurs souhaitent avoir un user en lecture seule sur les objets d'un autre schéma...

Le rôle

Encore et toujours, on commence par créer le rôle correspondant à ces droits :

CREATE ROLE role_name NOT IDENTIFIED;
GRANT CONNECT TO role_name;
GRANT CREATE SESSION TO role_name;
GRANT RESOURCE TO role_name;
GRANT CREATE SYNONYM TO role_name;
GRANT UNLIMITED TABLESPACE TO role_name;

Il faut ensuite récupérer les GRANT SELECT à effectuer, c'est possible grâce à ces requêtes :

SELECT 'GRANT SELECT ON schema.'||TABLE_NAME||' TO role_name;' FROM dba_tables WHERE owner='owner';
SELECT 'GRANT SELECT ON schema.'||VIEW_NAME||'TO role_name;' FROM dba_views WHERE owner='owner';

Le user

On crée alors le user :

CREATE USER user_name IDENTIFIED BY pswd DEFAULT TABLESPACE tbs_name;Et on le grant :

GRANT role TO user;
GRANT UNLIMITED TABLESPACE TO user;

Synonymes

la création de synonymes n'est pas obligatoire mais facilite la vie du user... Autant le faire ! Il faut exécuter le résultat de ces deux requêtes :

SELECT 'CREATE SYNONYM ' ||TABLE_NAME|| ' FOR schema.' ||TABLE_NAME||';' FROM ALL_TABLES WHERE OWNER='owner';
SELECT 'CREATE SYNONYM ' ||VIEW_NAME|| ' FOR schema.' ||VIEW_NAME||';' FROM ALL_VIEWS WHERE OWNER='owner';

Et voilà!

Gestion des users "standards" sous Oracle

Tu es content, tu as fini d'installer et de configurer ta plateforme Oracle... Et là, on te demande un user standard avec tous les droits sur son schéma.
Comme d'habitude tu ne fais que de la migration, tu ne sais pas trop comment faire...
Respire, ça va bien se passer!

Les rôles, pensez-y!

Les rôles ont été créés par Oracle pour simplifier l'attribution des mêmes droits à plusieurs utilisateurs. Et même si aujourd'hui on ne te demande qu'un seul utilisateur, tu auras l'air malin si dans 2 ans on t'en demande un autre avec les mêmes droits!

Voilà les droits à "granter" pour obtenir un rôle permettant un accès total à tous les objets de son propre schéma :

CREATE ROLE role_name NOT IDENTIFIED;
GRANT CONNECT TO role_name;
GRANT CREATE SESSION TO role_name;
GRANT RESOURCE TO role_name;
GRANT CREATE CLUSTER TO role_name;
GRANT CREATE INDEXTYPE TO role_name;
GRANT CREATE OPERATOR TO role_name;
GRANT CREATE PROCEDURE TO role_name;
GRANT CREATE SEQUENCE TO role_name;
GRANT CREATE TABLE TO role_name;
GRANT CREATE TRIGGER TO role_name;
GRANT CREATE TYPE TO role_name;
GRANT UNLIMITED TABLESPACE TO role_name;

Et les tablespaces ???

Ne pas oublier de créer des tablespaces pour mettre les données du user. Cette étape est facultative, mais recommandée.

CREATE TABLESPACE tbs__dbo_indx01 DATAFILE '+_INDX' SIZE your_size AUTOEXTEND ON NEXT your_next_extend_size MAXSIZE your maxsize_or_unlimited;

CREATE TABLESPACE your_tbs_name DATAFILE 'your_datafile_path' SIZE your_datafile_size AUTOEXTEND ON  NEXT your_next_extend_size MAXSIZE your_max_size_or_unlimited;

Enfin, le user

Il n'y a plus qu'à créer le user

CREATE USER user_name IDENTIFIED BY your_psswd DEFAULT TABLESPACE your_tbs_name ;

Et lui donner les droits :

GRANT your_role TO user;
GRANT UNLIMITED TABLESPACE TO user;

Archive logs

Ce qu'on appelle couramment des archive logs en Oracle sont en fait des archives des redo logs. C'est l'équivalent des WAL de postgreSQL.

Purge

Bien sûr ces archive logs s'amoncellent; Le mieux est de purger les fichiers obsolètes grâce à la commande suivante (sous Rman).

DELETE OBSOLETE;

(Hé oui, des fois Oracle, c'est simple).
Le mieux est de rajouter cette commande après chaque sauvegarde.
Si Oracle était totalement planté suite à full, il y a de grandes chances qu'rman refuse de se connecter à votre base. Vous pouvez alors supprimer les fichiers les plus anciens à la main (sous ASM ou sur filesystem) et ensuite n'oubliez surtout pas d'exécuter cette commande :

CROSSCHECK ARCHIVELOG ALL

(Sous ASM, les archive logs sont "cachés" sous des répertoires ayant pour format yyyy_mm_dd).
Si vous ne trouvez pas d'archive logs obsolètes et que vous avez vraiment besoin de place, vous pouvez aussi tenter la commande suivante (en vous assurant que le chef de projet est conscient des risques) :

DELETE ARCHIVELOG ALL COMPLETED BEFORE 'your_date';

Politique de retention

Comment fait Rman pour savoir si un fichier est obsolète ? C'est là qu'il faut aller voir du côté de la politique de rétention. Vous pouvez soit définir un nombre de fichiers à conserver, soit définir une fenêtre de temps à conserver.
On peut voir sa politique de rétention en faisant

SHOW RETENTION POLICY;

Par défaut, Rman considère qu'un seul backup de chaque fichier est nécessaire.
Voilà comment lui dire de conserver n version(s) de chaque fichier :

CONFIGURE RETENTION POLICY TO REDUNDANCY n;

Voilà pour donner une durée de rétention de n jours :

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF n DAYS;

Politique de suppression

Ah bah oui, pourquoi il ferait pas tout tout seul notre Rman adoré?
Par défaut la politique de suppression n'est pas settée. Vous pouvez décider par exemple de supprimer tous les archives logs d'une instance maître s'ils ont été appliqués sur la standby:

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;

Vérifier qu'une standby applique bien les logs (Oracle)

J'ai testé ces vérifications sur une standby physique, je ne suis pas sûre que cela fonctionne sur une standby logique.

Numéro de séquence

On commence par vérifier le numéro de séquence en cours avec cette requête sur le maître et l'esclave :

ARCHIVE LOG LIST

Il va répondre quelque chose de ce genre :

Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     2794
Next log sequence to archive   2796
Current log sequence           2796

On peut ensuite demander au maître de changer de numéro de séquence :

ALTER SYSTEM SWITCH LOGFILE;

Et revérifier les numéros de séquence!

Mrp0

Le process qui applique les redos sur la standby s'appelle mrp0. Si vous requêtez la vue v$managed_standby, vous pourrez voir dans quel état il est :

SELECT process, client_process, sequence#, status FROM V$managed_standby WHERE process='MRP0';

S'il vous répond "no rows selected", il faut le démarrer avec un ordre du genre :

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

S'il vous répond "Applying log", tout va bien.

Recovery mode

Vous pouvez vérifier le "recovery mode" ainsi :

SELECT recovery_mode FROM v$archive_dest_status WHERE dest_id=2 ;

Quelques statistiques

Voici deux requêtes vous permettant de récupérer des stats parfois utiles :

SELECT * FROM v$dataguard_stats;
SELECT start_time, item, units, sofar FROM V$recovery_progress ORDER BY 1, 2;