| | auteur : Laurent Schneider |
La requête suivante nous permet de lister les objets invalides, avec les informations suivantes :
- Schéma
- Type d'objet
- Date de création
- Date de dernière modification/compilation
SELECT OWNER,
OBJECT_TYPE,
OBJECT_NAME,
CREATED,
LAST_DDL_TIME
FROM DBA_OBJECTS
WHERE STATUS='INVALID'
ORDER BY OWNER, OBJECT_NAME;
OWNER OBJECT_TYPE OBJECT_NAME CREATED LAST_DDL_T
PUBLIC SYNONYM DBA_HIST_FILESTATXS 2006-04-18 2006-06-13
PUBLIC SYNONYM DBA_HIST_SQLBIND 2006-04-18 2006-06-13
PUBLIC SYNONYM DBA_HIST_SQLSTAT 2006-04-18 2006-06-13
|
|
| | auteur : Laurent Schneider |
À partir de la version 10g, la requête suivante permet de lister les objets dans la poubelle, avec les propriétés suivantes :
- Nom du tablespace
- Type d'objet
- Propriétaire
- Nom original
- Nom BIN$
- SCN
- Date de création
- Date d'effacement des objets dans la poubelle (Recycle bin)
SELECT
TS_NAME,
TYPE,
OWNER,
ORIGINAL_NAME,
OBJECT_NAME,
DROPSCN,
CREATETIME,
DROPTIME
FROM dba_recyclebin
ORDER BY owner, type, original_name, dropSCN;
TS_NAME TYPE OWNER ORIG OBJECT_NAME DROPSCN CREATETIME DROPTIME
USERS TABLE SCOTT T BIN$F22M89kvcArgQwow5W1wCg==$0 3537036 2006-06-30 2006-06-30
|
|
| | auteur : Laurent Schneider |
La requête suivante nous permet de lister les jobs, avec les caractéristiques suivantes :
- Schéma
- Numéro du job
- Date de prochaine éxecution
- Code des jobs
SELECT SCHEMA_USER,
JOB,
NEXT_DATE,
WHAT
FROM DBA_JOBS;
SCHEMA JOB NEXT_DATE WHAT
SYS 1 2006-07-01 scott.p;
|
|
| | auteur : Laurent Schneider |
La requête suivante permet de lister les sessions, avec les propriétés suivantes :
- Utilisateur DB
- Utilisateur SE
- SID
- SERIAL#
- Processus OS
- Type de serveur
- Status
- Machine cliente
- Programme
- Heure du login
- Nom du dispatcher
- Nom du shared server
SELECT s.USERNAME,
s.OSUSER,
s.SID,
s.SERIAL#,
p.SPID,
s.SERVER,
s.STATUS,
s.MACHINE,
s.PROGRAM,
TO_CHAR(s.LOGON_TIME, 'hh24:mi:ss') LOGON_TIME,
d.name DISP,
ss.name SERV
FROM V$PROCESS p,
V$SESSION s,
V$DISPATCHER d,
V$CIRCUIT c,
V$SHARED_SERVER ss
WHERE p.ADDR = s.PADDR
AND s.SADDR=c.SADDR (+)
AND c.DISPATCHER=d.PADDR (+)
AND c.SERVER=ss.PADDR (+)
AND s.USERNAME IS NOT NULL
ORDER BY s.USERNAME, p.SPID;
USERNAME OSUSER SID SERIAL# SPID SERVER STATUS MACHINE PROGRAM LOGON DISP SERV
DBSNMP oracle 129 31 2465846 SHARED ACTIVE pclsc01 emagent 06:17 D000 S003
DBSNMP oracle 122 6 2728088 NONE INACTIVE pclsc01 emagent 06:17 D000
SYS oracle 113 2669 2920628 DEDICATED ACTIVE pclsc01 sqlplus 10:38
|
Concernant les "longues opérations", la requête suivante vous permettra d'obtenir :
- Numéros de sessions
- Opération
- Travail effectué
- Travail total
- Temps restant
SELECT SID,
SERIAL#,
OPNAME,
SOFAR,
TOTALWORK,
TIME_REMAINING
FROM V$SESSION_LONGOPS
WHERE TIME_REMAINING != 0;
SID SERIAL# OPNAME SOFAR TOTAL TIME_REM
120 4001 RMAN: full datafile backup 33692 66496 76
|
|
| | auteurs : LeoAnderson, Jaouad |
Depuis la version 8, le BUFFER CACHE est divisé en plusieurs segments : DEFAULT, KEEP et RECYCLE.
Contrairement à ce que leurs noms peuvent laisser penser,
ils sont gérés tous les 3 exactement de la même façon, par les même règles LRU (Last Recently Used).
En général, on utilise le buffer KEEP pour y stocker les blocks des tables que l'on interroge souvent;
et le buffer RECYCLE pour des données plus volatiles.
Par exemple, si on a une table de REFERENCE, une table de COMMANDES et une table IMAGE_PRODUIT, on aura intérêt à répartir les tables de la façon suivante :
- COMMANDES sur le buffer pool DEFAULT
- REFERENCE dans le buffer pool KEEP
- IMAGE_PRODUIT dans le buffer pool RECYCLE
En effet, si l'on interroge l'image (volume important), cela va nécessiter de sortir du pool de nombreux blocs de REFERENCE
qu'il faudra recharger ultérieurement alors que les blocs de l'image auront très peu de chance de resservir...
Les noms des buffers pools ne sont qu'une astuce mnémotechnique, car ils pourraient très bien s'appeller A, B et C, cela ne changerait rien !
Remarque : depuis la 9i, il est possible de définir des buffer pools de taille de block différente ( db_nk_cache_size) mais les buffer KEEP et RECYCLE auront forcément comme taille de bloc la taille DEFAULT.
Donc, on a 3 pools de taille par défault et jusqu'à 4 buffers de taille différente, ce qui fait 7 zones buffers indépendantes au maximum !
(mais je vous déconseille vivement d'implémenter un tel système, ça deviendra impossible à administrer/tuner !)
La requête est la suivante :
col object_type format a10
col object_name format a20
SELECT dba_objects.owner,object_name,object_type,object_type
FROM dba_objects, dba_indexes,dba_tables
WHERE dba_objects.object_name = dba_indexes.index_name
AND dba_objects.object_name = dba_tables.table_name
AND dba_tables.buffer_pool = 'KEEP'
AND dba_indexes.buffer_pool = 'KEEP' ;
|
Comment "Keeper" une table en mémoire :
ALTER TABLE TABLE_NAME STORAGE (BUFFER_POOL KEEP) ;
|
Attention : avec les multiples buffers pools, il n'est plus possible de monitorer les ratios par la vue
habituellement utilisée (v$SysStat) mais Oracle a implémenté la vue v$Buffer_Pool_Statistics :
SQL> SELECT Name, Block_size, Round(100*(CONSISTENT_GETS+DB_BLOCK_GETS-PHYSICAL_READS)/(CONSISTENT_GETS+DB_BLOCK_GETS) ,2)
2 AS HitRatio
3 FROM v$buffer_pool_statistics;
NAME BLOCK_SIZE HITRATIO
DEFAULT 8192 97.77
SQL> ALTER system SET db_keep_cache_size=50M scope=SPFILE;
SQL> CREATE TABLE toto (col1 varchar2(30) ) storage (buffer_pool keep);
TABLE created.
SQL> SELECT Name, Block_size, Round(100*(CONSISTENT_GETS+DB_BLOCK_GETS-PHYSICAL_READS)/(CONSISTENT_GETS+DB_BLOCK_GETS) ,2)
2 AS HitRatio
3 FROM v$buffer_pool_statistics;
NAME BLOCK_SIZE HITRATIO
KEEP 8192 100
DEFAULT 8192 89.57
|
|
Consultez les autres F.A.Q's
 
|
|
