Impasse suite à une tentative d'export

Après avoir tenté un export d'un schéma sur une base de données avec l'outil EXPDP, j'ai obtenu une erreur, qui malheureusement, je ne me souviens pas. Suite à cette erreur, j'ai tenté à nouveau un export mais sans succès car rien n'aboutissait.

J'ai alors vérifié l'état de la session dans la vue « v$session » et, j'ai remarqué que ma session provenant de l'outil EXPDP était bloquée par une autre. La session bloquante correspondait à ma précédente session qui était tombée en erreur.

Pour me permettre de réaliser l'export, j'ai alors décidé de terminer la session avec la commande "Alter system kill session". À ma grande surprise, la base de données m'a retournée une erreur me disant que la session n'existe pas. Suite à cela, j'ai décidé d'être plus radicale puis de terminer la processus de la session directement sur le serveur. Encore là, je ne trouvais pas de processus correspondant à la session. Me voilà dans une impasse... Le seul moyen que j'ai pu faire pour m'en sortir a été de redémarrer l'instance de la base de données avec la commande "shutdown abort" car la commande "shutdown immediate" ne parvenait pas à arrêter les processus.

Si vous avez déjà rencontré ce genre de problème et que vous l’avez résolu autrement, merci de partager avec moi.

OOW 2010 – Database Track – Jour 4…le dernier!

C'est peut-être le dernier jour mais non le moindre en fait de contenu. Aujourd'hui, j'ai eu droit à des conférences sur l'optimisation avec les outils ASH et AWR et, une autre à propos d'Oracle Active Data Guard. Comme toutes les autres sessions, elles furent très intéressantes et remplies d'informations pertinentes.

La première conférence était présentée par nul autre que Thomas Kyte. Disons que ça commence bien la journée! Comme d'habitude, il a su me captiver dès la première seconde et ce, jusqu'à la toute dernière.

Ce que j'ai particulièrement aimé (et que j'aimerai probablement toujours), c'est les façons d'effectuer de l'optimisation à partir de simples lignes de commandes avec un outil tel que SQL*Plus. Les raisons sont bien simples car en mandat nous n'avons pas toujours recours à des outils graphiques et, aussi, j'aime voir les commandes exécutées et les résultats. Je ne suis pas trop fervent des boites noirs par lesquels une multitude de commandes sont exécutées sans que nous ne sachions ce qui est accomplis.

Alors, voici quelques faits à propos d'ASH ainsi qu'AWR :

ASH

• ASH = Active Session History
• ASH est toujours actifs, donc, lorsqu'un problème survient, on peut directement s'y référer puis comparer les valeurs actuelles avec celles précédant le problème.
• Simplifie l'investigation car autrement un problème peut être difficilement reproduit
• Ce mécanisme accède directement à la structure du noyau de la base de données
• Ne contient pas tous les énoncés SQL qui ont été exécutés. On y retrouve seulement ceux qui ont été actifs et qui sont plus " gourmands "
• Un échantillon d'énoncé SQL actif est collecté à chaque seconde en mémoire. Le processus " MMON Lite (MMNL) " s'occupe d'accomplir cette tâche.
• L'échantillon est conservé dans une cache (buffer) circulaire dans le SGA. Par défaut, il a la dimension de 2 MB par CPU (consulter la vue V$SGASTAT pour la taille totale utilisée)
• Les données d'ASH sont principalement consultées via la vue V$ACTIVE_SESSION_HISTORY
• Une partie de l'échantillon utilisé par ASH alimente l'AWR
• Permet d'effectuer une analyse basée sur le temps de traitement sur la base de données (DB Time)
• Les données proviennent principalement des vues V$SESSION et V$SESSION_WAIT
• Si nous effectuons la somme des secondes d'ASH, nous obtiendrons le " DB Time "
• La page " Top Activity " dans Oracle EM est basée sur les données d'ASH. Le pourcentage d'activité correspondant à un énoncé SQL correspond au pourcentage du " DB Time "
• Il ne faut pas utiliser des fonctions telles que MIN, MAX et AVG avec les données provenant d'ASH car les résultats seront biaisés. Les données proviennent d'échantillon et les longs traitements fausseront les résultats.
• Le contenu d'ASH peut être exporté puis chargé dans une table ou un chiffrier
• ASH n'est pas un résultat de trace mais plutôt de l'échantillonnage

AWR

• AWR = Automatic Workload Repository
• AWR est présent dans toutes les éditions de base de données
• Il est constitué de statistiques de base (ex. physical reads), de statistiques sur les énoncés SQL (disk read par SQL), mesures (physical reads/seconde) et d'information (échantillon) provenant d'ASH.
• Un cliché (snapshot) provient d'un processus qui extrait les données de la mémoire puis qui les écrient sur disque.
• Ne jamais comparer deux clichés dont un redémarrage de base de données a eu lieu durant la période couverte par les clichés
• Le package DBMS_WORKLOAD_REPOSITORY permet de gérer l'AWR
• La rétention par défaut est de 7 jours, Oracle supprime automatiquement les données plus anciennes. Il est recommandé (bonne pratique) de conserver un minimum d'un mois.

En conclusion, Oracle Open World fut une expérience formidable. J'ai grandement apprécié les conférences. Je fus très impressionné par l'ampleur de l'événement. Bravo à Oracle et je leur dit : " Two Thumbs Up "

Attends ! Ben oui, je n'ai que ça à faire !

Voici un script que j’aime bien utilisé pour visualiser les événements d’attente propre à une session qui est en cours d’exécution :

REM ****************************************************
REM * Script: sess_wait.sql
REM * Titre : Afficher les wait events d'une session
-- ****************************************************
set pagesi 999 feed off linesi 500 trimspoo on veri off

col event format A40

-- ****************************************************
-- Afficher les sessions en cours
-- ****************************************************
select SID,
substr(username,1,15) username,
status,
substr(machine,1,20) machine,
program
from v$session
where username is not null
and status != 'KILLED'
order by program, username, status;

-- Choisir une session
Accept L_sid prompt 'Entrez le SID (Enter = Tous) : '

-- ****************************************************
-- Afficher les événements propres à la session choisie
-- ****************************************************
Select substr(event,1,30) event,total_waits,time_waited
from v$session_event
where sid=nvl('&L_sid',sid)
order by total_waits;

-- ****************************************************
-- Afficher l'événement d'attente actuel de la session
-- ****************************************************
Select *
from v$session_wait
where sid=nvl('&L_sid',sid);

Activer la trace sur une session

La procédure "SET_SQL_TRACE_IN_SESSION" du package d'Oracle "DBMS_SYSTEM" permet d'activer et de désactiver la trace SQL sur n'importe quelle session en cours. L'activation d'une trace à partir de cette procédure est l'équivalent d'activer l'évènement "10046" de niveau 1.

Syntaxe :

DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION
(
sid NUMBER,
serial# NUMBER,
sql_trace BOOLEAN
);

Exemples de trace sur une session dont le SID est 460 et in SERIAL# équivalent à 222 :

Activation
EXEC dbms_system.set_sql_trace_in_session (460, 222, true);

Désactiver
EXEC dbms_system.set_sql_trace_in_session (460, 222, false);

Vous pouvez obtenir la valeur du "SID" et "SERIAL#" en consultant la vue dynamique "V$SESSION".

La colonne "SQL_TRACE" de la vue dynamique "V$SESSION" indique si une trace est en cours sur la session. Lors de l'activation de la trace, la valeur de cette colonne reste "DISABLED" tant qu'il n'y a pas d'opération d'exécuté. Même comportement lors de la désactivation.

Par défaut, aucun privilège et synonyme n'existe pour le package DBMS_SYSTEM. Se connecter sous SYS ou sinon, octroyer les droits à l'utilisateur désiré.