Archives pour la catégorie 12c

12c: Oracle en multi-thread

Publié le par
1

Sous Windows, Oracle tourne avec un seul process et plusieurs threads. Les process Oracle de V$PROCESS sont en fait des threads.
Sous Linux, on est habitué à avoir un process OS pour chaque process Oracle.

La 12c permet d’avoir une architecture multi-thread sous Unix/Linux aussi afin de mieux gérer les ressources:

  • C’est moins couteux de créer un thread qu’un process (normalement, avec un pool de connexion bien configuré, on ne devrait pas voir une forte activité de création de process de toute façon)
  • Les switch de contexte entre threads sont moins couteux qu’entre process car beaucoup de ressources sont partagées entre tous les threads d’un process. On verra la différence lorsque le système commence à être assez chargé (forte utilisation CPU)

Pour celà il faut:

  • Mettre le paramètre threaded_execution=true (nécessite un redémarrage bien sûr)
  • Mettre dedicated_through_broker_LISTENER=ON dans le listener.ora
    Pour que la connection ouvre un thread dans un process serveur au lieu que ce soit le listener qui crée un process.

Attention, c’est un gros changement d’architecture, il y a quelques restriction, la première que vous verrez est qu’il n’est plus possible de se connecter ‘/ as sysdba’. Il faut fournir le user/password.

Un exemple de V$PROCESS dans la demo
Dans V$PROCESS PID est le numéro de process Oracle, SPID est toujours le numéro de process de l’OS (PID), et on a STID qui donne le numéro de thread (LWP) et EXECUTION_TYPE qui dit si c’est un thread ou un process.

12c Création d’une Pluggable Database

Publié le par
Répondre

Dans la Container Database créée dans le dernier post on ne peut pas encore créer de tables.

Il faut maintenant créer une Pluggable Database pour pouvoir travailler dedans comme on avait l’habitude de travailler dans une base avant la 12c.

Et c’est très simple:

create pluggable database MANPDB01 admin user ADMIN identified by oracle;

On a besoin de préciser un utilistateur DBA pour cette Pluggable Database. Et si l’on est pas en OMF pour déterminer le nom des fichiers, on rajoutera DB_FILE_NAME_CONVERT pour convertir les fichers de PDB$SEED vers ceux de notre nouvelle PDB.

Il y a toujours une une grosse incompréhension lorsque un développeur pas trop habitué à Oracle a besoin d’un nouvel environnement et va voir le DBA pour lui demander une nouvelle base. Le développeur a l’impression de demander quelque chose de simple. Le DBA lui doit provisionner un ensemble de ressources et mettre en place tout un tas de procédures.

C’est fini. En 12c, dans un CDB, on peut créer une base en 10 secondes. Pour le DBA c’est une Pluggable Database mais le développeur la voit comme sa propre base.

La demo de cette opération très simple.

L’utilisateur se connectera avec un nom de service spécifique, pour mon exemple:

connect ADMIN/oracle@//92.168.56.112/MANPDB01.pachot.net

Le DBA pourra lui choisir de se connecter à la CDB puis passer sur la Pluggable Database avec:

alter session set container=MANPDB01

12c Création manuelle d’une Container Database

Publié le par
Répondre

Evidemment, le plus simple pour créer une Container Database est de le faire avec DBCA.

La création manuelle diffère de la création d’une 11g ou d’une 12c non-CDB principalement sur les points suivants:

  • Dans init.ora il faudra préciser:
    enable_pluggable_database=true
  • Dans CREATE DATABASE il faudra préciser
    enable pluggable database

    et (sauf si on utilise OMF pur nommer les fichiers) la clause:

    seed file_name_convert=(...)

    pour donner le nom des datafiles de PDB$SEED à partir de ceux de CDB$ROOT

  • il faut utiliser catcon.pl pour lancer les catalog.sql, catproc.sql, etc sur tous les containers

On a alors une ‘Multitenant Container Database’ avec 2 containers:
CDB$ROOT qui contient le dictionnaire et les objets communs.
PDB$SEED une Pluggable Database vide prête à être clonée pour créer des Pluggable Databases

Chaque container a au moins ses tablespaces SYSTEM et SYSAUX et un service pour s’y connecter (sauf PDB$SEED auquel on ne se connecte pas).

Le détail de la création de la CDB sur la demo

Cette base ne sert encore à rien, car la CDB n’est pas faite pour stocker des objets non-Oracle. La prochaine étape sera la création d’une Pluggable Database qui pourra alors être utilisée pour créer ce qu’on veut. Ce sera le sujet du prochain post.

12c: Container Database et Pluggable Databases

Publié le par
1

La 12c est sortie (Linux et Solaris):

  • La doc à lire en ligne
  • L’install à télécharger sur OTN

Au delà des nouvelles fonctionnalités, c’est un gros changement d’architecture avec la notion de CDB – Multitenant Container Database

On est habitués à ce que une instance (les process et la mémoire) travaille sur une seule base (les fichiers). En RAC on peut avoir plusieurs instances sur une seule base. Mais contrairement à d’autres SGBD, entre plusieurs bases, on ne partage aucune ressource: chacune a son dictionnaire, l’ensemble des objects Oracle (les dbms_xxx, tables systèmes), chacune a sa mémoire, ses process,…

Bien sûr on pourrait n’avoir que très peu de bases – l’idéal étant de n’avoir qu’une seule instance par serveur. Mais pour cela il faut pouvoir mettre les schémas de plusieurs applications dans une même base. C’est tout à fait possible et Oracle permet aussi bien de les séparer logiquement (par les schemas) et physiquement (par les tablespaces).

Au niveau physique, il est assez facile de gérer l’ensemble des tablespaces d’une application: on peut les backuper indépendamment, les transporter avec Transportable Tablespace, etc. et au niveau logique tout va bien si l’application accepte de ne pas être toute seule sur la base. Mais ce n’est pas le cas. Beaucoup de logiciels imposent les noms de schemas (donc on ne peut pas en avoir deux sur une même base), créent des objets publics (db links, synonymes) qui empêchent de mutualiser les ressources.

En 12c Oracle a étendu le concept de Transportable Tablespaces (ensemble de tablespaces ‘self-contained’ et export des meta-données du dictionnaire qui vont avec) avec le concept de Pluggable Databases. En y rajoutant tout pour que l’application croit être toute seule sur sa base. La Pluggable Database a son tablespace SYSTEM avec les metadonnées des tables de l’application, ses tables, ses users, etc. et des liens vers les metadonnées communes.

On a donc plusieurs containers dans une seule database gérée par une seule instance, et chacun apparaît comme une base:
Chaque Pluggable Database sur laquelle se connecte l’appli est un Container. L’application peut y faire ce qu’elle veut comme si elle était toute seule sur une base.
Les objets communs sont dans un container racine CDB$ROOT. Il y a en plus une Pluggable Database PDB$SEED en read-only qui permet de créer une nouvelle PDB facilement en la clonant – fini les longs catalog.sql/catproc.sql pour chaque création de base. Les développeurs vont pouvoir demander une nouvelle base sans avoir l’impression de demander un nouveau datacenter.

Une base qui peut contenir plusieurs conteneurs – donc plusieurs Pluggable Databases, c’est une ‘Multitenant Container Database’ ou CDB.
Bien sûr on peut continuer à créer des bases non-CDB, comme avant, sans cette notion de Pluggable Database. Elle n’ara alors qu’un seul conteneur.

c’est au CREATE DATABASE que ça se décide avec ENABLE PLUGGABLE DATABASE.

Au prochain post, la création d’une Container Database…