Blog Oracle de Zakaria EL HAMDAOUI » Non classé

Techniques de FLASHBACK ORACLE

ora_home — Sun, 06 Oct 2013 18:13:49 +0000

1- Vue d’ensemble
Les techniques de flashback sont un ensemble de fonctionnalités proposées par Oracle qui permettent de voir l’état passé de données, ou de ramener une table ou la totalité de la base de données dans le passé.
Les fonctionnalités proposées sont les suivantes :

- Flashback Query : permet de lire les données telles qu’elles étaient à un instant dans le passé (appary en version 9i).

- Flashback Version Query : permet de voir toutes les versions d’une ligne sur un certain intervelle de temps (apparu en version 10).

- Flashback Transaction Query) : permet de voir les modifications réalisées par une ou plusieurs transactions sur un certain intervalle de temps (apparue en version 10).

- Flashback Transaction : permet d’annuler les modifications d’une transaction, et de ses transactions dépendantes( apparue en version 11).

- Flashback Data Archive (Oracle Total Recall) : permet de conserver sur le long terme, toutes les modifications apportées à une table (apparue en version 11).

- Flashback Table : permet de ramener une table dans l état où elle était, juste avant sa suppression (apparue en version 10).

- Flashback Database : permet de ramener la totalité de la base de données dans l’état où elle était à un certain moment dans le passé (apparue en version 11).

Seule la fonctionnalité Flashback Query est disponible dans toutes les éditions de la base de données (et donc notamment en Standart Edition).
La fonctionnalité Flashback Data Archive, est une option de l’Entreprise Edition et nécessite donc, une licence supplémentaire.

Les autres fonctionnalités de Flashback nécessitent l’Entreprise Edition, mais sans option supplémentaire.
Les fonctionnalités de Flashback de requête (Flashback Query, Flashback Version Query et Flashback Transaction Query), et la fonctionnalité de Flashback Table, utilisent les informations d’annulation pour revenir en arrière. Le paramètre UNDO_RETENTION et le tablespace d’annulation doivent donc être correctement dimensionnés, si vous souhaitez pouvoir retourner loin dans le passé.

2- Niveau ligne
Flashback Query

Pour lire les données telles qu’elles étaient à un instant donné du passé, vous pouvez utiliser l’option AS OF sur une table présente dans la clause FROM d’une requête SELECT.

Syntaxe :
Nom_table AS OF { TIMESTAMP | SCN } expression

L’option TIMESTAMP permet de retourner à un instant donné du passé en indiquant une date et une heure ; dans ce cas, l’expression doit être de type TIMESTAMP. L’option SCN permet de retourner à un instant donné du passé en indiquant un numéro SCN ; dans ce cas, l’expression doit être un nombre.

SQL> select * from emp where empno = 7369;

EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
---------- ---------- --------- ---------- -------- ---------- ---------- --------------------------------
7369 SMITH CLERK 7902 17/12/80 800 20

SQL> select to_char(sysdate, 'DD/MM/YYY HH24:MI:SS') "SYSDATE",
2 dbms_flashback.get_system_change_number "SCN"
3 FROM dual;

SYSDATE SCN
------------------ ----------
06/10/013 15:31:48 3446120

La fonction GET_SYSTEM_Change_NUMBER du package DBMS_FLASHBACK retourne le numéro SCN courant. Il faut le privilège EXECUTE sur le package pour l’utiliser.

Un peu plus tard :

SQL> update emp set ename = 'ZAKARIA' where empno = '7369';
1 ligne mise à jour.
SQL> commit;
Validation effectuée.

SQL> select to_char(sysdate, 'DD/MM/YYY HH24:MI:SS') "SYSDATE",
2 dbms_flashback.get_system_change_number "SCN"
3 FROM dual;

SYSDATE SCN
------------------ ----------
06/10/013 15:38:41 3446364

Maintenant je vais retourner vers le passé avec la notion du temps :

SQL> SELECT * FROM EMP
2 AS OF TIMESTAMP SYSTIMESTAMP - INTERVAL '10' minute
3 where empno = 7369;

EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
--------- ---------- --------- ---------- -------- ---------- ---------- ----------
7369 SMITH CLERK 7902 17/12/80 800 20

Ou bien avec la notion du SCN :

SQL> SELECT * FROM EMP
2 AS OF SCN 3446120
3 where empno = 7369;

EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
---------- ---------- --------- ---------- -------- ---------- ---------- ----------
7369 SMITH CLERK 7902 17/12/80 800 20

NB : c’est un résumé de la partie FLASHBACK du livre « Administration ORACLE 11g » de OLIVIER HEURTEL.

Statistiques ORACLE, Package DBMS_STAT

ora_home — Sun, 23 Jun 2013 13:38:40 +0000

La semaine dernière, et lors d’une mission de consulting chez un opérateur télécoms, on a confronté un problème de performance qui concerne les statistiques.

Bref, le problème est le suivant :

L’équipe de développement a développé une application qui utilise une base de données Oracle 10g. Au niveau du serveur de recette l’application marche très bien, avec un temps de réponse raisonnable pour la plus part des requêtes, mais une fois l’application est en production, oooops le temps de réponse est vraiment anormale (Exemple : une requête en recette : 15s, en prod : 3 minutes !!!!!!!!!!!!!).

NB : Avant mon arrivé, ils ont bien vérifié que la configuration des 2 serveurs (Recette et Prod) ont les mêmes caractéristiques . Les 2 BD ont aussi la même volumétrie.

Avant de commencer d’inspecter les plans d’exécutions, il fallait voir les statistiques utilisées par Oracle. On sait parfaitement qu’Oracle se base sur les statistiques collectées pour déterminer le meilleur plan d’exécution. Si on arrive à avoir les mêmes statistiques que le serveur de recette, il nous suffit de rejouer son scénario et si le problème vient réellement d’un plan d’exécution différent, alors on va pouvoir identifier la ou les requêtes en question.

Pour cela, on va sauvegarder les statistiques du serveur de recette :

1- Créer une table pour sauvegarder les statistique : (USER à le schéma qui utilise l ’application, NOM_TABLE_STATS à Nom de la table des statistiques)

exec DBMS_STATS.CREATE_STAT_TABLE (ownname=>’USER’, stattab=>’NOM_TABLE_STATS’);

2- Alimenter la table NOM_TABLE_STATS par les statistiques du serveur de recette (A travers un Export du package DBMS_STATS)

exec DBMS_STATS.EXPORT_SCHEMA(‘USER’,’NOM_TABLE_STATS’);

3- Au niveau du serveur PROD, importer les statistique déjà collectées :
– Pour cela, il faut déjà supprimé les statistiques du PROD par la commande suivante :
exec DBMS_STATS.DELETE_SCHEMA_STATS(‘USER’,FORCE=>TRUE);

– Importer les statistiques :
exec DBMS_STATS.IMPORT_SCHEMA_STATS(‘USER’,’NOM_TABLE_STATS’);

Et viola, maintenant on a les même statistiques au niveau des 2 serveurs, après les tests au niveau de la PROD, on a constaté que le temps de réponse est très raisonnable.

NB : Normalement c’est la première étape qu’on doit faire, il y a des cas où le problème persiste toujours, dans ce cas il faut revoir et analyser les plans d’exécutions pour voire s’il y a des full scan ou des mauvaises utilisation d’index ou bien autre chose.

Générer les DDL d’un objet (table,index,…)

ora_home — Mon, 15 Apr 2013 11:54:07 +0000

A partir de la version 9i, Oracle a introduit le paquet DBMS_METADATA , qui peut être utilisé pour récupérer des définitions d’objets que DDL.
L’exemple ci-dessous montre comment utiliser ce paquet :

Je vais creer une table Test :

SQL> CREATE TABLE Test
(Num integer, Nom varchar2(20), Prenom varchar2(20));

Maintenant, je vais générer le DDL de cette table :

SQL> SELECT dbms_metadata.get_ddl('TABLE', TABLE_NAME)
2 from user_tables
3 where TABLE_NNAME = ('Test');

Le résultat est :

DBMS_METADATA.GET_DDL('TABLE',TABLE_NAME)
--------------------------------------------------------------------

CREATE TABLE "SYS"."TEST"
( "NUM" NUMBER(*,0),
"NOM" VARCHAR2(20),
"P

Oppssss !!!! c’est quoi ça !!!
Alors on doit positionner les paramétres d’affichage au niveau de SQLPLUS :

SQL> SET LONG 50000
SQL> SET PAGES 500
SQL> SET LINES 200

Maintenant, on Ré-exécute la même reqûete :

DBMS_METADATA.GET_DDL('TABLE',TABLE_NAME)
----------------------------------------------------------------------------

CREATE TABLE "SYS"."TEST"
( "NUM" NUMBER(*,0),
"NOM" VARCHAR2(20),
"PRENOM" VARCHAR2(20)
) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "SYSTEM"

Essst voilà, notre code DDL est généré :).

NB : Vous pouvez aussi générer le DDL d’une table DROPé, et ce avec la même reqûete (SELECT dbms_metadata.get_ddl(‘TABLE’, TABLE_NAME)
2 from user_tables
3 where TABLE_NNAME = (‘Test’);) Mais vous devez l’adapter on utilisant FROM user_recyclebib

A+

Instruction MERGE

ora_home — Wed, 12 Dec 2012 14:38:22 +0000

Par : Zakaria EL HAMDAOUI
Consultant Oracle

A travers ce petit article, je vais essayer de présenter l’instruction « MERGE », qui malheureusement n’est pas assez utilisée par les développeurs.

MERGE, permet de mettre à jour ou d’insérer des données dans une table, de façon conditionnelle.

- Exécute une instruction UPDATE si la ligne existe et une instruction INSERT s’il s’agit d’une nouvelle ligne :

- Evite des mises à jour distinctes

- Améliore les performances et facilite l’utilisation

- S’avère particulièrement utile dans les applications de data warehouse

SQL a été étendu pour inclure l’instruction MERGE. Cette instruction vous permet de mettre à jour ou d’insérer une ligne dans une table de façon conditionnelle, évitant ainsi l’utilisation de plusieurs instructions UPDATE. La mise à jour ou l’insertion dans la table cible dépend d’une condition définie dans la clause ON.
Etant donné que l’instruction MERGE combine les commandes INSERT et UPDATE, vous devez disposer des privilèges INSERT et UPDATE sur la table cible et du privilège SELECT sur la table source.
L’instruction MERGE est déterministe. Vous ne pouvez pas mettre à jour plusieurs fois la même ligne de la table cible dans la même instruction MERGE.
Vous pouvez également utiliser des boucles PL/SQL et plusieurs instructions LMD. Cependant, l’instruction MERGE est plus facile à utiliser et s’exprime plus simplement sous la forme d’une instruction SQL.
L’instruction MERGE convient à plusieurs applications de data warehouse. Par exemple, ce type d’application peut nécessiter l’utilisation de données provenant de plusieurs sources, et certaines de ces données peuvent être en double. A l’aide de l’instruction MERGE, vous pouvez ajouter ou modifier des lignes sous certaines conditions.

Syntaxe de l’instruction MERGE

MERGE INTO table_name table_alias
USING (table|view|sub_query) alias
ON (join condition)
WHEN MATCHED THEN
UPDATE SET
col1 = col_val1,
col2 = col2_val
WHEN NOT MATCHED THEN
INSERT (column_list)
VALUES (column_values);

Clause INTO désigne la table cible dans laquelle vous allez réaliser une insertion ou une mise à jour.

Clause USING identifie la source des données à mettre à jour ou à insérer ; il peut s’agir d’une table, d’une vue ou d’une sous-interrogation.

Clause ON désigne la condition en fonction de laquelle l’instruction MERGE réalise une mise à jour ou une insertion.

WHEN MATCHED |indique au serveur comment répondre aux résultats obtenus avec la condition de jointure.

WHEN NOT MATCHED

Exemple de fusion de lignes

MERGE INTO copy_emp c
USING employees e
ON (c.employee_id = e.employee_id)
WHEN MATCHED THEN
UPDATE SET
c.first_name = e.first_name,
c.last_name = e.last_name,
c.email = e.email,
c.phone_number = e.phone_number,
c.hire_date = e.hire_date,
c.job_id = e.job_id,
c.salary = e.salary,
c.commission_pct = e.commission_pct,
c.manager_id = e.manager_id,
c.department_id = e.department_id
WHEN NOT MATCHED THEN
INSERT VALUES(e.employee_id, e.first_name, e.last_name,
e.email, e.phone_number, e.hire_date, e.job_id,
e.salary, e.commission_pct, e.manager_id,
e.department_id);

L’exemple ci-dessus compare les valeurs EMPLOYEE_ID de la table COPY_EMP avec les valeurs EMPLOYEE_ID de la table EMPLOYEES. Lorsqu’une correspondance est trouvée, la ligne de la table COPY_EMP est mise à jour pour qu’elle corresponde à la ligne de la table EMPLOYEES. Si la ligne n’est pas trouvée, elle est insérée dans la table COPY_EMP.

La condition c.employee_id = e.employee_id est évaluée. La table COPY_EMP étant vide, la condition renvoie un message indiquant l’absence de correspondance. La logique correspond à la clause WHEN NOT MATCHED et la commande MERGE insère les lignes de la table EMPLOYEES dans la table COPY_EMP.
Lorsque la table COPY_EMP comprend des lignes et que les ID employés correspondent dans les deux tables (tables COPY_EMP et EMPLOYEES), les lignes présentes dans la table COPY_EMP sont mises à jour pour qu’elles correspondent à celles de la table EMPLOYEES.

V$SQLTEXT

ora_home — Mon, 01 Oct 2012 14:02:14 +0000

V$SQLTEXT : texte SQL complet sans troncature, affiché sur plusieurs lignes.

TUNING : REGLAGE DE LA SHARED POOL

ora_home — Mon, 01 Oct 2012 12:21:36 +0000

1. REGLAGE DE LA SHARED POOL

V$LIBRARYCACHE : contient des statistiques relatives à un type d’élément conservé dans le cache « library ».

• NAMESPACE : Les éléments qui reflètent l’activité du cache « library » relative aux instructions SQL et aux blocs PL/SQL : SQL AREA, TABLE/PROCEDURE, BODY et TRIGGER
• GETS : affiche le nombre total de demandes d’informations sur l’élément correspondant.
• PINS : pour chaque zone, PINS affiche le nombre d’exécutions d’instructions ou de procédures SQL.
• RELOADS : si l’application appelle l’exécution d’une instruction SQL et que, dans le cache « library », la zone SQL partagée contenant la représentation analysée de cette instruction a été libérée afin de faire de la place à une autre instruction ou en raison de l’invalidation des objets indiqués par l’instruction, le serveur Oracle recharge implicitement cette instruction et, par conséquent, la réanalyse. Le nombre de rechargements est calculé pour chaque espace de nom.
• INVALIDATIONS : lorsqu’un objet est modifié, il est possible qu’il existe un meilleur chemin d’exécution pour toutes les instructions utilisant cet objet. C’est la raison pour laquelle le serveur Oracle marque toutes les exécutions utilisant un objet modifié comme non valides

 LIBRARY CACHE HIT RATIO >90%:

SELECT SUM(PINS-ROLOADS)/SUM(PINS)*100 ‘’Library cahce HIT-Ratio’’
FROM V$LIBRARYCACHE;

 RELOADS TO PINS <1%

SELECT SUM(ROLOADS)/SUM(PINS)*100 ‘’Reload-Ratio’’
FROM V$LIBRARYCACHE;

 PINS TO RELOADS

SELECT sum(pins), sum(reloads), sum(pins) * 100 / sum(pins+reloads) “Pin Hit%” FROM v$librarycache;

V$SQLAREA: statistiques détaillées sur tous les curseurs partagés et 1000 premiers caractères de l’instruction SQL.

V$SQL : cette vue répertorie les statistiques sur la zone SQL partagée et contient une ligne pour chaque enfant du texte SQL entré à l’origine. V$SQL est une vue similaire à V$SQLAREA, excepté le fait qu’elle ne comporte pas de clause GROUP BY qui peut rendre l’interrogation de la vue V$SQLAREA plus coûteuse.

V$SQLTEXT : texte SQL complet sans troncature, affiché sur plusieurs lignes.

V$DB_OBJECT_CACHE : objets de la base de données mis en mémoire cache, y compris les packages ; comprend également les tables et les synonymes lorsque ces objets sont référencés dans des instructions SQL.

V$SHARED_POOL_RESERVED :Cette vue facilite le réglage du pool et de l’espace réservés au sein de la zone de mémoire partagée.

• FREE_SPACE : est la quantité totale d’espace libre dans la liste d’espaces réservés.
• AVG_FREE_SIZE : est la taille moyenne de la mémoire libre dans la liste d’espaces réservés.
• MAX_FREE_SIZE : est la taille de la plus grande zone de mémoire libre dans la liste d’espaces réservés
• REQUEST_MISSES : est le nombre de fois où la liste d’espaces réservés ne possédait pas de mémoire libre pour satisfaire la demande et a commencé à retirer des objets de la iste LRU.
• REQUEST_FAILURES : est le nombre de fois où une demande n’a pas été satisfaite en raison de l’insuffisance de mémoire.
• LAST_FAILURE_SIZE : est la taille de la dernière demande non satisfaite

objectif :

REQUEST_FAILURES ou REQUEST_MISSES proche de 0 ou/et n’augmentent pas.
SHARED_POOL_RESERVED_SIZE~=10% de SHARED_POOL_SIZE
 DBMS_SHARED_POOL .ABORTED_REQUEST_THRESHOLD: permet de restreindre la quantité de mémoire partagée à vider avant de signaler une erreur ORA-4031, afin de limiter l’étendue d’un vidage éventuellement provoqué par la présence d’un objet volumineux.
V$ROWCACHE : information sur dictionary cache :
• PARAMETER : donne le nom (de categorie) du cache du dictionnaire de données faisant l’objet de l’état.
• GETS : affiche le nombre total de demandes d’informations sur l’élément correspondant (par exemple, pour la ligne contenant des statistiques sur les descriptions de fichier, cette colonne indique le nombre total de demandes de données de description de fichier).
• GETMISSES : affiche le nombre de demandes de données ayant échoué en mémoire cache.