FAQ OracleConsultez toutes les FAQ
Nombre d'auteurs : 16, nombre de questions : 138, dernière mise à jour : 16 février 2013
Sommaire→Administration→Système- Comment afficher l'encombrement disque/mémoire des unités de traitement ?
- Comment connaître les bases en cours d'utilisation ?
- Comment afficher l'encombrement mémoire des pools partagés ?
- Comment mesurer les I/O sur les fichiers ?
- Comment afficher le nom du composant, l'état et la version des éléments du registre ?
- Comment afficher la date, l'action et la version des patches/upgrades ?
- Quelle est la procédure pour déplacer des objets de SYSAUX (10g) ?
- Comment connaître le systéme d'exploitation qui héberge le SGBDR ?
- Comment savoir si une base source est valide pour une migration en 10g ?
- Comment détecter/supprimer les sessions qui sont marqués Killed ?
- Comment modifier l'emplacement de la région de restauration flash (10g) ?
- Quelles sont les fonction de SMon (System Monitor) ? (en 9i)
- Comment reveiller le SMON pour nettoyer les segements temporaires ?
- Comment trouver les sessions qui utilisent la tablespace temporaire ?
La place occupée par les unités de traitement est interrogeable depuis la vue : USER_OBJECT_SIZE
- NAME Contient le nom de l'objet
- TYPE Contient le type de l'objet (TYPE, TYPE BODY, TABLE, VIEW, SYNONYM,SEQUENCE, PROCEDURE, FUNCTION, PACKAGE, PACKAGE BODY, JAVA SOURCE, JAVA CLASS, JAVA RESOURCE ou JAVA DATA)
- SOURCE_SIZE Contient la taille en octets du code source
- PARSED_SIZE Contient la taille en octets du code DIANA (incluant les références aux objets sous-jacents)
- CODE_SIZE Contient la taille du code chargé en mémoire à l'exécution
- ERROR_SIZE Contient la taille des messages d'erreur
SQL> SELECT *
2 FROM USER_OBJECT_SIZE
3 WHERE TYPE IN ('PACKAGE BODY','PACKAGE','FUNCTION','PROCEDURE')
4 ORDER BY TYPE,NAME ;
NAME TYPE SOURCE_SIZE PARSED_SIZE CODE_SIZE ERROR_SIZE
------------------------------ ------------- ----------- ----------- ---------- ----------
LIGNESALAIRE FUNCTION 280 261 563 0
PWD_DECODE FUNCTION 459 234 702 0
RETOURNE_PARAM FUNCTION 885 239 990 0
SRV_LECTURE_PARAMETRE FUNCTION 458 342 697 0
TEST_XX FUNCTION 869 269 1119 0
PKG_CORRECTION PACKAGE 414 1493 362 0
TEST_RECORD PACKAGE 233 761 875 0
PKG_CORRECTION PACKAGE BODY 11408 0 12467 0
TEST_RECORD PACKAGE BODY 403 0 1376 0
DEBUG PROCEDURE 1153 475 1343 0
DISPLAY_IMAGE PROCEDURE 894 509 1277 0
ECRITURE_ERREUR PROCEDURE 755 1517 673 0
La première ligne indique que la fonction LIGNESALAIRE occupe 280 octets de code source et nécessite 563 octets en mémoire à l'exécution.
Pour connaître les bases de données actuellement en cours d'utilisation sur votre poste il vous suffit :
Sous Windows d'aller dans le gestionnaire des services : Click droit sur le poste de travail => gérer => services et applications => services
puis de regarder tous les services commençant par OracleService et qui sont formatés de la sorte OracleService<SID> (où SID correspond au nom de l'instance associée)
Sous Linux Vous pouvez lancer la commande suivante : ps -ef | egrep pmon_ | grep -v grep
Voici un script permettant d'afficher la taille allouée, utilisée et libre de chaque pool :
COL "Total octets alloués" FORMAT A20
COL "octets utilisés" FORMAT A20
COL "octets libres" FORMAT A20
SELECT
a.POOL "Pool"
, b.Octets || ' (' || ROUND(b.Octets/1024/1024) || ' Mo)' "Total octets alloués"
, (b.Octets-a.BYTES) || ' (' || ROUND((b.Octets-a.BYTES)/1024/1024) || ' Mo)' "octets utilisés"
, a.BYTES || ' (' || ROUND(a.BYTES/1024/1024) || 'Mo)' "octets libres"
FROM V$SGASTAT a,
( SELECT POOL, SUM(BYTES) Octets, SUM(BYTES/1024/1024) Mo
FROM V$SGASTAT
WHERE POOL IS NOT NULL
GROUP BY POOL
ORDER BY POOL) b
WHERE NAME = 'free memory'
AND a.POOL = b.POOL
ORDER BY a.POOL ;
Ainsi que le résultat de l'exécution
SQL> COL "Total octets alloués" FORMAT A20
SQL> COL "octets utilisés" FORMAT A20
SQL> COL "octets libres" FORMAT A20
SQL> SELECT
2 a.POOL "Pool"
3 , b.Octets || ' (' || ROUND(b.Octets/1024/1024) || ' Mo)' "Total octets alloués"
4 , (b.Octets-a.BYTES) || ' (' || ROUND((b.Octets-a.BYTES)/1024/1024) || ' Mo)' "octets utilisés"
5 , a.BYTES || ' (' || ROUND(a.BYTES/1024/1024) || 'Mo)' "octets libres"
6 FROM V$SGASTAT a,
7 ( SELECT POOL, SUM(BYTES) Octets, SUM(BYTES/1024/1024) Mo
8 FROM V$SGASTAT
9 WHERE POOL IS NOT NULL
10 GROUP BY POOL
11 ORDER BY POOL) b
12 WHERE NAME = 'free memory'
13 AND a.POOL = b.POOL
14 ORDER BY a.POOL
15 /
Pool Total octets alloués octets utilisés octets libres
----------- -------------------- -------------------- --------------------
java pool 29360128 (28 Mo) 0 (0 Mo) 29360128 (28Mo)
large pool 8404644 (8 Mo) 304668 (0 Mo) 8099976 (8Mo)
shared pool 41943040 (40 Mo) 22455544 (21 Mo) 19487496 (19Mo)
Via le script suivant :
set linesize 250
col file_name format a40
select b.file_name, a.file#, a.cnt
from (select file#, count(1) cnt
from v$bh
group by file#) a,
dba_data_files b
where a.file# = b.file_id;
Via la requête suivante, à partir de la 9i :
SELECT COMP_NAME,
STATUS,
VERSION
FROM DBA_REGISTRY
ORDER BY COMP_NAME;
COMP_NAME STATUS VERSION
---------------------------------- ------ -----------
JServer JAVA Virtual Machine VALID 10.2.0.2.0
Oracle Database Catalog Views VALID 10.2.0.2.0
Oracle Database Java Packages VALID 10.2.0.2.0
Oracle Database Packages and Types VALID 10.2.0.2.0
Oracle Expression Filter VALID 10.2.0.2.0
Oracle Text VALID 10.2.0.2.0
Oracle Workspace Manager VALID 10.2.0.3.0
Oracle XDK VALID 10.2.0.2.0
Oracle XML Database VALID 10.2.0.2.0
Oracle interMedia VALID 10.2.0.2.0
À partir de la version 10.1.0.5 cpu2006jan, via le requête suivante :
SELECT ACTION_TIME,
ACTION,
VERSION,
ID
FROM DBA_REGISTRY_HISTORY
ORDER BY to_timestamp(ACTION_TIME,'DD.MM.YYYY HH24:MI:SSXFF');
ACTION_TIME ACTION VERSION ID
---------------- -------- ------------ ----------
14.02.2006 10:28 CPU 4751932
07.03.2006 11:30 UPGRADE 10.2.0.2.0
Lors d'une réorganisation de base de données, si l'on souhaite déplacer certains objets
du tablespace SYSAUX vers d'autres tablespaces, comment procéder ?
Cette requête va nous donner la procédure à utiliser pour le déplacement en fonction des objets
SQL> SELECT occupant_name, schema_name, move_procedure
2 FROM v$sysaux_occupants ;
OCCUPANT_NAME SCHEMA_NAME MOVE_PROCEDURE
---------------- --------------- ---------------------------------------------------------------
LOGMNR SYSTEM SYS.DBMS_LOGMNR_D.SET_TABLESPACE
LOGSTDBY SYSTEM SYS.DBMS_LOGSTDBY.SET_TABLESPACE
STREAMS SYS
XDB XDB XDB.DBMS_XDB.MOVEXDB_TABLESPACE
AO SYS DBMS_AW.MOVE_AWMETA
XSOQHIST SYS DBMS_XSOQ.OlapiMoveProc
...
Via cette requête :
SQL> SELECT dbms_utility.port_string FROM dual;
PORT_STRING
-----------------------------------------------
IBMPC/WIN_NT-8.1.0
Lors d'une migration vers une base 10g, comment savoir si les pré requis ont été vérifiés avant d'effectuer la migration ?
Via un nouvel outil d'upgrade ( Upgrade information Tool ) :
Prendre le fichier utlu101i.sql ( migration vers une 10gR1 ) présent dans le dossier $ORACLE_HOME\rdbms\admin\ et le faire tourner sur la base source.
Il est possible de faire une migration vers la 10g ( quelque que soit la release ) sans passer par d'autres versions si la base source est 806, 817, 927
Voici comment déterminer les sessions qui sont killed for ever :
- sous Unix :
SELECT spid
FROM v$process
WHERE NOT EXISTS ( SELECT 1
FROM v$session
WHERE paddr = addr);
- sous Windows :
SVRMGRL> SELECT spid, osuser, s.program
FROM v$process p, v$session s
WHERE p.addr=s.paddr;
Pour les tuer :
c:>orakill sid thread
Il suffit de modifier le parametre DB_RECOVERY_FILE_DEST.
Avec ce paramètre, il faut toujours spécifier le paramètre d'initialisation DB_RECOVERY_FILE_DEST_SIZE.
Par exemple :
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='/disk1' SCOPE=BOTH SID='*' ;
- Fusion des extents libre toutes les 5 mn
- Nettoyage des segments temporaires toutes les 2 h
- Mise à jours de SMON_SCN_TIME toutes les 5 mn
- Nettoyage des objects inexistants dans OBJ$, toutes les 12 h
- Nettoyage de IND$ toutes les heure
- Compactage (shrink) des segments undo toutes les 12 h
- Restauration des transactions uniquement au démarrage de la base
- Il annule les transactions non validées quand c'est posté par PMON
En réalité, SMon (System MONitor) ne s'endort pas réellement,
puisqu'il n'est sollicité que de temps à autres lorsque la base est en activité.
La doc (cf lien au bas de la QR) précise simplement que :
| SMON checks regularly to see whether it is needed |
|---|
Mais il peut être utile parfois de le solliciter manuellement, ce qu'on appelle un wakeup :
1. Exécutez d'abord la requête suivante :
SQL> SELECT pid FROM v$process
2 WHERE addr =
3 (
4 SELECT paddr FROM v$bgprocess
5 WHERE name = 'SMON'
6 );
PID
----------
8
2. Puis récupérez le PID pour exécuter la commande suivante (connecté en tant que SYSDBA) :
En général : 6 => 8i, 7 => 9i et 8 => 10g
SQL> ORADEBUG WAKEUP 8
Instruction traitée.
Grâce à la requête suivante :
SQL> SELECT se.osuser, se.username, se.sid,
2 su.extents, su.blocks * to_number(rtrim(p.value)) AS Space,
3 tablespace
4 FROM v$sort_usage su, v$parameter p, v$session se
5 WHERE p.name = 'db_block_size'
6 AND su.session_addr = se.saddr
7 ORDER BY se.username, se.sid;