|
auteur : SheikYerbouti |
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
taille des unités de traitement |
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.
|
|
auteur : Helyos |
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
|
|
auteur : SheikYerbouti |
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)
|
|
|
auteur : Jaouad |
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;
|
|
|
auteur : Laurent Schneider |
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
|
|
|
auteur : Laurent Schneider |
À 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
|
|
|
auteur : Jaouad |
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
...
|
|
|
auteur : Jaouad |
Via cette requête :
SQL > SELECT dbms_utility.port_string FROM dual;
PORT_STRING
IBMPC/ WIN_NT- 8 .1 .0
|
|
|
auteur : Jaouad |
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
|
|
auteur : Jaouad |
Voici comment déterminer les sessions qui sont killed for ever :
SELECT spid
FROM v$process
WHERE NOT EXISTS ( SELECT 1
FROM v$session
WHERE paddr = addr);
|
SVRMGRL> SELECT spid, osuser, s.program
FROM v$process p, v$session s
WHERE p.addr= s.paddr;
|
Pour les tuer :
|
|
auteur : bouyao |
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= ' * ' ;
|
|
|
auteur : bouyao |
- 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
|
|
auteur : LeoAnderson |
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.
|
|
lien : System Monitor Process (SMON)
|
|
auteur : Aline |
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;
|
|
Consultez les autres F.A.Q's
Les sources présentées sur cette page sont libres de droits
et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation
constitue une œuvre intellectuelle protégée par les droits d'auteur.
Copyright © 2006 Developpez Developpez LLC.
Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne
peut être faite de ce site ni de l'ensemble de son contenu : textes, documents
et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez
selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.