Rechercher sur arkzoyd.com

27 octobre 2007

Pré-requis d'installation sur Linux : RPMs x86_64 ou i386

Il faut connaître la version des RPMs installés sous Redhat ou Oracle Enterprise Linux ; c'est très utile si vous fonctionnez avec Linux x86-64 dans la mesure ou Oracle utilise aussi des RPMs 32bits. 2 points à mémoriser (ou bookmarker !) :
  • L'ensemble des pré-requis est toujours mis à jour dans la note 169706.1 qui contient désormais, par exemple, les infos pour Oracle Enterprise Linux 5 ou Oracle 11g
  • La commande suivante où vous remplacerez sysstat par le package que vous cherchez :
rpm -qa --queryformat \
"%{NAME}-%{VERSION}-%{RELEASE} (%{ARCH})\n" \
|grep sysstat

16 octobre 2007

Modifier les fenêtres de maintenance

Juste un post rapide pour montrer comment modifier les fenêtres de maintenance d'Oracle 10g à la main et ainsi, si vous utilisez les travaux automatiques (statistiques, sauvegardes...), changer leur planification...

1- D'abord quelles sont les fenêtres programmées ?
set lines 120
col WINDOW_NAME format a16
col DURATION format a14
col REPEAT_INTERVAL format a70
select WINDOW_NAME,REPEAT_INTERVAL,DURATION, ENABLED
from dba_scheduler_windows;

WINDOW_NAME REPEAT_INTERVAL DURATION ENABL
---------------- ---------------------------------------------------------------------- -------------- -----
WEEKNIGHT_WINDOW freq=daily;byday=MON,TUE,WED,THU,FRI;byhour=22;byminute=0;bysecond=0 +000 08:00:00 TRUE
WEEKEND_WINDOW freq=daily;byday=SAT;byhour=0;byminute=0;bysecond=0 +002 00:00:00 TRUE
2- Modifiez les attributs "repeat_interval" et "duration" des 2 fenêtres
exec dbms_scheduler.set_attribute(-
name=>'WEEKNIGHT_WINDOW', -
attribute=>'repeat_interval', -
value=>'freq=daily;byday=MON,TUE,WED,THU,FRI,SAT;byhour=0;byminute=0;bysecond=0')

exec dbms_scheduler.set_attribute(-
name=>'WEEKNIGHT_WINDOW', -
attribute=>'duration', -
value=>'+000 06:00:00')

exec dbms_scheduler.set_attribute(-
name=>'WEEKEND_WINDOW', -
attribute=>'repeat_interval', -
value=>'freq=daily;byday=SUN;byhour=0;byminute=0;bysecond=0')

exec dbms_scheduler.set_attribute(-
name=>'WEEKEND_WINDOW', -
attribute=>'duration', -
value=>'+001 00:00:00')
3- Validez les modifications
WINDOW_NAME      REPEAT_INTERVAL                                                             DURATION       ENABL
---------------- --------------------------------------------------------------------------- -------------- -----
WEEKNIGHT_WINDOW freq=daily;byday=MON,TUE,WED,THU,FRI,SAT;byhour=0;byminute=0;bysecond=0 +000 05:00:00 TRUE
WEEKEND_WINDOW freq=daily;byday=SUN;byhour=0;byminute=0;bysecond=0 +001 00:00:00 TRUE

14 octobre 2007

Installer/Désinstaller 11g en ligne de commande

Après la procédure pour la version 10g, voici la procédure d'installation/désinstallation d'Oracle 11g en ligne de commande !

Supposons pour ce qui suit que le répertoire d'installation d'Oracle 11g soit /u01/app/oracle/product/11.1.0/db_1. Pour désinstaller votre logiciel de base de données, il suffit d'opérer les quelques étapes ci-dessous :
cd /u01/app/oracle/product/11.1.0/db_1
export ORACLE_HOME=`pwd`
cd oui/bin

./runInstaller -silent -deinstall -removeallfiles \
REMOVE_HOMES={"$ORACLE_HOME"}
Pour l'installation, voici le minimum des paramètres que vous devez précisez :
  • Le répertoire d'installation de votre base de données (ORACLE_HOME)
  • Un nom pour ce répertoire d'installation (ORACLE_HOME_NAME)
  • Le répertoire de base du logiciel Oracle (ORACLE_BASE) --nouveau en 11g
  • Que vous ne voulez que le logiciel (n_configurationOption=3)
  • Le fichier de réponse de votre choix (e.g install/response/ee.rsp) --changement par rapport à 10g
Supposons que vous soyez dans le répertoire du logiciel Oracle (i.e /[...]/database ) :
export DISTRIB=`pwd`
export ORACLE_HOME=/u01/app/oracle/product/11.1.0/db_1
export ORACLE_HOME_NAME=OraDb111Home1
export ORACLE_BASE=/u01/app/oracle

./runInstaller -silent \
-responseFile $DISTRIB/install/response/ee.rsp \
ORACLE_BASE=$ORACLE_BASE \
ORACLE_HOME=$ORACLE_HOME \
ORACLE_HOME_NAME=$ORACLE_HOME_NAME \
n_configurationOption=3

su - root -c $ORACLE_HOME/root.sh
# ou si sudo est configuré
# sudo $ORACLE_HOME/root.sh
Bon ! Il ne vous reste plus qu'à créer une base de données en ligne de commande comme décrit ici et moi à trouver pourquoi cette procédure testée avec succès sur Enterprise Linux 5 et 11.1.0.6 ne fonctionne pas encore avec mon poste de travail Ubuntu...

Grid Control, Agent 10g et HTTPS restreint à 443

J'ai eu la "chance" de configurer l'OMS et les agents d'Oracle GridControl 10.2.0.3 en HTTPS via port 443 le tout avec Linux et après quelques ébats : ça marche ! Rien d'exceptionnel ? Une revue (que je vais compléter !) de ces aspects de paramétrage vous indiqueront que :
  1. Les agents 11g (pour dans quelques mois j'espère) implémenteront très probablement l'Enhancement Request 5055990 intitulée "Need EM Agent to work on port 443 (securely) on Unix". Et, pour le plaisir, Linux fonctionne comme Unix dans ce cas !
  2. Cette section de la documentation qui explique comment faire travailler agent et OMS à travers un firewall et mentionne en particulier "Before completing that step, configure your firewalls to allow both HTTP and HTTPS traffic between the Management Agent and Management Repository". Bien sur entre 2 data center différents, c'est un peu délicat de demander ça... Sans attendre 3 mois
  3. Cette section de la documentation indique clairement qu'il faudra aussi créer un canal SQL*NET entre le Grid Control et les bases de données cibles pour les aspects d'administration. Ne rigolez pas ;) !
Et pour dire vrai :
  1. Effectivement les agents Linux et Unix ne peuvent pas discuter sur le port 443 et il n'est pas possible de créer un proxy http dans ce sens ! MAIS ! Vous pouvez faire une translation de port sur l'OMS et sur le serveur de l'agent... Cette technique vous permet de vous sortir "simplement" de la restriction actuelle au moins si votre OMS est sous Linux. Le dialogue passe alors à travers le port 443 du serveur de l'agent, même si l'agent écoute sur une adresse au dessus de 1024
  2. Ma lecture de cette restrictions reside dans la procedure d'installation. Enfin si vous configurez les agents "à la main" avec "emctl deploy", il n'y a eu aucun trafic HTTP (de toute façon il était bloqué sur TOUS les ports !)
  3. Effectivement ! Il vous faudra sans doute, comme moi, créer un tunnel sécurisé SQL*NET grâce à un Connection Manager dans chaque data center ! Je vous conseille "Net Services Administrator's Guide - Configuring and Administering Oracle Connection Manager" pour plus d'informations. Lorsque vous configurez la cible base de données, il est possible de préciser l'URL de connexion et donc d'utiliser un listener situé localement.
Note : Si le port par défaut du protocole HTTPS est 443, il est possible d'écouter en HTTPS sur n'importe quel port ! Il y a donc une différence fondamentale entre bloquer tous les ports sauf le port 443 et filtrer le protocole HTTPS. La première solution vous permet, par exemple, de dialoguer en HTTP sans SSL à travers le port 443. La deuxième solution vous permet de dialoguer via un autre port si le protocole est HTTPS. Dans ce qui est décrit ci-dessous (a) tous les ports sont bloqués sauf 443 et (b) le firewall filtre le protocole HTTPS. Bien sur s'agissant de l'OMS et des agents, les requêtes doivent être faites dans les 2 sens

Configurer l'OMS pour qu'il ne soit accessible qu'en HTTPS sur le port 443

Cette étape est finalement assez simple quoi qu'il faille naviguer entre les différentes documentations. Il faut :

1) Stopper l'OMS avec la commande ci dessous :
$ORACLE_HOME/opmn/bin/opmnctl stopall
2) Passez le fichier .apachectl root comme décrit dans cette section de la documentation "Oracle HTTP Server Administrator's Guide".
cd $ORACLE_HOME/Apache/Apache/bin

chown root .apachectl
chmod 6750 .apachectl
3) Changez le port sécurisé comme décrit sous "To change the default Management Service port to a secure port" dans le document "Enterprise Manager Advanced Configuration - 12.2 Reconfiguring the Oracle Management Service". Pour cela exécutez les commandes suivantes :
$ORACLE_HOME/bin/emctl secure oms \
-secure_port 443

ORACLE_HOME/dcm/bin/dcmctl updateconfig -ct ohs
4) Eventuellement bloquer l'OMS. Dans ce cas, vous ne pourrez plus communiquer autrement qu'en HTTPS. C'est vrai y compris, d'après mes tests, via l'interface web : seule la page d'accueil s'affiche dans votre navigateur web. Quand vous tentez de vous connecter, votre navigateur reçoit un message HTTP 302 et reste bloqué sur la même page.
$ORACLE_HOME/bin/emctl lock oms
5) Redémarrez l'OMS
$ORACLE_HOME/bin/emctl start oms
2 points à noter :
- Si vous avez déjà des agents configurés, il faudra changer la valeur de REPOSITORY_URL située dans le fichier $AGENT_HOME/sysman/config/emd.properties. Pour qu'elle pointe vers la nouvelle adresse de votre OMS. Vous trouverez plus d'informations dans "Enterprise Manager Advanced Configuration - 12.1 Reconfiguring the Oracle Management Agent". Si vos agents ne communiquaient pas encore en HTTPS, reportez-vous à "Enterprise Manager Advanced Configuration - 5.2.4 Enabling Security for the Oracle Management Agent"
- Vous pouvez ajouter un certificat validé par un organisme externe, comme Entrust pour éviter le message de votre navigateur web et pour sécuriser votre environnement un peu plus. Pour information, la configuration SSL du serveur apache est stockée dans le fichier httpd_em.conf dans le répertoire $ORACLE_HOME/sysman/config.

Configurer vos serveurs OMS et cibles pour permettre le "
Port Address Translation (NPAT)"

Le principe que nous allons utiliser est schématisé ci-dessous ; il consiste à effectuer 2 translation de ports avec iptables de manière que le trafic passe par 443 mais que ni l'OMS, ni l'agent ne sachent que le port n'est pas 3872 (ou celui de votre choix). Pour cela, il faut configurer iptables :
  • sur l'OMS pour qu'il transforme les appels à target:3872 vers target:443
  • sur la cible pour qu'elle transforme les appels vers target:443 vers des appels à target:3872

Pour réaliser cette opération, il faut :

1) Vérifier que les 2 adresses sont connues soit via les DNS, soit via les fichiers /etc/hosts des 2 machines. Dans le pire des cas, le protocole ICMP est aussi bloqué et vous ne pourrez pas tester avec ping ; toutefois le ping doit afficher la résolution de l'adresse en fonction du nom.

2) Vérifier que iptables est actif (là je deviens encore plus spécifique - ces procédures sont pour Redhat Linux 3+ ou Oracle Enterprise Linux 4+). Sous root :
# Pour quel niveau iptables démarre automatiquement ?
/sbin/chkconfig --list iptables

# Quel est le niveau au boot ?
grep initdefault /etc/inittab|grep ":"

# Active iptables lors du passage dans les niveaux 3 et 5
/sbin/chkconfig --level 35 iptables on

# iptables est-il actuellement actif ?
# (oui si affiche les tables)
/sbin/service iptables status

# demarre iptables
/sbin/service iptables start
3) Ajouter une règle qui fasse la translation des ports. Cette opération est bien sur différente sur le serveur OMS et sur la cible puisque la règle de translation est différente. On supposera que l'adresse IP de la cible est 10.0.0.1 ; Remarquez que comme dans l'établissement de la connexion vers la cible, jamais l'adresse de l'OMS apparaît elle n'apparaît pas dans les règles;

Sur l'OMS :
iptables -t nat -A OUTPUT          \
-d 10.0.0.1 -p tcp --dport 3872 \
-j DNAT --to-destination 10.0.0.1:443
Sur le serveur cible :
iptables -t nat -A PREROUTING     \
-d 10.0.0.1 -p tcp --dport 443 \
-j REDIRECT --to-ports 3872
Remarques :
- iptables sert généralement de firewall. S'il était déjà activé, il faudrait veiller à l'ordre des règles et en particulier que les trames concernées ne soient pas bloquées
- Pour éviter de se tromper,
    • vous pouvez visualiser les règles avec "iptables -t nat -L".
    • vous pouvez supprimer une règle avec "iptables -t nat -D [chaîne] [numregle]" ou [chaîne] est selon ce que vous avez modifié PREROUTING ou OUTPUT et [numregle] est la position de la règle dans votre chaîne (e.g. 1 si votre table était vide avant)
    • vous pouvez sauvegardez toutes les règles dans un fichier avec "iptables-save >monfichier"
    • vous pouvez restaurer toutes les règles à partir d'un fichier avec "iptable-restore <monfichier"
4) Sauvegarder l'ensemble des règles dans la configuration iptables utilisé par le service
/etc/init.d/iptables save
Configurer les agents manuellement.

Pendant l'installation des agents (avec runInstaller), vous pouvez avoir plusieurs erreurs :

1) Dans l'écran "Specify Agent Management Service Location" positionnez le nom du serveur OMS ainsi que 443 comme port de communication ; comme le test n'est pas effectué en HTTPS, vous aurez forcément un message d'erreur "The specified Management Service on host x at port y is unreachable [...]" Cliquer sur OK pour continuer malgré tout !

2) L'assistant de configuration des agents doit laisser au minimum les agents non-sécurisé. Vous trouverez ci-dessous l'ensemble de étapes pour remettre la configuration à plat.

2.a) Dans le cas ou la configuration n'est pas correcte vous pouvez la refaire complètement... En fait dans mon cas (RAC), cette configuration est visiblement faite sur le premier nœud avec les informations des nœuds du cluster dont l'"Installer" dispose via le clusterware puis est poussée sur les autres noeuds. Lorsque les agents démarrent, ils vont chercher leur configuration dans le répertoire `hostname` de l'ORACLE_HOME de l'agent :
  • Si, par le jeu des noms de domaine par exemple, la configuration est différente du hostname sur le serveur, vous serez amener à refaire la configuration comme ce qui suit.
  • D'autre part, refaire la configuration permet de maîtriser la manière dont l'agent est représenté dans l'OMS (i.e. avec le nom de domaine ou nom), il permet de changer un nom de la cible
  • Enfin, si vous avez un nom de domaine trop long, il est possible que l'agent ne stocke pas sa configuration comme il faut dans l'OMS. Cette méthode permet de s'en abstraire
Pour refaire la configuration, il faut utiliser la commande "emctl deploy". Voici comment :
#Remplacez ce qui suit par votre ORACLE_HOME
export ORACLE_HOME=/u01/app/oracle/product/10.2.0/agent10g
export PATH=$ORACLE_HOME/bin:$PATH
cd $ORACLE_HOME

# Effacer le répertoire qui suit revient à effacer la configuration
# de l'agent. Vérifiez qu'il n'a a pas un autre répertoire avec un
# nom de serveur et supprimez-le manuellement
rm -rf $ORACLE_HOME/`hostname`

# Utiliser emctl deploy pour créer la configuration
export MYHOSTNAME=$lt;nom_agent_dans_oms>
emctl deploy agent \
$ORACLE_HOME/`hostname` \
$MYHOSTNAME:3872 \
`hostname`

# truc
# -----
# Il est possible de changer les chaînes `hostname` pour changer
# la manière dont le serveur apparaît dans le GridControl toutefois
# le répertoire doit correspondre avec $ORACLE_HOME/`hostname`.
# Si pour n'importe quel raison ce n'est pas le cas, un lien permet
# à l'agent de s'y retrouver
# -----
# cd $ORACLE_HOME
# ln -s `hostname` $MYHOSTNAME
2.b) Une fois que la configuration est faite, il faut la modifier pour qu'elle supporte HTTPS et sécuriser l'agent. Pour cela opérez ce qui suit :
  • Editez le fichier emd.properties de votre configuration comme dans l'exemple qui suit :
export ORACLE_HOME=/u01/app/oracle/product/10.2.0/agent10g
export PATH=$ORACLE_HOME/bin:$PATH
cd $ORACLE_HOME/`hostname`/sysman/config
vi emd.properties
  • Modifiez les URLs suivantes :
    • REPOSITORY_URL ressemble à ce qui suit : http://mon-oms:443/em/upload/ . Modifiez cette URL de façon à remplacer http par https et supprimer le / à la fin (important en https, le / à la fin de l'URL NE DOIT PAS être présent) . Votre propriété doit ressembler à ceci :
      REPOSITORY_URL=https://mon-oms:443/em/upload
    • emdWalletSrcUrl ressemble à ce qui suit : http://mon-oms:443/em/wallets/emd . Modifiez cette URL de façon à remplacer http par https. Votre propriété doit ressembler à ceci :
      emdWalletSrcUrl=https://mon-oms:443/em/wallets/emd
    • EMD_URL ressemble à ce qui suit : https://target:3872/emd/main . Modifiez cette URL de façon à remplacer http par https. Votre propriété doit ressembler à ceci :
      EMD_URL=https://target:3872/emd/main (Si vous voulez modifiez le port d'écoute de l'agent pour n'importe quelle valeur libre et >= 1024, il suffit de changer la valeur de ce port.
  • Vous pouvez ensuite simplement, sécuriser l'agent, le démarrer et chargez les fichiers dans l'OMS :
emctl secure agent
emctl start agent
emctl upload
Remarques :
a- runConfig.sh est l'assistant de configuration de l'agent qui est lancé à la fin de l'installation. S'il échoue, son fichier de log est situé dans cfgtoollogs/cfgfw
b- pour tester vos connexions https, utilisez wget avec, par exemple comme ceci "wget --no-check-certificate https://oms-host:443"
c- Si vous utilisez les scripts agentDownload, ce que je recommande, même si, avec RAC, ce n'est encore très clair pour moi, je pense que c'est plus simple. Enfin j'espère et je compte sur vous pour me donner votre feedback
Voilà qui conclut cette expérience avec une configuration un peu spéciale. Mon contact Oracle sur ce sujet a dit : "Obviously you watched all the MycGyver episodes ;-)". En fait c'est Rusty Russel qu'il faut remercier ! Quant à moi, je souhaite que cette expérience pour sécuriser le GridControl et/ou que cet exemple d'utilisation de NPAT vous soit utile.

12 octobre 2007

Oracle lirait-il mon blog ?

A peine, je conseille à SAP de racheter BEA qu'Oracle envoie une lettre au board de BEA pour faire une offre. Allez voir Jean-Philippe pour tous les liens !

On reste calme ! Ce n'est qu'un début ! Si quelqu'un veux racheter Teradata cette semaine, je me fais analyste de marché ;)

08 octobre 2007

Installer/désinstaller 10g en ligne de commande

Supposons pour ce qui suit que le répertoire d'installation d'Oracle 10g soit /u01/app/oracle/product/10.2.0/db_1. Pour désinstaller votre logiciel de base de données, il suffit d'opérer les quelques étapes ci-dessous (réfléchissez 10 fois avant d'exécuter ce qui suit) :
cd /u01/app/oracle/product/10.2.0/db_1
cd oui/bin

./runInstaller -silent -deinstall -removeallfiles \
REMOVE_HOMES={"/u01/app/oracle/product/10.2.0/db_1"}
Pour l'installation, en réalité, inutile de modifier le fichier de réponse par défaut, modifiez simplement les paramètres qui changent de ceux par défaut comme dans l'exemple qui suit :
  • Le répertoire d'installation de votre base de données (ORACLE_HOME)
  • Un nom pour ce répertoire d'installation (ORACLE_HOME_NAME)
  • Que vous ne voulez que le logiciel (n_configurationOption=3)
  • Le fichier de réponse de votre choix (e.g enterprise.rsp)
Supposons que vous soyez dans le répertoire de votre du logiciel Oracle :
export DISTRIB=`pwd`                                \
./runInstaller -silent \
-responseFile $DISTRIB/response/enterprise.rsp \
ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1 \
ORACLE_HOME_NAME=OraDb102Home1 \
n_configurationOption=3
Une dernière chose à propos de cette méthode et sur mon desktop :
  • L'installation d'Oracle 10g a duré 3 minutes 4 secondes (hors root.sh)
  • La désinstallation d'Oracle 10g a duré 1 minute 4 secondes
PS : Cette dernière méthode évolue un peu en 11g mais laissez moi en parler une autre fois.

SAP s'aligne...

Excellente nouvelle ! SAP s'aligne enfin et promet de racheter Business Objects : L'avenir va être intéressant. Si je peux me permettre 2 conseils pour étendre la nouvelle entente franco-allemande sur le coté ouest :
Bien sur, c'est pour concurrencer Oracle sur le terrain de la technologie et je vous laisse le soin de réfléchir au CRM, aux solutions verticales ou à l'entreprise 2.0. Après ça messieurs, s'il vous reste 1 milliard (même en dollars canadiens), j'ai développé une nouvelle technologie qui pourrait transformer l'avenir de Google. Bon je n'en dis pas plus !

07 octobre 2007

Créer base de données "à la main" VS "sans assistant"...

Je crois l'avoir déjà dit : "Un de mes posts que je vous recommande de ne pas utiliser est celui qui explique comment créer une base de données manuellement". Oui : Il fonctionne bien ; oui : c'est intéressant de savoir ce qu'il se passe quand on crée une base de données...

Si je déconseille de l'utiliser pour créer une base de données, c'est juste parce qu'il y a une méthode plus rapide, plus simple, mieux supportée et compatible avec RAC : utiliser DBCA en mode silencieux ! La seule vrai objection qui pourrait être faîte à cette dernière méthode c'est si vous voulez personnalisez à outrance la création de vos bases de données. Si c'est le cas, n'oubliez pas :
  • Vous pouvez créer votre template avec CREATE DATABASE et le déployer de manière standard avec DBCA
  • Vous pouvez ajouter des scripts après l'installation et même les intégrer à vos templates
  • Plus votre environnement est personnalisé et ne ressemble à aucun autre, plus de chance vous avez de tomber sur les bugs d'aucun autre ;)
Assez de blabla, voici un exemple d'utilisation de DBCA en mode silencieux pour créer une base de données en 10g et 11g (test effectué sur linux avec 11.1.0.6 et 10.2.0.1). Pour plus d'information, tapez dbca -h . Si vous trouvez une documentation plus complète, j'aimerais bien la référencer ICI. D'ici là avec quelques tests et un peu d'aide, c'est vraiment rapide et direct :
./dbca -silent -createDatabase                   \
-templateName General_Purpose.dbc \
-gdbName ORCL \
-sysPassword change_on_install \
-systemPassword manager \
-emConfiguration NONE \
-datafileDestination /u01/app/oracle/oradata \
-storageType FS \
-characterSet WE8ISO8859P15 \
-memoryPercentage 20
Quelques remarques à ce sujet :
  • Il n'y a pas besoin de positionner la variable ORACLE_HOME ou ORACLE_SID. En revanche, vérifiez que vous utilisez le DBCA situé dans le répertoire "bin" du logiciel Oracle que vous utilisez. Le plus simple, c'est de préfixer votre commande par ./ (ou .\ sous Windows) après avoir navigué dans le répertoire du logiciel que vous voulez utiliser. Sous Linux/Unix, le fichier "oratab" est mis à jour à la fin de la création de votre base de données. Vous pourrez simplement mettre à jour votre environnement avec "oraenv" une fois votre base créée.
  • Les 2 premières options -silent et -createDatabase indiquent que vous voulez créer une base de données et que vous n'avez pas de "DISPLAY"
  • Les templates par défaut sont situés dans le répertoire "assistants/dbca/templates" de votre logiciel. Référencez le fichier qui vous convient.
  • L'option gdbName vous permet de positionner le "global database Name". Le SID est déduit de cette option et de votre configuration mais vous pourriez également positionner le SID dans la ligne commande
  • sysPassword et systemPassword permettent de positionner les mots de passe de SYS et SYSTEM. Modifiez-les une fois la base créée.
  • emConfiguration définit le paramétrage de GridControl/Database Control ou, dans ce cas, de rien du tout
  • l'option datafileDestination permet de définir la destination de vos fichiers de base de données dans le cadre d'un déploiement OFA. C'est à dire, ici avec l'option storageType "FS" l'ensemble des fichiers de bases de données seront stockés dans le sous-répertoire du répertoire précisé par cette option
  • l'option characterSet permet de positionner le jeu de caractères de votre base de données.
  • memoryPercentage ; je déteste cette option ! 11g propose une alternative -totalMemory qui permet de positionnez la taille de la SGA et PGA en MB et pas en % de la mémoire du serveur. Enfin, c'est un moyen de positionnez la taille de la SGA et de la PGA. Quitte la la modifier dès que possible !
Encore plus redoutable, vous pouvez supprimer une base de données avec DBCA en mode silencieux comme ceci ; (Tournez votre langue dans votre bouche 7 fois avant de lancer cette commande) :
./dbca -silent -deleteDatabase \
-sourceDB ORCL
Pour conclure... Lorsqu'il est utilisé avec des templates, DBCA utilise RMAN et le résultat est assez efficace. Dans ces tests sur mon desktop et avec la commande "time" avant ./dbca, on obtient les résultats qui suivent :
  • Créer une base de données avec 10.2.0.1 : 2m59.094s
  • Supprimer la même base de données : 0m24.481s
  • Créer une base de données avec 11.1.0.6 : 4m9.451s
  • Supprimer la même base de données : 0m31.526s
Je souhaite que ces derniers résultats finissent par vous persuader : créer une base de données en moins de 10 minutes (le temps de personnalisez la première ligne de commande). Qui peut encore croire que CREATE DATABASE est la meilleure manière de créer une base de données Oracle ?

06 octobre 2007

Qu'est ce que vous risquez de casser dans votre base Oracle ?

Analyser l'impact d'une modification, à l'intérieur de votre base de données n'est pas compliqué grace à la table temporaire DEPTREE ! Rien à voir avec DEPT, bien sur ! Il s'agit de l'arbre des dépendances complet alors que ALL_DEPENDENCIES ne présente que la partie code.

Vous trouverez ci-dessous un exemple d'utilisation ; et voici un premier pointeur dans la documentation d'Oracle 11g.

1ere et seule difficulté

Il est très probable que la table temporaire DEPTREE n'existe pas dans votre base de données. Allez savoir pourquoi ça fait partie de ces utilitaires avec DBMS_SHARED_POOL et le script dbmspool.sql qui ne sont pas installés par défaut. Bonne nouvelle, si vous pouvez vous connectez à un des comptes SYSDBA de votre serveurs, ça va vite :
sqlplus "/ as sysdba"
@?/rdbms/admin/utldtree
Et les messages d'erreurs sur le fait que la table ou la procédure n'existe pas sont attendus.

Et d'ailleurs, c'est installé !

Première étape - Charger la table DEPTREE

La procédure deptree_fill est à cet effet. Pour l'utiliser, vous devez préciser :
  • le type de l'objet (par exemple 'table' ou 'view')
  • le schéma de l'objet
  • le nom de l'objet
Ça donne pour la table SCOTT.EMP :
exec deptree_fill('table', 'scott', 'emp')


Deuxième étape - Visualiser le résultat

Comme on s'en doutait, il suffit de faire un select sur la table DEPTREE comme ci-dessous :
col seq# format 999
col name format a20

select * from deptree
order by seq#;

NESTED_LEVEL TYPE SCHEMA NAME SEQ#
------------ ------------------- --------------- -------------------- ----
0 TABLE SCOTT EMP 0
1 PROCEDURE SCOTT TEST 1
Faut-il préciser que bien sur les appels via du SQL dynamique (EXECUTE IMMEDIATE ou DBMS_SQL) et le code de l'application ne sont pas affichés ? non ! En même temps si vous cherchez à savoir ce qui pourrait être invalidé par votre modification, c'est exactement ce qu'il faut !

04 octobre 2007

Vous avez été quelques-uns à dire 11g, c'est pour bientôt

Deuxième sujet polémique du jour, les résultats de la question du mois de septembre qui n'a visiblement pas intéressé le plus grand nombre : "Quand allez-vous mettre 11g en production ?"

Pourrait-on voir une explication dans ce post précédent ? Vous pouvez commenter !

Pour ma part, stretch cluster oblige, 11g pourrait être pour très bientôt. C'est ce que je me souhaite en tous les cas.

MySQL un peu moins compatible avec SAP ?

Comment comprenez-vous ça ? SAP reprend à son compte MaxDB, géré depuis 2003 par MySQL pour re(Adabas D)-re(SAP DB)-re(MaxDB)-développer son moteur de base de données maintenant au cœur de sa nouvelle offre, SAP Business ByDesign ! Et moi qui croyais que SAP était un support actif de MySQL.

Pourtant les "technos" SAP sont de par mon expérience bien fichues ; j'ai eu l'occasion d'y toucher de nombreuses fois - ;-) toujours avec Oracle - pour tirer le meilleur parti d'environnement VLDB, d'environnement décisionnels avec le partitioning, la compression ou même le support d'ABAP par OWB : Alors pourquoi ce genre de pas de côté ? Pourquoi ne pas plutôt pousser dans le sens de MySQL ? Pourquoi ne pas permettre d'accéder aux produits SAP pour les besoins d'un prototype, d'évaluation ou d'éducation aussi simplement que le fait Oracle ? Pourquoi simplement annoncer une licence Netweaver pour les développeurs tout en admettant que les clients ont des conditions très différentes et même si c'est déjà un pas positif ? Tout ça c'est juste dommage : enfin, sans critiquer la stratégie et juste en regardant mon intérêt personnel !

Ce qui est sur aujourd'hui c'est que MySQL vient sans doute de perdre une bonne occasion de rentrer dans les entreprises par les applications ! Ou en tout cas de voir cette échéance sérieusement repoussée. En même temps qui pourrait croire que MySQL puisse gérer des applications d'entreprises en dehors de quelques serveurs web ou pour des applications embarquées ? Peut-être moi mais visiblement pas les gurus d'eSAP...

Il me reste à souhaiter longue vie à (comment va-t-on l'appeler ?) SAP DB 2.0. Après cette digression, revenons à Oracle.