FAQ OracleConsultez toutes les FAQ

Nombre d'auteurs : 15, nombre de questions : 137, dernière mise à jour : 26 octobre 2006  Ajouter une question

 

Cette F.A.Q. a été réalisée à partir des questions fréquemment posées sur le forum Oracle de www.developpez.com et de l'expérience personnelle des auteurs. Elle pourra traiter de tout type de questions portant sur les technologies Oracle.

Nous espérons que cette F.A.Q. saura répondre à un maximum de vos questions. Nous vous souhaitons une bonne lecture.

L'équipe Oracle de Developpez.


SommaireAdministrationSystème (14)
précédent sommaire suivant
 

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

Code sql :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
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.

Mis à jour le 30 novembre 2004 SheikYerbouti

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 : clic 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 :

Code linux :
ps -ef | egrep pmon_ | grep -v grep

Mis à jour le 30 novembre 2004 helyos

Voici un script permettant d'afficher la taille allouée, utilisée et libre de chaque pool :

Code sql :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
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

Code sql :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
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)

Mis à jour le 30 novembre 2004 SheikYerbouti

Via le script suivant :

Code sql :
1
2
3
4
5
6
7
8
9
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;

Mis à jour le 18 septembre 2006 Jaouad

Via la requête suivante, à partir de la 9i :

Code sql :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
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

Mis à jour le 18 septembre 2006 laurentschneider

À partir de la version 10.1.0.5 cpu2006jan, via le requête suivante :

Code sql :
1
2
3
4
5
6
7
8
9
10
11
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

Mis à jour le 18 septembre 2006 laurentschneider

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

Code sql :
1
2
3
4
5
6
7
8
9
10
11
12
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 
...

Mis à jour le 18 septembre 2006 Jaouad

Via cette requête :

Code sql :
1
2
3
4
5
SQL> SELECT dbms_utility.port_string FROM dual; 
  
PORT_STRING 
----------------------------------------------- 
IBMPC/WIN_NT-8.1.0

Mis à jour le 18 septembre 2006 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

Mis à jour le 18 septembre 2006 Jaouad

Voici comment déterminer les sessions qui sont killed for ever :
- sous Unix :

Code sql :
1
2
3
4
5
SELECT spid                   
  FROM v$process                   
 WHERE NOT EXISTS ( SELECT 1  
                      FROM v$session                                      
                     WHERE paddr = addr);
- sous Windows :

Code sql :
1
2
3
SVRMGRL> SELECT spid, osuser, s.program                   
          FROM v$process p, v$session s                   
         WHERE p.addr=s.paddr;
Pour les tuer :

Code sql :
c:>orakill sid thread

Mis à jour le 18 septembre 2006 Jaouad

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 :

Code sql :
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='/disk1' SCOPE=BOTH SID='*' ;

Mis à jour le 15 octobre 2006 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

Mis à jour le 15 octobre 2006 bouyao

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 :

Code sql :
1
2
3
4
5
6
7
8
9
10
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

Code sql :
1
2
SQL> ORADEBUG WAKEUP 8 
Instruction traitée.

Mis à jour le 15 octobre 2006 LeoAnderson

System Monitor Process (SMON)

Grâce à la requête suivante :

Code sql :
1
2
3
4
5
6
7
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;

Mis à jour le 15 octobre 2006 aline

Proposer une nouvelle réponse sur la FAQ

Ce n'est pas l'endroit pour poser des questions, allez plutôt sur le forum de la rubrique pour ça


Réponse à la question

Liens sous la question
précédent sommaire suivant
 

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 © 2014 Developpez Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et 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.

 
 
 
 
Partenaires

PlanetHoster
Ikoula