Avec un peu de délai, voici la version française de la suite de la série qui nous emmène vers la version 12c de la base de données Oracle. Le thème de ce feuilleton est bien la mise à jour vers la nouveauté, l’idée principale étant de passer par toutes les étapes possibles, l’une après l’autre, épisode par épisode.
Le point de départ c’était il y a déjà quelques temps, raconté ici, la mise en place d’un environnement de travail composé d’un serveur Oracle Entreprise Linux 6 sur lequel est installé une base de donnée en version 11.2.0.3 nommée ora112 et les binaires de la version 12.1.0.1. Aujourd’hui nous verrons toutes les étapes de préparation qui sont réalisées au préalable, et comme lors d’une mise à niveau, il est important d’évaluer l’impact des changements sur la qualité de service des applications, la toute première chose sera une évaluation des performances de notre configuration. N’ayant pas de vrai production à disposition, c’est de nouveau l’outil Swingbench de Dominic Giles qui va être utiliser. Le test “Order entry” correspondant à une application marchande est celui que j’ai choisi pour établir l’étalonnage.
1. Référence
Pour la mise en place de l’outillage et du test , se reporter ici quelques mois en arrière. Swingbench évolue à son rythme et la version courante que j’ai trouvé est la 2.4 datant de mars 2010 , elle reste cependant complètement opérationnelle sur un client Windows 7 et un jre 1.6.0.4.
Les conditions du tests sont les suivantes (affichage des champs en langue anglaise, tel que l’outil le présente):
– Number of Users :15
– Minimum Delay beetween transaction (MinimumThinkTime): 100ms
– Maximum Delay beetween transaction (MaximumThinkTime): 200ms
– Logon Delay : 0
– Logon Group : 1
– Benchmark run time : 15 minutes
– Prise de statistiques sur la base sélectionnée et déclenché dés le début du test.
Les résultats se retrouvent dans le tableau 1 suivant :
Table 1:
| TPS | Max TPM | Customer Registration | Browse Products | Order Products | Process Orders | Browse Orders | Remarks |
| 14.25 | 917 | 20 | 17 | 70 | 30 | 36 | July 3th 11:04 |
- TPS : Transaction par seconde
- Max TPM : Nombre maximale de transaction par minute
- Durée moyenne des transactions de chaque test (ms)
2. Chemins de migration
Pour le chemin de migration, notre choix ici est simple la version de la base de départ étant dans le dernier patchset courant ; nous allons pouvoir dans un premier temps utiliser les outils fournis pour mettre à jour notre dictionnaire.
Je rappelle que dans cette première saison nous ne parlons pas des bases enfichable et des containeurs (Pluggable database) , nous allons vers une base qui reste dans une architecture traditionnelle.
On peut retrouver les informations concernant les chemins de mise à jour dans la documentation ou sur ce « white paper » produit par Oracle que je vous recommande et dont voici le tableau traduit :
| Version source |
Patch Set source | Support de MAJ directe |
| Oracle Database 11g Release 2 | 11.2.0.2 et ultérieur | Oui |
|
– |
11.2.0.1 | MAJ directe non supportée, Prendre une autre méthode |
| Oracle Database 11g Release 1 | 11.1.0.7 | Oui |
|
– |
11.1.0.6 | MAJ directe non supportée, Prendre une autre méthode |
| Oracle Database 10g | 10.2.0.5 | Oui |
|
– |
10.2.0.4 et précédent | MAJ directe non supportée, Prendre une autre méthode |
| Oracle Database 9i et précédente | Tous | MAJ directe non supportée, Prendre une autre méthode |
Nous reparlerons des différentes méthodes à disposition dans un prochain épisode et plus particulièrement la nouveauté relative à l’export/import des tablespaces en mode complet (Full Transportable Export/Import).
Pour rappel ce voyage ne concerne pas directement les fonctionnalités multitenant mais ne vous inquiétez pas vous trouverez rapidement de nombreux autres articles sur ce sujet sur arzyod.
3. Vérification des pré-requis
Pour vérifier les pré-requis, quelques nouveautés:
Le script utlu121i.sql n’existe plus en tant que tel et est remplacé par le script preupgrd.sql. Le fichier existe toujours mais contient simplement les informations relatives au nouveau script :
Rem Rem $Header: rdbms/admin/utlu121i.sql /main/24 2012/08/22 07:32:07 bmccarth Exp $ Rem Rem utlu121i.sql Rem Rem Copyright (c) 2010, 2012, Oracle and/or its affiliates. Rem All rights reserved. Rem Rem NAME Rem utlu121i.sql - UTiLity Upgrade Information Rem Rem DESCRIPTION Rem Provide information to users of location of new pre-upgrade Rem information tool. Rem Rem NOTES Rem Functionality replaced by preupgrd.sql script. Rem Rem MODIFIED (MM/DD/YY) Rem bmccarth 07/10/12 - Replace with DOC statements explaining how to Rem use the new utility. Rem DOC ############################################################################ ############################################################################ Note that the new preupgrd.sql script replaces the utlu121i.sql script and earlier versions of the Pre-Upgrade Information Tool. The Pre-Upgrade Information Tool, which now consists of preupgrd.sql and utluppkg.sql. 1. Make sure preupgrd.sql and utluppkg.sql (located in the admin directory of the new installation of Oracle Database 12.1) are accessible while connected to your source database, which is the database to be upgraded 2. Connect to your source database using an account with DBA privileges and execute the preupgrd.sql script. For more information on the Pre-Upgrade Information Tool, see the Oracle Database Upgrade Guide. ############################################################################ ##########################################################################
La nouveauté fondamentale, c’est la génération automatique de script correctif (fixup) pour avant et après la mise à jour, dont le contenu varie en fonction des caractéristiques de votre base. D’ ou une simplification des opérations à réaliser pour les DBA et plus d’oubli possible !
Pour ce faire, Oracle à créer un package PL spécifique nommé DBMS_PREUP qui est chargé à partir du fichier utluppkg.sql, il faut donc faire attention à ce que les deux fichiers (preupgrd.sql et utluppkg.sql) soient accessibles depuis la base source pour que le test puisse fonctionner correctement.
Ce script PL n’est pour l’instant pas wrappé et peut donc être consulté à loisir (attention plus de 10000 lignes de code).
4. Exécution du script de vérification
Connexion dans l’environnement de la base source en version 11.2 (ora112) puis changement de répertoire vers la localisation des scripts de vérification:
[oracle@easydirtech ~]$ cd /u01/app/oracle/product/12.1.0.1/rdbms/admin [oracle@easydirtech admin]$ ls pre* preupgrd.sql [oracle@easydirtech admin]$ ls utluppkg* utluppkg.sql
Base ouverte et opérationnelle nous exécutons le script avec SQL*Plus:
[oracle@easydirtech admin]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.3.0 Production on Thu Jul 25 06:35:36 2013 Copyright (c) 1982, 2011, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> @preupgrd.sql Loading Pre-Upgrade Package... Executing Pre-Upgrade Checks... Pre-Upgrade Checks Complete. ************************************************************ Results of the checks are located at: /u01/app/oracle/cfgtoollogs/ora112/preupgrade/preupgrade.log Pre-Upgrade Fixup Script (run in source database environment): /u01/app/oracle/cfgtoollogs/ora112/preupgrade/preupgrade_fixups.sql Post-Upgrade Fixup Script (run shortly after upgrade): /u01/app/oracle/cfgtoollogs/ora112/preupgrade/postupgrade_fixups.sql ************************************************************ Fixup scripts must be reviewed prior to being executed. ************************************************************ ************************************************************ ====>> USER ACTION REQUIRED <<==== ************************************************************ The following are *** ERROR LEVEL CONDITIONS *** that must be addressed prior to attempting your upgrade. Failure to do so will result in a failed upgrade. You MUST resolve the above errors prior to upgrade ************************************************************
Fichiers créés pendant la vérification :
a. Fichier spool ou journal
[oracle@easydirtech admin]$ cat /u01/app/oracle/cfgtoollogs/ora112/preupgrade/preupgrade.log Oracle Database Pre-Upgrade Information Tool 07-25-2013 06:36:26 Script Version: 12.1.0.1.0 Build: 006 ********************************************************************** Database Name: ORA112 Version: 11.2.0.3.0 Compatible: 11.2.0.0.0 Blocksize: 8192 Platform: Linux x86 64-bit Timezone file: V14 ********************************************************************** [Renamed Parameters] [No Renamed Parameters in use] **********************************************************************
La première section est dédiée aux modifications du paramétrage, la liste complète des paramètres se retrouve dans le chapitre 8 de la documentation, ou sera obtenue après l’upgrade par la requête :
SELECT NAME,VALUE FROM V$PARAMETER WHERE ISDEPREECATED=’TRUE’;
Le petit nouveau est SEC_CASE_SENSITIVE_LOGON ( les autres paramètres étant déjà dans ce statut en version précédente). il passe en mode déprécié, mais en fait cela ne change rien puisque sa fonctionnalité est maintenue pour la compatibilité descendante; il n’est pas encore dans le mode désupporté. Une manière habituelle de l’éditeur pour pousser les utilisateurs à aller vers la fonctionnalité.
il existe cependant quelques nouvelles subtilités dans le domaine de la sécurité et sans les détaillées ici, vous pouvez les trouver dans la documentation : Oracle® Database Security Guide 12c Release 1 (12.1):
********************************************************************** [Obsolete/Deprecated Parameters] --> max_enabled_roles 10.1 DESUPPORTED --> cursor_space_for_time 11.1 DESUPPORTED --> cursor_space_for_time 11.2 DESUPPORTED --> sec_case_sensitive_logon 12.1 DESUPPORTED [Changes required in Oracle Database init.ora or spfile] **********************************************************************
Petit rappel en cas d’utilisation d’un de ces paramètres le message :
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
survient pendant le démarrage de l’instance et il y a des indications supplémentaires dans le fichier de trace , comme par exemple :
Deprecated system parameters with specified values: max_enabled_roles cursor_space_for_time End of deprecated system parameter listing
Avec dans notre cas d’école:
– Une définition pour max_enabled_roles à 120
– cursor_space_for_time sur true
– sec_case_sensitive_logon sur true
La suite de la sortie du journal donne la liste de tous les composants installés dans la base, leur état actuel (idéalement VALID) et l’application ou non d’une mise à jour de ce composant ([upgrade]):
[Component List] ********************************************************************** --> Oracle Catalog Views [upgrade] VALID --> Oracle Packages and Types [upgrade] VALID --> JServer JAVA Virtual Machine [upgrade] VALID --> Oracle XDK for Java [upgrade] VALID --> Oracle Workspace Manager [upgrade] VALID --> OLAP Analytic Workspace [upgrade] VALID --> Oracle Enterprise Manager Repository [upgrade] VALID --> Oracle Text [upgrade] VALID --> Oracle XML Database [upgrade] VALID --> Oracle Java Packages [upgrade] VALID --> Oracle Multimedia [upgrade] VALID --> Oracle Spatial [upgrade] VALID --> Expression Filter [upgrade] VALID --> Rule Manager [upgrade] VALID --> Oracle Application Express [upgrade] VALID --> Oracle OLAP API [upgrade] VALID **********************************************************************
La section qui suit montre la validation de l’espace minimum requis pour tous les tablespaces :
[Tablespaces] ********************************************************************** --> SYSTEM tablespace is adequate for the upgrade. minimum required size: 1228 MB --> SYSAUX tablespace is adequate for the upgrade. minimum required size: 1491 MB --> UNDOTBS1 tablespace is adequate for the upgrade. minimum required size: 400 MB --> TEMP tablespace is adequate for the upgrade. minimum required size: 60 MB --> EXAMPLE tablespace is adequate for the upgrade. minimum required size: 310 MB [No adjustments recommended] **********************************************************************
Suivi du résultat des divers tests et du détail des actions à effectuer pour corriger en cas d’anomalie :
********************************************************************** [Pre-Upgrade Checks] ********************************************************************** WARNING: --> Enterprise Manager Database Control repository found in the database In Oracle Database 12c, Database Control is removed during the upgrade. To save time during the Upgrade, this action can be done prior to upgrading using the following steps after copying rdbms/admin/emremove.sql from the new Oracle home - Stop EM Database Control: $> emctl stop dbconsole - Connect to the Database using the SYS account AS SYSDBA: SET ECHO ON; SET SERVEROUTPUT ON; @emremove.sql Without the set echo and serveroutput commands you will not be able to follow the progress of the script. WARNING: --> Existing DBMS_LDAP dependent objects Database contains schemas with objects dependent on DBMS_LDAP package. Refer to the Upgrade Guide for instructions to configure Network ACLs. USER APEX_030200 has dependent objects. INFORMATION: --> OLAP Catalog(AMD) exists in database Starting with Oracle Database 12c, OLAP is desupported. If you are not using the OLAP Catalog component and want to remove it, then execute the ORACLE_HOME/oraolap/admin/catnoamd.sql script before or after the upgrade. INFORMATION: --> Older Timezone in use Database is using a time zone file older than version 18. After the upgrade, it is recommended that DBMS_DST package be used to upgrade the 11.2.0.3.0 database time zone version to the latest version which comes with the new release. Please refer to My Oracle Support note number 977512.1 for details. Then Pre and Post upgrade recommendations(the one Oracle made, really need to follow if you want to stay supported) ********************************************************************** [Pre-Upgrade Recommendations] ********************************************************************** ***************************************** ********* Dictionary Statistics ********* ***************************************** Please gather dictionary statistics 24 hours prior to upgrading the database. To gather dictionary statistics execute the following command while connected as SYSDBA: EXECUTE dbms_stats.gather_dictionary_stats; ^^^ MANUAL ACTION SUGGESTED ^^^ ********************************************************************** [Post-Upgrade Recommendations] ******************************************************************** ***************************************** ******** Fixed Object Statistics ******** ***************************************** Please create stats on fixed objects two weeks after the upgrade using the command: EXECUTE DBMS_STATS.GATHER_FIXED_OBJECTS_STATS; ^^^ MANUAL ACTION SUGGESTED ^^^ **********************************************************************
Enfin la dernière section du journal présente la synthèse des informations et les recommandations post mise à jour:
************ Summary ************ 0 ERRORS exist in your database. 2 WARNINGS that Oracle suggests are addressed to improve database performance. 2 INFORMATIONAL messages that should be reviewed prior to your upgrade. After your database is upgraded and open in normal mode you must run rdbms/admin/catuppst.sql which executes several required tasks and completes the upgrade process. You should follow that with the execution of rdbms/admin/utlrp.sql, and a comparison of invalid objects before and after the upgrade using rdbms/admin/utluiobj.sql If needed you may want to upgrade your timezone data using the process described in My Oracle Support note 977512.1 ***********************************
b. Fichier de correctif (Fixup) à exécuter avant la migration
Le fichier contient un récapitulatif de l’ensemble des actions à effectuer avant la migration, et les changements qui ne peuvent pas être traiter par le script sont identifiés clairement par le label ci dessous :
-- Action: ^^^ MANUAL ACTION REQUIRED ^^^
Exemple dans mon cas, aucune action n’est réalisée par le script, mais trois actions sont requises et une suggérée en tant qu’action manuelle (d’où l’utilité du script !) :
[oracle@easydirtech admin]$ cat /u01/app/oracle/cfgtoollogs/ora112/preupgrade/preupgrade_fixups.sql
SET ECHO OFF SERVEROUTPUT ON FORMAT WRAPPED TAB OFF LINESIZE 750;
BEGIN
dbms_output.put_line ('Pre-Upgrade Fixup Script Generated on 2013-07-31 04:52:03 Version: 12.1.0.1 Build: 006');
dbms_output.put_line ('Beginning Pre-Upgrade Fixups...');
END;
/
BEGIN
dbms_preup.clear_run_flag(TRUE);
END;
/
BEGIN
-- ***************** Fixup Details ***********************************
-- Name: DEFAULT_PROCESS_COUNT
-- Description: Verify min process count is not too low
-- Severity: Warning
-- Action: ^^^ MANUAL ACTION REQUIRED ^^^
-- Fix Summary:
-- Review and increase if needed, your PROCESSES value.
dbms_preup.run_fixup_and_report('DEFAULT_PROCESS_COUNT');
END;
/
BEGIN
-- ***************** Fixup Details ***********************************
-- Name: DBMS_LDAP_DEPENDENCIES_EXIST
-- Description: Check for dependency on DBMS_LDAP package
-- Severity: Warning
-- Action: ^^^ MANUAL ACTION REQUIRED ^^^
-- Fix Summary:
-- Network Objects must be reviewed manually.
dbms_preup.run_fixup_and_report('DBMS_LDAP_DEPENDENCIES_EXIST');
END;
/
BEGIN
-- ***************** Fixup Details ***********************************
-- Name: AMD_EXISTS
-- Description: Check to see if AMD is present in the database
-- Severity: Informational
-- Action: ^^^ MANUAL ACTION REQUIRED ^^^
-- Fix Summary:
-- Manually execute ORACLE_HOME/oraolap/admin/catnoamd.sql script to remove OLAP.
dbms_preup.run_fixup_and_report('AMD_EXISTS');
END;
/
BEGIN
dbms_output.put_line ('');
dbms_output.put_line ('**********************************************************************');
dbms_output.put_line (' [Pre-Upgrade Recommendations]');
dbms_output.put_line ('**********************************************************************');
dbms_output.put_line ('');
END;
/
BEGIN
dbms_output.put_line (' *****************************************');
dbms_output.put_line (' ********* Dictionary Statistics *********');
dbms_output.put_line (' *****************************************');
dbms_output.put_line ('');
dbms_output.put_line ('Please gather dictionary statistics 24 hours prior to');
dbms_output.put_line ('upgrading the database.');
dbms_output.put_line ('To gather dictionary statistics execute the following command');
dbms_output.put_line ('while connected as SYSDBA:');
dbms_output.put_line (' EXECUTE dbms_stats.gather_dictionary_stats;');
dbms_output.put_line ('');
dbms_output.put_line ('^^^ MANUAL ACTION SUGGESTED ^^^');
dbms_output.put_line ('');
END;
/
BEGIN dbms_preup.fixup_summary(TRUE); END;
/
BEGIN
dbms_output.put_line ('**************** Pre-Upgrade Fixup Script Complete *********************');
END;
/
c. Fichier post migration
Une fois encore aucune action par le script tout doit être fait ensuite (mais c’est dut à la simplicité de ma configuration) :
[oracle@easydirtech admin]$ cat /u01/app/oracle/cfgtoollogs/ora112/preupgrade/preupgrade_fixups.sql
SET ECHO OFF SERVEROUTPUT ON FORMAT WRAPPED TAB OFF LINESIZE 750;
BEGIN
dbms_output.put_line ('Pre-Upgrade Fixup Script Generated on 2013-07-31 04:52:03 Version: 12.1.0.1 Build: 006');
dbms_output.put_line ('Beginning Pre-Upgrade Fixups...');
END;
/
BEGIN
dbms_preup.clear_run_flag(TRUE);
END;
/
BEGIN
-- ***************** Fixup Details ***********************************
-- Name: DEFAULT_PROCESS_COUNT
-- Description: Verify min process count is not too low
-- Severity: Warning
-- Action: ^^^ MANUAL ACTION REQUIRED ^^^
-- Fix Summary:
-- Review and increase if needed, your PROCESSES value.
dbms_preup.run_fixup_and_report('DEFAULT_PROCESS_COUNT');
END;
/
BEGIN
-- ***************** Fixup Details ***********************************
-- Name: DBMS_LDAP_DEPENDENCIES_EXIST
-- Description: Check for dependency on DBMS_LDAP package
-- Severity: Warning
-- Action: ^^^ MANUAL ACTION REQUIRED ^^^
-- Fix Summary:
-- Network Objects must be reviewed manually.
dbms_preup.run_fixup_and_report('DBMS_LDAP_DEPENDENCIES_EXIST');
END;
/
BEGIN
-- ***************** Fixup Details ***********************************
-- Name: AMD_EXISTS
-- Description: Check to see if AMD is present in the database
-- Severity: Informational
-- Action: ^^^ MANUAL ACTION REQUIRED ^^^
-- Fix Summary:
-- Manually execute ORACLE_HOME/oraolap/admin/catnoamd.sql script to remove OLAP.
dbms_preup.run_fixup_and_report('AMD_EXISTS');
END;
/
BEGIN
dbms_output.put_line ('');
dbms_output.put_line ('**********************************************************************');
dbms_output.put_line (' [Pre-Upgrade Recommendations]');
dbms_output.put_line ('**********************************************************************');
dbms_output.put_line ('');
END;
/
BEGIN
dbms_output.put_line (' *****************************************');
dbms_output.put_line (' ********* Dictionary Statistics *********');
dbms_output.put_line (' *****************************************');
dbms_output.put_line ('');
dbms_output.put_line ('Please gather dictionary statistics 24 hours prior to');
dbms_output.put_line ('upgrading the database.');
dbms_output.put_line ('To gather dictionary statistics execute the following command');
dbms_output.put_line ('while connected as SYSDBA:');
dbms_output.put_line (' EXECUTE dbms_stats.gather_dictionary_stats;');
dbms_output.put_line ('');
dbms_output.put_line ('^^^ MANUAL ACTION SUGGESTED ^^^');
dbms_output.put_line ('');
END;
/
BEGIN dbms_preup.fixup_summary(TRUE); END;
/
BEGIN
dbms_output.put_line ('**************** Pre-Upgrade Fixup Script Complete *********************');
END;
/
4 Mise en oeuvre des recommandations
En synthèse, pour que la base soit propre avant la mise à jour, il nous faut traiter :
– Le paramétrage de la base
– La présence de la DBconsole
– Les dépendances ACL pour l’utilisation du package DBMS_LDAP
– La présence du catalogue OLAP (Analytic Meta Données)
a. Modification du paramétrage
Suppression de la définition des paramètres inutilisés:
SQL> alter system reset max_enabled_roles ; System altered. SQL> alter system reset cursor_space_for_time ; System altered. SQL> alter system reset sec_case_sensitive_logon;
La commande « reset » repositionne les valeurs par défaut, soit en dynamique si c’est possible, sinon dans le fichier spfile, un redémarrage de l’instance est alors nécessaire.
Comme pour le changement du nombre maximal de processus :
SQL> alter system set processes=300 scope=spfile ; System altered.
Suivi d’un redémarrage de l’instance
b. Suppression de la DBconsole
La DBconsole n’existant plus (remplacer par Database Administration Express) , il est judicieux de supprimer sa configuration de la base à migrer avant de réaliser l’opération, cela diminuera d’autant la durée totale. Pour cela, la distribution de la version 12c fournie un script : rdbms/admin/emremove.sql que l’on déroule pour réaliser l’opération, il est rapide et efficace.
Toujours dans l’environnement de la version d’origine, puis positionner vous sous les binaires de la version cible:
$emctl stop dbconsole [oracle@easydirtech ~]$ cd /u01/app/oracle/product/12.1.0.1/rdbms/admin [oracle@easydirtech admin]$ sqlplus / as sysdba SQL> set serveroutput on SQL> set echo on SQL> @emremove.sql SQL> Rem SQL> Rem $Header: rdbms/admin/emremove.sql /main/2 2012/07/27 01:19:53 spramani Exp $ SQL> Rem SQL> Rem emremove.sql SQL> Rem SQL> Rem Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. SQL> Rem SQL> Rem NAME SQL> Rem emremove.sql - This script removes EM Schema from RDBMS …. Finished phase 5 Starting phase 6 : Dropping Oracle Enterprise Manager related other roles ... Finished phase 6 The Oracle Enterprise Manager related schemas and objects are dropped. Do the manual steps to shutdown the DB Control if not done before running this script and then delete the DB Control configuration files PL/SQL procedure successfully completed.
Il reste quelques fichiers de configuration sous le répertoire HOME de la version 11G, ils ne sont pas génant et disparaitront après le nettoyage final.
c. Traitements des ACL pour les packages réseaux DBMS_LDAP
Depuis la version 11.2 pour utiliser certains packages d’outils réseaux comme DBMS_LDAP, qui permet entre autres d’aller parcourir une arborescence LDAP, il est nécessaire de créer un fichier d’autorisation (ACL – Access Control List) et d’associer ces autorisations à des cibles,ceci à l’aide des packages DBMS_NETWORK_ACL_ADMIN.CREATE_ACL() et DBMS_NETWORK_ACL_ADMIN_ASSIGN_ACL().
Pour un exemple concret vous pouvez lire cette entrée . Dans notre cas, c’est la configuration APEX par défaut qui contient des appels au package, nous n’en tiendrons pas compte. Si vous utilisez APEX et une authentification LDAP, il vous faudra définir et associer les droits d’accès correspondant.
d. Suppression de la configuration OLAP
En version 12c , les fonctionnalités OLAP sont toujours présentes, ce qui n’est plus supporté c’est le catalogue de Méta Données CWM (Common Warehouse Metamodel) , faisant partie des méta données analytiques.
Si vous l’utilisiez, il est plus que temps de prévoir une alternative, sinon le plus simple est de supprimer les entrées correspondantes du dictionnaire grâce au script catnoamd.sql. On trouve ce script sous $ORACLE_HOME/olap/admin/ .
On peut exécuter celui de la version 11.2 ou celui de la version 12.1, cela ne pose pas de problème; à condition d’être positionné au préalable dans le bon répertoire.
Exemple avec celui de la version 12.1 :
[oracle@easydirtech admin]$ . oraenv ORACLE_SID = [ora112] ? ora112 The Oracle base remains unchanged with value /u01/app/oracle [oracle@easydirtech admin]$ cd /u01/app/oracle/product/12.1.0.1/olap/admin [oracle@easydirtech admin]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.3.0 Production on Wed Jul 31 10:23:31 2013 Copyright (c) 1982, 2011, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> @catnoamd Synonym dropped. … PL/SQL procedure successfully completed. 1 row deleted. SQL> select * from dba_registry where COMP_ID='AMD' ; no rows selected
f. Statistiques sur les objets du dictionnaire
Exécution du calcul des statistiques sur les objets du dictionnaire pour que la procédure de mise à jour ce déroule plus rapidement. Cette étape est importante si vous souhaitez réduire au minimum le temps de la mise à jour. même si pour mon cas; je n’ai pas vu avec mes bases de test d’écart notable.
A noter que le calcul à duré une vingtaine de secondes :
[oracle@easydirtech bin]$ time sqlplus /nolog <<! > connect / as sysdba > EXECUTE dbms_stats.gather_dictionary_stats; > ! SQL*Plus: Release 11.2.0.3.0 Production on Wed Jul 31 10:45:32 2013 Copyright (c) 1982, 2011, Oracle. All rights reserved. SQL> Connected. SQL> PL/SQL procedure successfully completed. SQL> Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options real 0m19.655s user 0m0.011s sys 0m0.024s
6. Sauvegarde
Dernière étape, la sauvegarde la base dans l’état, ne l’oubliez pas ce n’est pas parce que l’on voyage vers le ciel que l’on ne doit pas être rigoureux et professionel. Pour moi, il s’agit de pouvoir rejouer mon opération de mise à jour autant de fois que nécessaire pour les tests et la suite de cette série. Je vous laisse le choix de la méthode, sur ma plateforme de test j’ai simplement arrêter proprement la base et fait une copie de l’ensemble des fichiers dans un autre répertoire.
Tout est prêt , la première méthode que nous utiliserons sera avec l’assistant fourni « dbua », toujours en mode silencieux, cela dans le prochain épisode, restez avec nous ….
