Overblog
Suivre ce blog Administration + Créer mon blog
1 mars 2018 4 01 /03 /mars /2018 09:54

12c - Dataguard - GAP - Recover From Service

En Mars, l'ami-dba maintient le rythme.

http://www.lami-dba.com/2018/02/dataguard-resolve-gap-revover-from-service.html

Aimez, partagez, critiquez & inscrivez vous à la newsletter.

@+

LAO

Partager cet article
Repost0
Published by LAO - dans Dataguard Administration Oracle 12c
commenter cet article …
25 juin 2010 5 25 /06 /juin /2010 11:10

Administration - Export et compression à la volée

Bonjour,


ce jour j'ai décidé de vous parler d'un petit truc que je trouve sympa. Pouvoir effectuer un export tout en compressant à la volée. Ce qui lorsque l'on veut faire cela sur une base de plusieurs dizaines de GO peut être (en plus d'être sympa) économique (en espace disque). Pour effectuer mon test, j'ai utilisé la distribution linux que l'on peut trouver sur le site Oracle et une version 10g pour la base. J'ai également crée une base dont l'export fait un plus de 300 MO. Seul hic, mon fs déstiné à recevoir les export ne fait lui que 150 MO. La manipulation est très simple. On passe au niveau OS par des "pipes".

Pour cela.

mknod exp.dmp p

 

puis je crée une tache de fond consistant à compresser le fichier exp.dmp.

gzip <exp.dmp >exp.dmp.gz &

Il ne reste alors plus qu'à exporter....

 exp system/x79ukhf file=exp.dmp log=exp.log full=yes

 si je vérifie au niveau de mon FS.

ls -lh

prw-r--r-- 1 oracle oinstall    0 Jun 25 11:28 exp.dmp
-rw-r--r-- 1 oracle oinstall 114M Jun 25 11:28 exp.dmp.gz
-rw-r--r-- 1 oracle oinstall  91K Jun 25 11:28 exp.log

Je constate que mon export est bien zippé et mon exp.dm a toujours sa taille initiale de 0.

Avec un peu d'imagination, on se rend compte qu'il en sera aussi simple pour effectuer l'import avec une décompression à la volée sans utilisation réelle de l'espace disque disponique car volatie au travers du pipe.

@+

 

LAO.

 

 

 

Partager cet article
Repost0
Published by LAO - dans Administration
commenter cet article …
17 juin 2009 3 17 /06 /juin /2009 06:38

Administration - Opérations longues

Bonjour,

Lors de la création d'un index (ou de sa reconstruction) sur une table à forte volumétrie, il peut être interessant ne serait ce que pour savoir si on a le temps d'entamer une sieste de savoir on l'on se situe par rapport à l'opération en cours.
Il existe pour cela une vue système qui peut nous aider. A savoir : v$session_longops

Un petit desc sur la vue, vous donnera l'ensemble des colonnes qui pour la plupart parlent d'elle même.
Je vais en citer quelques unes

- SQL_ID pour identifier la requête longue en question
- START_TIME pour indentifier l'heure de début d'execution
- ELAPSED_TIME pour identifier le temps déjà écoulé.
- MESSAGE pour connaitre l'action en cours

et bien sur TIME_REMAINING pour avoir une idée de combien temps il reste pour l'opération en cours...
Il sera également possible bien sur d'idenitfier la session effectuant l'opération longue via les colonnes SID et SERIAL#
Une requête assez simple du type nous donnera donc des informations importantes

SELECT Message,Time_Remaining FROM V$session_longops
WHERE Time_Remaining>0;

exemple:



Le resultat suivant nous indique que l'opération en cours est un "Sort Output", que le traitement à parcouru 260822 blocs sur 462733 et qu'il reste environ 527 secondes avant la fin du traitement.

Attention : à une instruction SQL ne corresponds pas forcement une et une seule opération.... La création d'un index est constitué des plusieurs actions... Mais cela fera l'objet d'un autre post.

Dans l'exemple, j'ai parlé de création d'index, mais il peut bien sur s'agir d'autres opérations.....

LAO.
Partager cet article
Repost0
Published by LAO - dans Administration
commenter cet article …
30 mars 2009 1 30 /03 /mars /2009 18:38

Historique volumétrie tablespace

Bonjour,

Il est parfois utilie pour anticiper la croissance d'un tablespace de savoir comment il s'est comporter récemment. Nous avons dans un post précédent qu'il existait une vue sympathique permettant de connaitre l'espace libre à un instant t. Mais que faire si je veux connaitre l'évolution de la croissance.

J'en connais déjà qui vont mettre en place un petit job pour interroger la vue donnant l'espace à un instant et stocker cela dans une table afin d'en avoir l'évolution.

Je vais vous faire une petite confidence. Il existe déjà une vue qui donne l'évolution de la volumétrie:
Il s'agit de DBA_HIST_TBSPC_SPACE_USAGE

Remarque : Avant que quelqu'un ne me fasse la reflexion que cela ne marche pas en oracle 9 ou 6: Je le sais, et l'ensemble de mes articles partent du postulat que j'utilise une version 10 au minumum.

Donc pour avoir l'évolution par tablespace en fonction du temps, on peut executer la requête suivante.
SELECT  t.Name,Tablespace_Usedsize "Espace utilisé(nb blocks)",Rtime FROM  DBA_HIST_TBSPC_SPACE_USAGE h, v$TABLESPACE t
WHERE  h.Tablespace_id=t.TS#
ORDER BY t.Name,Rtime;


Remarque : La vue DBA_HIST_TBSPC_SPACE_USAGE conserve un historique qui correspond au paramétrage de AWR: Par défaut un snap toutes les heures avec une rétention de 10 jours. Bien evidemment ces paramètres sont modifiables....

Remarque : Pour avoir la taille en MO il suffit dans la requête de remplacer Tablespace_Usedsize par Tablespace_Usedsize*taille_de_block/1024

LAO.
Partager cet article
Repost0
Published by LAO - dans Administration
commenter cet article …
19 février 2009 4 19 /02 /février /2009 11:49

Connaitre la version Oracle qui tourne (32 ou 64 bit)

Bonjour,

Il arrive parfois que l'on se connecte sur une base et que l'on souhaiterait savoir si il s'agit d'une version 32bit ou 64bit.

Pour avoir la réponse vous pouvez executer la requête suivante :
SELECT  length(addr)*4  FROM  V$Process WHERE ROWNUM=1;

LENGTH (ADDR)*4
----------------------------
                        32


Par ailleurs, si vous êtes en environnement linux et que vous désirez savoir la version du noyau linux (32bit ou 64bit) tapez la commande suivante.

# getconf LONG_BIT


LAO.






Partager cet article
Repost0
Published by LAO - dans Administration
commenter cet article …
14 février 2009 6 14 /02 /février /2009 14:52

Connexion à une base distante - ORA-01031

Bonjour,

Il arrive parfois que l'on soit obligé de se connecter à un serveur oracle autrement qu'en local avec l'utilisateur SYS.
Cela peut par exemple arriver dans les cas suivants:
  • Besoin de stopper une base
  • Besoin de redémarrer une base
  • Opération de duplication.
  • ...
Si vous ne voulez pas avoir de mauvaise surprise le jour venu, il convient de s'assurer que vous pouvez bien vous connecter depuis un poste client sur votre base préférée en SYS.

Je viens de créer une base DB1 sur une machine XP (ORA10-SRV4).
Sur un poste client, j'ajoute l'entrée suivante dans le tnsnames.ora
DB1_SRV4 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = ORA10-SRV4)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = DB1)
    )
  )


Depuis mon poste client., il ne reste plus qu'a ouvrir une session sqlplus et se connecter en sys.
SQLPLUS /nolog
CONNECT SYS/oracle@DB1_SRV4

Et la ... patatra ORA-01031 : Insufficient privieges Impossible de se connecter à ma base en sys depuis un poste client.

Une solution serait donc d'autoriser les connexions distantes à SYS.

Pour cela,il faut s'assurent que le paramètre REMOTE_LOGIN_PASSOWORDFILE a la valeur EXCLUSIVE.
Il s'agit de la valeur par défaut. On peut supposer que si la valeur a été changé, c'est peut être justement pour éviter que l'on puisse se connecter en sys depuis un poste distant. Si néanmoins, on veut changer la valeur.

Remarque :
Le paramètre REMOTE_LOGIN_PASSWORDFILE peut prendre trois valeurs.
  • NONE
  • EXCLUSIVE (le fichier de mot de passe est propre à une instance)
  • SHARED (le fichier de mot des passe est partagé par plusieurs instances. Ex: RAC)

ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE SCOPE=SPFILE;

Si je précise SCOPE=SPFILE, c'est tout simplement que la modification de ce paramètre n'est pas modifiable de façon dynamique et nécessite un redémarrage de l'instance ORACLE. Si vous utilisez un PFILE plutôt qu'un SPFILE alors il faut ajouter la ligne suivtante dans votre fichie PFILE.
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE


Ceci étant fait, cela ne suffit pas. Il va maintenant falloir créer ce qu'on appelle un fichier de mot passe via l'utilitaire ORAPWD

La syntaxe est relativement simple
orapwd file=password_file_name password=sys_password entries=nb_entries force=Y


 Paramètre  Explications
 FILE Permet d'indiquer le nom du fichier
 PASSWORD Indique le mot de passe pour l'utilisateur SYS
 ENTRIES Indique le nombre de connexion simultanées avec l'utilsateur SYS
 FORCE Indique si il faut écraser le fichier existant.


Remarque : En fonction de l'environnement, le nom ainsi que l'emplacment du fichier peut être différent.

Ex1:Environnement Unix
Nom :orapwSID (ex:orapwdDB1)
Emplacement :ORACLE_HOME/dbs

Ex2: Envrironnement windows
Nom:PWDsid.ora
Emplacement :ORACLE_HOME\database

Dans mon cas précis, cela donnerait:
orapwd FILE=%ORACLE_HOME%\database\pwdDB1.ora PASSWORD=oracle ENTRIES=5

Je peux donc maintenant depuis un poste client lancer à nouveau une fentre sqlplus:
SQLPLUS /nolog
CONNECT sys/oracle@DB1_SRV4 as sysdba

Et maintenant que je suis connecté en sys, je vais enfin pouvoir arreter ma base
SHUTDOWN IMMEDIATE;

Puis la redémarrer.
STARTUP;

Arghh :ORA-12514 TNS : Le processus d'écoute ne connait pas actuellement le service demandé dans le descripteur de connexion.

Et vous pouvez toujours essayer de vous reconnecter, l'erreur persiste. Je viens d'arreter une base et je ne peux plus la remonté. En supposant que je n'ai plus accès au serveur, je suis dans la mouise...


Pour pouvoir me connecter à une instance inactive (pour la rédémarrer) il faut que l'instance soit connu du LISTENER.

ex LISTENER.ora (%ORACLE_HOME%\NETWORK\admin
# listener.ora Network Configuration File: E:\oracle\product\10.2.0\db_1\network\admin\listener.ora
# Generated by Oracle configuration tools.

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = E:\oracle\product\10.2.0\db_1)
      (PROGRAM = extproc)
    )
    (SID_DESC =
      (SID_NAME = DB1)
      (ORACLE_HOME = E:\oracle\product\10.2.0\db_1)
    )
  )

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = ORA10-SRV4)(PORT = 1521))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
    )
  )


Une fois que les lignes concernant DB1 ont été ajoutées dans le listener.ora, il faut recharger celui-ci afin que les modifications soient prise en compte.

Pour cela:
LSNRCTL RELOAD

et non pas
LSNRCTL STOP
LSNRCTL START

qui entraine pendant un cours instant une interuption de l'accès aux eventuelles autres bases qui seraient sur le serveur.
A partir de maintenant, je peux  me connecter en SYS a un base active pour l'arreter aussi qu'à une base inactive pour la redémarrer.


Conclusion :

Afin d'éviter le désagrément de ne pas pouvoir se connecter à une base via un client (tout simplement parceque l'on n'a pas accès au serveur), ou pire pouvoir s'y connecter, mais ne pas redémarrer une instance, il convient lors de la création d'une base ORACLE d'indiquer au DBA qui créera la base tous les besoins futurs.Y en a même qui osent dire "Gouverner, c'est prévoir". Je dois avouer qu'a ce jour, je n'ai pas du rencontrer de bon gouverneur....

LAO.










Partager cet article
Repost0
Published by LAO - dans Administration
commenter cet article …
31 janvier 2009 6 31 /01 /janvier /2009 09:18

Supprimer une base de données.

Bonjour,

On parle souvent de création de base de données, mais ils arrive aussi de devoir supprimer des bases de données.
On peut alors utiliser (dbca, Database Configuration Assistant), qui permet la suppression d'une base.
Si on aime (ou que l'on n'a pas forcement le choix) les opérations manuelles, on peut faire le nettoyage à la main.
Depuis Oracle 10 et uniquement depuis cette version, il existe une commande qui permet la suppression d'une base ==> "DROP DATABASE".

Remarque : Pour les versions précedents d'Oracle, reportez vous au commentaire de  Wahren.

Opération de suppression d'une base: (en sys)
Je vais supprimer la base que j'ai cloné dans mon article précédent (DB2)
SET ORACLE_SID=DB2
SQLPLUS /nolog
CONNECT / as sysdba

SHUTDOWN ABORT;
STARTUP MOUNT EXCLUSIVE RESTRICT pfile='e:\oracle\product\admin\db2\pfile\init.ora';
DROP DATABASE;
EXIT;

Le "DROP DATABASE" a eu pour effet de supprimer les fichiers de la base de données (datafiles, redo, controlfile,...) mais les répertoires sont encore présents, ainsi que toute la partie log(udump, cdump,budum,pfile). Il faut donc les supprimer à la main.

Par ailleurs, sous windows, il faut penser à supprimer l'instance représenté par un windows service

oradim -delete -sid DB2

Notre base est maintenant supprimée.

Si ma base était une base de production (en fin de vie) à supprimer, j'aurai également pu passer par RMAN.
L'avantage de passer par RMAN aurait été de pouvoir supprimer la base ainsi que les backup associés et de désenregistrer la bae du Catalog. Attention, pour être désenregistrer du catalog, il faut evidemment être connecté au catalog pour effectuer l'opération.

La commande est la même.

DROP DATABASE; (uniquement suppression de la base)
DROP DATABASE INCLUDING BACKUPS; (pour supprimer également les backups)

On peut également ajouter l'option NOPROMPT pour ne pas avoir de demande de confirmation de la part de RMAN.

LAO.

Partager cet article
Repost0
Published by LAO - dans Administration
commenter cet article …
29 janvier 2009 4 29 /01 /janvier /2009 15:56

Créer une base manuellement

Bonjour,

Aujourd'hui, je vais aborder le thème de la création d'une base de données.
Et pour être plus précis, je vais surtout créer une base de façon manuelle. C'est à dire sans utiliser l'assistant de base de données (dbca=> DataBase Configuration Assistant).

Pour cela, je vais utiliser une machine virtuelle (Windows XP) sur laquelle j'ai déjà installé un noyau Oracle (10.2.0.1) patché en 10.2.0.3.

Mon noyau Oracle est installé dans le répertoire E:\oracle\product\10.2.0\
L'instance et la base se nommeront DB1. On peut nommer la base de façon différente de l'instance.

Avant toute chose il faut créer les répertoires nécessaire à la création de la base:
MKDIR E:\oracle\product\10.2.0\admin
MKDIR E:\oracle\product\10.2.0\oradata

MKDIR E:\oracle\product\10.2.0\admin\DB1
MKDIR E:\oracle\product\10.2.0\oradata\DB1

MKDIR E:\oracle\product\10.2.0\admin\DB1\bdump
MKDIR E:\oracle\product\10.2.0\admin\DB1\cdump
MKDIR E:\oracle\product\10.2.0\admin\DB1\pfile
MKDIR E:\oracle\product\10.2.0\admin\DB1\udump
Une fois l'arborescence crée nous allons avoir besoin d'un fichier d'initialisation (pfile) courramment nommé init.ora. Ce fichier sera placé dans le répertoire E:\oracle\product\10.2.0\admin\DB1\pfile

exemple de fichier init.ora
Attention, si votre emplacement diffère, il faut prendre soin de modifier les chemins. De même ceci est un exemple qui doit être adapté en fonction du résultat voulu. L'objet n'étant pas de passer en revu tous les paramètres d'une instance oracle, je ne commenterai pas le fichier ci-dessous. 


##############################################################################
# Copyright (c) 1991, 2001, 2002 by Oracle Corporation
##############################################################################
 
###########################################
# Cache and I/O
###########################################
db_block_size=8192
db_file_multiblock_read_count=16
 
###########################################
# File Configuration
###########################################
control_files=("E:\oracle\product\10.2.0\ORADATA\DB1\control01.ctl", "E:\oracle\product\10.2.0\ORADATA\DB1\control02.ctl", "E:\oracle\product\10.2.0\ORADATA\DB1\control03.ctl")
 
###########################################
# Cursors and Library Cache
###########################################
open_cursors=300
 
###########################################
# Diagnostics and Statistics
###########################################
background_dump_dest=E:\oracle\product\10.2.0\admin\DB1\bdump
core_dump_dest=E:\oracle\product\10.2.0\admin\DB1\cdump
user_dump_dest=E:\oracle\product\10.2.0\admin\DB1\udump
 
###########################################
# Miscellaneous
###########################################
compatible=10.2.0.1.0
 
###########################################
# Job Queues
###########################################
job_queue_processes=10
 
###########################################
# Database Identification
###########################################
db_domain=""
db_name=DB1
db_unique_name=DB1
 
###########################################
# SGA Memory
###########################################
sga_target=256M
 
###########################################
# Processes and Sessions
###########################################
processes=150
 
###########################################
# System Managed Undo and Rollback Segments
###########################################
undo_management=AUTO
undo_tablespace=UNDOTBS1
 
###########################################
# Shared Server
###########################################
dispatchers="(PROTOCOL=TCP) (SERVICE=ORADBXDB)"
 
###########################################
# Security and Auditing
###########################################
audit_file_dest=E:\oracle\product\10.2.0\admin\DB1\adump
remote_login_passwordfile=EXCLUSIVE
 
###########################################
# Sort, Hash Joins, Bitmap Indexes
###########################################
pga_aggregate_target=20M

Puisque nous sommes sous windows, je vais également devoir créer mon instance Oracle qui sera représenté par un Windows Service. 

Dans une console DOS, tapez la commande suivante.

oradim -new -sid DB1

Une fois l'instance crée, nous allons nous connecter à cette instance via l'utilitaire SQL+

SET ORACLE_SID=DB1
SQLPLUS /nolog
CONNECT / as sysdba

STARTUP NOMOUNT pfile='E:\oracle\product\10.2.0\admin\db1\pfile\init.ora'

Une fois la base en mode nomount, il ne reste plus qu'a lancer le script de création de base.

Exemple de script de création de base:

On constate, que l'instruction de la commande CREATE DATABASE, va entre autre permetre la création du fichier Control File. Modifier les chemins et options en fonction de votre configuration et résultat voulu (Character Set, Archivelog ou pas,nombre et taille des redo,...)


Create DATABASE DB1
USER SYS IDENTIFIED BY oracle
USER SYSTEM IDENTIFIED BY oracle
MAXDATAFILES 200
MAXINSTANCES 1
CHARACTER SET AL32UTF8
NATIONAL CHARACTER SET UTF8
LOGFILE 
GROUP 1 ('E:\oracle\product\10.2.0\oradata\DB1\redo01.rdo') SIZE 50M,
GROUP 2 ('E:\oracle\product\10.2.0\oradata\DB1\redo02.rdo') SIZE 50M,
GROUP 3 ('E:\oracle\product\10.2.0\oradata\DB1\redo03.rdo') SIZE 50M
MAXLOGFILES 20
MAXLOGMEMBERS 5
NOARCHIVELOG
EXTENT MANAGEMENT LOCAL
DATAFILE 'E:\oracle\product\10.2.0\oradata\DB1\system.dbf' SIZE 500M
SYSAUX DATAFILE 'E:\oracle\product\10.2.0\oradata\DB1\sysaux.dbf' SIZE 500M
DEFAULT TEMPORARY TABLESPACE TEMP
TEMPFILE 'E:\oracle\product\10.2.0\oradata\DB1\temp.dbf' SIZE 250M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M
UNDO TABLESPACE UNDOTBS1
DATAFILE 'E:\oracle\product\10.2.0\oradata\DB1\UNDOTBS1.dbf' SIZE 250M;

Maintenant que la base de donnée est crée, il ne reste plus (cette fois c'est la bonne) qu'à executer deux scripts oracles.

Toujours en SYS.

@?\rdbms\admin\catalog.sql
@?\rdbms\admin\catproc.sql

Et cette fois c'est terminé. Votre base de donnée est crée sans options particulières.
Les avantages sont à mon avis:
  • La possibilité de créer des bases de facon uniforme (uniquement les chemins, et nom de base à modifier)
  • On sait ce qui  a été installé, alors qu'avec l'assistant, on peut avoir tendance à choisir des options dont on ne sais pas vraiment si l'on en a l'utilité.
  • Pratique pour créer des bases à distance (essayer de lancer un dbca en telnet !)
  • Le jour ou DBCA est en rade, on n'est pas totalement à rue.

Laurent

Partager cet article
Repost0
Published by LAO - dans Administration
commenter cet article …
27 janvier 2009 2 27 /01 /janvier /2009 15:50

Administratration - Identifier les indexes inutilisés

Bonjour,

Lorsqu'une application a un peu de vécu, il arrive que l'on se demande si tel index est utilisé ou pas.
En effet la présence d'un index a un impact sur :
  • La taille de la base
  • Les performance lors d'opération d'INSER, UPDATE , ou DELETE puisqu'il faut au passage mettre à jour les indexes.
Donc si un index n'est pas utilisé, il n'a aucune raison d'exister. Sauf  si on aime a penser que peut etre un jour il sera utilisé.


Admettons que vous aillez un doute sur l'utilisation d'un index que l'on appellera "mon_index". Il va suffir de le monitorer et de voir si il est utilisé.

ALTER INDEX mon_index MONITORING USAGE;

Il suffit ensuite d'interroger la vue v$object_usage pour savoir si l'index a été utilisé.
Dans cette vue nous avons les colonnes suivante:
  • Index_Name
  • Table_Name
  • Monitoring
  • USED
  • Start_Monitoring
  • End_Monitoring
Si l'index a été utilisé, alors la colonne USED prends la valeur YES.

Une fois que l'on pense avoir sa réponse, ou que l'on estime que l'on est passé dans toutes les requetes pouvant potentiellement utiliser cet index, on peut alors stopper le monitoring.

ALTER INDEX mon_index NOMONITORING;

Remarque: Une fois qu'un index a été monitoré, la trace est conservée dans la vue v$object_usage (d'ou l'interet de la colonne End_Monitoring).

Attention : La méthode décrite ici, indique seulement qu'un index n'a pas été utilisé. Cela ne permet pas de conclure que l'index est inutile. Cela peut permettre par exemple de mettre en evidence que les stats ne sont pas à jour, ou que les paramètres de base sont mal initialisés.....

Re Attention : L'utilisation de ce type de monitoring doit également est effectué avec quelqu'un qui maitrise le fonctionnel. En effet, si vous décidez de supprimer un index car non utilisé sur plusieurs mois et que manque de pot,il était utile sur un traitement annuel, vous pouvez plombez les performances. "Sans controle, la puissance n'est rien..."

LAO.
Partager cet article
Repost0
Published by LAO - dans Administration
commenter cet article …
23 janvier 2009 5 23 /01 /janvier /2009 10:55

Déplacer ou renommer un datafile base ouverte

Bonjour,

  je vais reprendre l'année 2009 en douceur avec un petit post qui peut quand même être utile.

Objectif : Déplacer un ou plusieurs datafiles ouverte.

Les raisons qui peuvent amener à deplacer un datafile peuvent être multiples
  • Erreur lors de la création
  • Manque cruelle de place
  • Déplacement de fichier en fonction de leur activité (lecture / ecriture).


Les manipulations sont relativement simples..

A faire en étant connecter en SYSTEM.


-1 Identifier le ou les fichier à déplacer ainsi que leur emplacement.

SELECT File_Name FROM Dba_Data_files;

-2 Passer le tablespace concerné par les datafiles en READONLY


ALTER TABLESPACE Mon_tbs READ ONLY;

-3 Passer le tablespace en mode OFFLINE.


ALTER TABLESPACE Mon_tbs OFFLINE;

ATTENTION : A partir de maintenant les données étant dans ce tablespace ne sont plus accessibles.


-4 Faire la copie du ou des fichiers concernés vers un nouvel emplacement.

 

-5 Indiquer à ORACLE que l'emplacement du / des fichiers a changé.

 

ALTER DATABASE RENAME  FILE 'chemin_complet_du fichier/nomfichier' TO 'Nouveau_chement/nomfichier';

-6 Remettre le tablespace accessible et en écriture.

 

ALTER TABLESPACE mon_tbs ONLINE;

ALTER TABLESPACE mon_tbs READ WRITE;

Une fois qu'il a été constaté que tout fonctionne correctement on peut supprimer les fichiers d'origine. (attention à ne pas se tromper de fichier)


LAO.

Partager cet article
Repost0
Published by LAO - dans Administration
commenter cet article …