miércoles, 25 de noviembre de 2009
Oracle Sqlplus Unix Shell PLANOS
Cómo pasar valores desde sqlplus hacia Unix Shell
Ver Instancia Unicamente desde Unix
ps -fea | grep pmon |grep -v grep | awk {'print $9'} | cut -c 10-100
Hay ocasiones que dentro de un Shell script queremos consultar la base de datos y con dicho resultado continuar la lógica de nuestro Shell. Como logramos transferir ese resultado?
Tenemos dos enfoques para capturar valores luego de terminada la ejecución de Sql*plus: por archivos y por variables.
La primera de ellas es básicamente escribir la salida de la consulta en un archivo y luego levantarlo desde Shell. Este caso es ideal cuando nuestra consulta retorna varios registros, ya que el archivo servirá de entrada a algún comando Unix para procesarlo línea a línea. No veremos un ejemplo ya que es muy sencillo, basta usar el comando SPOOL de Sqlplus para obtener la salida en un archivo de texto. Si bien no es del todo prolijo, funciona.
Unix lo hace fácil: ejecutamos la consulta en una sesión sqlplus, y la salida es capturada en la variable 'resultado'. Para simplificar este ejemplo no he considerado si hubo algún error en la consulta, pero puede agregarse lógica que trate mensajes de error dentro de la variable asignada.
#!/bin/ksh
resultado=`sqlplus -s 'scott/tiger' << EOF
set serveroutput on
set feedback offset head off}
select * from dual;exit;
EOF`
echo "El resultado es: $resultado"
Varios resultados en una línea
Qué hacer si necesitamos retornar más de un valor? Continuamos retornando una única línea, pero separamos los valores dentro del sql con algún caracter que no ocurra dentro de cada resultado, por ejemplo punto y coma. En el ejemplo obtenemos el usuario conectado, la fecha actual y el valor de la columna de Dual, todo al mismo tiempo.
#!/bin/kshresultado=`sqlplus -s 'scott/tiger' << EOF
set serveroutput onset feedback off
set head offselect user||';'||sysdate||';'||dummy from dual;exit;EOF`
echo "Los valores son: $resultado"El valor retornado es: SCOTT;05-FEB-09;X
Con el comando cut separamos los valores fácilmente:
echo $resultado | cut -d';' -f1
SCOTT
echo $resultado | cut -d';' -f2
05-FEB-09
echo $resultado | cut -d';' -f3
X
Resultados multilínea
Si queremos obtener varias líneas en lugar de una sola, también podemos hacerlo de esta forma. Como en el caso anterior, si tenemos múltiples valores por línea es aconsejable usar separadores, ya que los espacios no son buenos a la hora de identificar strings que contengan espacios. Además, evitamos los incómodos espacios entre líneas al optimizar el tamaño de cada cadena y no llegar al fin de cada línea.
#!/bin/ksh
resultado=`sqlplus -s 'scott/tiger' << EOF
set serveroutput on
set feedback off
set head off
set linesize 131
set pagesize 9999
select empno||';'||ename||';'||job||';'||mgr||';'||deptno from emp;
exit;
EOF`
echo "El resultado es: $resultado"
La salida en este caso es:
7369;SMITH;CLERK;7902;20
7499;ALLEN;SALESMAN;7698;30
7521;WARD;SALESMAN;7698;30
7566;JONES;MANAGER;7839;20
7654;MARTIN;SALESMAN;7698;30
7698;BLAKE;MANAGER;7839;30
7782;CLARK;MANAGER;7839;10
7788;SCOTT;ANALYST;7566;20
7839;KING;PRESIDENT;;10
7844;TURNER;SALESMAN;7698;30
7876;ADAMS;CLERK;7788;20
7900;JAMES;CLERK;7698;30
7902;FORD;ANALYST;7566;20
Ahora, podemos usar cualquier comando para tratar las líneas. Uno de mis favoritos es awk, ya que nos provee de muchas funciones para tratamiento de cada tipo.
Para que awk consuma cada línea de la variable como si fuese un archivo, debemos incluir comillas dobles, de otro modo lo considerará como una única gran línea.
En el siguiente ejemplo, vemos como awk toma línea a línea e imprime un texto anexo.
echo "$resultado" | awk -F";" 'BEGIN {$cnt=1}
{print "Linea "$cnt, $0; $cnt=$cnt+1;}'
La salida generada por awk es:
Linea 1 7369;SMITH;CLERK;7902;20
Linea 2 7499;ALLEN;SALESMAN;7698;30
Linea 3 7521;WARD;SALESMAN;7698;30
Linea 4 7566;JONES;MANAGER;7839;20
Linea 5 7654;MARTIN;SALESMAN;7698;30
Linea 6 7698;BLAKE;MANAGER;7839;30
Linea 7 7782;CLARK;MANAGER;7839;10
Linea 8 7788;SCOTT;ANALYST;7566;20
Linea 9 7839;KING;PRESIDENT;;10
Linea 10 7844;TURNER;SALESMAN;7698;30
Linea 11 7876;ADAMS;CLERK;7788;20
Linea 12 7900;JAMES;CLERK;7698;30
Linea 13 7902;FORD;ANALYST;7566;20
Linea 14 7934;MILLER;CLERK;7782;10
lunes, 9 de noviembre de 2009
Oracle 11g Database Replay
Database Replay in Oracle Database 11g Release 1
The Database Replay functionality of Oracle 11g allows you to capture workloads on a production system and replay them exactly as they happened on a test system. This provides an accurate method to test the impact of a variety of system changes including:
Database upgrades.
Operating system upgrades or migrations.
Configuration changes, such as changes to initialization parameters or conversion from a single node to a RAC environment.
Hardware changes or migrations.
The capture and replay processes can be configured and initiated using PL/SQL APIs, or Enterprise Manager, both of which are demonstrated in this article. To keep things simple, the examples presented here are performed against two servers (prod-11g and test-11g), both of which run an identical database with a SID of DB11G.
Capture using the DBMS_WORKLOAD_CAPTURE Package
Replay using the DBMS_WORKLOAD_REPLAY Package
Capture using Enterprise Manager
Replay using Enterprise Manager
Capture using the DBMS_WORKLOAD_CAPTURE Package
The DBMS_WORKLOAD_CAPTURE package provides a set of procedures and functions to control the capture process. Before we can initiate the capture process we need an empty directory on the "prod-11g" database server to hold the capture logs.
mkdir /u01/app/oracle/db_replay_captureNext, we create a directory object pointing to the new directory.
CONN sys/password@prod AS SYSDBA
CREATE OR REPLACE DIRECTORY db_replay_capture_dir AS '/u01/app/oracle/db_replay_capture/';
-- Make sure existing processes are complete.
SHUTDOWN IMMEDIATE
STARTUPNotice the inclusion of a shutdown and startup of the database. This is not necessary, but Oracle suggest it as a good way to make sure any outstanding processes are complete before starting the capture process.
The combination of the ADD_FILTER procedure and the DEFAULT_ACTION parameter of the START_CAPTURE procedure allow the workload to be refined by including or excluding specific work based on the following attributes:
INSTANCE_NUMBER
USER
MODULE
ACTION
PROGRAM
SERVICE
For simplicity let's assume we want to capture everything, so we can ignore this and jump straight to the START_CAPTURE procedure. This procedure allows us to name a capture run, specify the directory the capture files should be placed in, and specify the length of time the capture process should run for. If the duration is set to NULL, the capture runs until it is manually turned off using the FINISH_CAPTURE procedure.
BEGIN
DBMS_WORKLOAD_CAPTURE.start_capture (name => 'test_capture_1',
dir => 'DB_REPLAY_CAPTURE_DIR',
duration => NULL);
END;
/Now, we need to do some work to capture. First, we create a test user.
CREATE USER db_replay_test IDENTIFIED BY db_replay_test
QUOTA UNLIMITED ON users;
GRANT CONNECT, CREATE TABLE TO db_replay_test;Next, we create a table and populate it with some data.
CONN db_replay_test/db_replay_test@prod
CREATE TABLE db_replay_test_tab (
id NUMBER,
description VARCHAR2(50),
CONSTRAINT db_replay_test_tab_pk PRIMARY KEY (id)
);
BEGIN
FOR i IN 1 .. 500000 LOOP
INSERT INTO db_replay_test_tab (id, description)
VALUES (i, 'Description for ' || i);
END LOOP;
COMMIT;
END;
/Once the work is complete we can stop the capture using the FINISH_CAPTURE procedure.
CONN sys/password@prod AS SYSDBA
BEGIN
DBMS_WORKLOAD_CAPTURE.finish_capture;
END;
/If we check out the capture directory, we can see that some files have been generated there.
$ cd /u01/app/oracle/db_replay_capture
$ ls
wcr_4f9rtgw00238y.rec wcr_cr.html wcr_scapture.wmd
wcr_4f9rtjw002397.rec wcr_cr.text
wcr_4f9rtyw00239h.rec wcr_fcapture.wmd
$We can retrieve the ID of the capture run by passing the directory object name to the GET_CAPTURE_INFO function, or by querying the DBA_WORKLOAD_CAPTURES view.
SELECT DBMS_WORKLOAD_CAPTURE.get_capture_info('DB_REPLAY_CAPTURE_DIR')
FROM dual;
DBMS_WORKLOAD_CAPTURE.GET_CAPTURE_INFO('DB_REPLAY_CAPTURE_DIR')
---------------------------------------------------------------
21
1 row selected.
SQL>
COLUMN name FORMAT A30
SELECT id, name FROM dba_workload_captures;
ID NAME
---------- ------------------------------
21 test_capture_1
1 row selected.
SQL>The DBA_WORKLOAD_CAPTURES view contains information about the capture process. This can be queried directly, or a report can be generated in text or HTML format using the REPORT function.
DECLARE
l_report CLOB;
BEGIN
l_report := DBMS_WORKLOAD_CAPTURE.report(capture_id => 21,
format => DBMS_WORKLOAD_CAPTURE.TYPE_HTML);
END;
/The capture ID can be used to export the AWR snapshots associated with the specific capture run.
BEGIN
DBMS_WORKLOAD_CAPTURE.export_awr (capture_id => 21);
END;
/A quick look at the capture directory shows a dump file and associated log file have been produced.
$ cd /u01/app/oracle/db_replay_capture
$ ls
wcr_4f9rtgw00238y.rec wcr_ca.dmp wcr_cr.text
wcr_4f9rtjw002397.rec wcr_ca.log wcr_fcapture.wmd
wcr_4f9rtyw00239h.rec wcr_cr.html wcr_scapture.wmd
$Replay using the DBMS_WORKLOAD_REPLAY Package
The DBMS_WORKLOAD_REPLAY package provides a set of procedures and functions to control the replay process. In order to replay the logs captured on the "prod-11g" system, we need to transfers the capture files to our test system. Before we can do this, we need to create a directory on the "test-11g" system to put them in. For simplicity we will keep the name the same.
mkdir /u01/app/oracle/db_replay_captureTransfer the files from the production server to the test server.
Next, we create a directory object pointing to the new directory.
CONN sys/password@test AS SYSDBA
CREATE OR REPLACE DIRECTORY db_replay_capture_dir AS '/u01/app/oracle/db_replay_capture/';It is a good idea to adjust the test system time to match the time when the capture process was started. This way any time-based processing will react in the same way. For this test I have ignored this step.
We can now prepare to replay the existing capture logs using the PROCESS_CAPTURE, INITIALIZE_REPLAY and PREPARE_REPLAY procedures. I've named the replay with the same name as the capture process (test_capture_1), but this is not necessary.
BEGIN
DBMS_WORKLOAD_REPLAY.process_capture('DB_REPLAY_CAPTURE_DIR');
DBMS_WORKLOAD_REPLAY.initialize_replay (replay_name => 'test_capture_1',
replay_dir => 'DB_REPLAY_CAPTURE_DIR');
DBMS_WORKLOAD_REPLAY.prepare_replay (synchronization => TRUE);
END;
/Before we can start the replay, we need to calibrate and start a replay client using the "wrc" utility. The calibration step tells us the number of replay clients and hosts necessary to faithfully replay the workload.
$ wrc mode=calibrate replaydir=/u01/app/oracle/db_replay_capture
Workload Replay Client: Release 11.1.0.6.0 - Production on Tue Oct 30 09:33:42 2007
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Report for Workload in: /u01/app/oracle/db_replay_capture
-----------------------
Recommendation:
Consider using at least 1 clients divided among 1 CPU(s).
Workload Characteristics:
- max concurrency: 1 sessions
- total number of sessions: 3
Assumptions:
- 1 client process per 50 concurrent sessions
- 4 client process per CPU
- think time scale = 100
- connect time scale = 100
- synchronization = TRUE
$The calibration step suggest a single client on a single CPU is enough, so we only need to start a single replay client, which is shown below.
$ wrc system/password@test mode=replay replaydir=/u01/app/oracle/db_replay_capture
Workload Replay Client: Release 11.1.0.6.0 - Production on Tue Oct 30 09:34:14 2007
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Wait for the replay to start (09:34:14)The replay client pauses waiting for replay to start. We initiate replay with the following command.
BEGIN
DBMS_WORKLOAD_REPLAY.start_replay;
END;
/If you need to stop the replay before it is complete, call the CANCEL_REPLAY procedure.
The output from the replay client includes the start and finish time of the replay operation.
$ wrc system/password@test mode=replay replaydir=/u01/app/oracle/db_replay_capture
Workload Replay Client: Release 11.1.0.6.0 - Production on Tue Oct 30 09:34:14 2007
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Wait for the replay to start (09:34:14)
Replay started (09:34:44)
Replay finished (09:39:15)
$Once complete, we can see the DB_REPLAY_TEST_TAB table has been created and populated in the DB_REPLAY_TEST schema.
SQL> CONN sys/password@test AS SYSDBA
Connected.
SQL> SELECT table_name FROM dba_tables WHERE owner = 'DB_REPLAY_TEST';
TABLE_NAME
------------------------------
DB_REPLAY_TEST_TAB
SQL> SELECT COUNT(*) FROM db_replay_test.db_replay_test_tab;
COUNT(*)
----------
500000
SQL>Information about the replay processing is available from the DBA_WORKLOAD_REPLAYS view.
COLUMN name FORMAT A30
SELECT id, name FROM dba_workload_replays;
ID NAME
---------- ------------------------------
11 test_capture_1
1 row selected.
SQL>In addition, a report can be generated in text or HTML format using the REPORT function.
DECLARE
l_report CLOB;
BEGIN
l_report := DBMS_WORKLOAD_REPLAY.report(replay_id => 11,
format => DBMS_WORKLOAD_REPLAY.TYPE_HTML);
END;
/
The Database Replay functionality of Oracle 11g allows you to capture workloads on a production system and replay them exactly as they happened on a test system. This provides an accurate method to test the impact of a variety of system changes including:
Database upgrades.
Operating system upgrades or migrations.
Configuration changes, such as changes to initialization parameters or conversion from a single node to a RAC environment.
Hardware changes or migrations.
The capture and replay processes can be configured and initiated using PL/SQL APIs, or Enterprise Manager, both of which are demonstrated in this article. To keep things simple, the examples presented here are performed against two servers (prod-11g and test-11g), both of which run an identical database with a SID of DB11G.
Capture using the DBMS_WORKLOAD_CAPTURE Package
Replay using the DBMS_WORKLOAD_REPLAY Package
Capture using Enterprise Manager
Replay using Enterprise Manager
Capture using the DBMS_WORKLOAD_CAPTURE Package
The DBMS_WORKLOAD_CAPTURE package provides a set of procedures and functions to control the capture process. Before we can initiate the capture process we need an empty directory on the "prod-11g" database server to hold the capture logs.
mkdir /u01/app/oracle/db_replay_captureNext, we create a directory object pointing to the new directory.
CONN sys/password@prod AS SYSDBA
CREATE OR REPLACE DIRECTORY db_replay_capture_dir AS '/u01/app/oracle/db_replay_capture/';
-- Make sure existing processes are complete.
SHUTDOWN IMMEDIATE
STARTUPNotice the inclusion of a shutdown and startup of the database. This is not necessary, but Oracle suggest it as a good way to make sure any outstanding processes are complete before starting the capture process.
The combination of the ADD_FILTER procedure and the DEFAULT_ACTION parameter of the START_CAPTURE procedure allow the workload to be refined by including or excluding specific work based on the following attributes:
INSTANCE_NUMBER
USER
MODULE
ACTION
PROGRAM
SERVICE
For simplicity let's assume we want to capture everything, so we can ignore this and jump straight to the START_CAPTURE procedure. This procedure allows us to name a capture run, specify the directory the capture files should be placed in, and specify the length of time the capture process should run for. If the duration is set to NULL, the capture runs until it is manually turned off using the FINISH_CAPTURE procedure.
BEGIN
DBMS_WORKLOAD_CAPTURE.start_capture (name => 'test_capture_1',
dir => 'DB_REPLAY_CAPTURE_DIR',
duration => NULL);
END;
/Now, we need to do some work to capture. First, we create a test user.
CREATE USER db_replay_test IDENTIFIED BY db_replay_test
QUOTA UNLIMITED ON users;
GRANT CONNECT, CREATE TABLE TO db_replay_test;Next, we create a table and populate it with some data.
CONN db_replay_test/db_replay_test@prod
CREATE TABLE db_replay_test_tab (
id NUMBER,
description VARCHAR2(50),
CONSTRAINT db_replay_test_tab_pk PRIMARY KEY (id)
);
BEGIN
FOR i IN 1 .. 500000 LOOP
INSERT INTO db_replay_test_tab (id, description)
VALUES (i, 'Description for ' || i);
END LOOP;
COMMIT;
END;
/Once the work is complete we can stop the capture using the FINISH_CAPTURE procedure.
CONN sys/password@prod AS SYSDBA
BEGIN
DBMS_WORKLOAD_CAPTURE.finish_capture;
END;
/If we check out the capture directory, we can see that some files have been generated there.
$ cd /u01/app/oracle/db_replay_capture
$ ls
wcr_4f9rtgw00238y.rec wcr_cr.html wcr_scapture.wmd
wcr_4f9rtjw002397.rec wcr_cr.text
wcr_4f9rtyw00239h.rec wcr_fcapture.wmd
$We can retrieve the ID of the capture run by passing the directory object name to the GET_CAPTURE_INFO function, or by querying the DBA_WORKLOAD_CAPTURES view.
SELECT DBMS_WORKLOAD_CAPTURE.get_capture_info('DB_REPLAY_CAPTURE_DIR')
FROM dual;
DBMS_WORKLOAD_CAPTURE.GET_CAPTURE_INFO('DB_REPLAY_CAPTURE_DIR')
---------------------------------------------------------------
21
1 row selected.
SQL>
COLUMN name FORMAT A30
SELECT id, name FROM dba_workload_captures;
ID NAME
---------- ------------------------------
21 test_capture_1
1 row selected.
SQL>The DBA_WORKLOAD_CAPTURES view contains information about the capture process. This can be queried directly, or a report can be generated in text or HTML format using the REPORT function.
DECLARE
l_report CLOB;
BEGIN
l_report := DBMS_WORKLOAD_CAPTURE.report(capture_id => 21,
format => DBMS_WORKLOAD_CAPTURE.TYPE_HTML);
END;
/The capture ID can be used to export the AWR snapshots associated with the specific capture run.
BEGIN
DBMS_WORKLOAD_CAPTURE.export_awr (capture_id => 21);
END;
/A quick look at the capture directory shows a dump file and associated log file have been produced.
$ cd /u01/app/oracle/db_replay_capture
$ ls
wcr_4f9rtgw00238y.rec wcr_ca.dmp wcr_cr.text
wcr_4f9rtjw002397.rec wcr_ca.log wcr_fcapture.wmd
wcr_4f9rtyw00239h.rec wcr_cr.html wcr_scapture.wmd
$Replay using the DBMS_WORKLOAD_REPLAY Package
The DBMS_WORKLOAD_REPLAY package provides a set of procedures and functions to control the replay process. In order to replay the logs captured on the "prod-11g" system, we need to transfers the capture files to our test system. Before we can do this, we need to create a directory on the "test-11g" system to put them in. For simplicity we will keep the name the same.
mkdir /u01/app/oracle/db_replay_captureTransfer the files from the production server to the test server.
Next, we create a directory object pointing to the new directory.
CONN sys/password@test AS SYSDBA
CREATE OR REPLACE DIRECTORY db_replay_capture_dir AS '/u01/app/oracle/db_replay_capture/';It is a good idea to adjust the test system time to match the time when the capture process was started. This way any time-based processing will react in the same way. For this test I have ignored this step.
We can now prepare to replay the existing capture logs using the PROCESS_CAPTURE, INITIALIZE_REPLAY and PREPARE_REPLAY procedures. I've named the replay with the same name as the capture process (test_capture_1), but this is not necessary.
BEGIN
DBMS_WORKLOAD_REPLAY.process_capture('DB_REPLAY_CAPTURE_DIR');
DBMS_WORKLOAD_REPLAY.initialize_replay (replay_name => 'test_capture_1',
replay_dir => 'DB_REPLAY_CAPTURE_DIR');
DBMS_WORKLOAD_REPLAY.prepare_replay (synchronization => TRUE);
END;
/Before we can start the replay, we need to calibrate and start a replay client using the "wrc" utility. The calibration step tells us the number of replay clients and hosts necessary to faithfully replay the workload.
$ wrc mode=calibrate replaydir=/u01/app/oracle/db_replay_capture
Workload Replay Client: Release 11.1.0.6.0 - Production on Tue Oct 30 09:33:42 2007
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Report for Workload in: /u01/app/oracle/db_replay_capture
-----------------------
Recommendation:
Consider using at least 1 clients divided among 1 CPU(s).
Workload Characteristics:
- max concurrency: 1 sessions
- total number of sessions: 3
Assumptions:
- 1 client process per 50 concurrent sessions
- 4 client process per CPU
- think time scale = 100
- connect time scale = 100
- synchronization = TRUE
$The calibration step suggest a single client on a single CPU is enough, so we only need to start a single replay client, which is shown below.
$ wrc system/password@test mode=replay replaydir=/u01/app/oracle/db_replay_capture
Workload Replay Client: Release 11.1.0.6.0 - Production on Tue Oct 30 09:34:14 2007
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Wait for the replay to start (09:34:14)The replay client pauses waiting for replay to start. We initiate replay with the following command.
BEGIN
DBMS_WORKLOAD_REPLAY.start_replay;
END;
/If you need to stop the replay before it is complete, call the CANCEL_REPLAY procedure.
The output from the replay client includes the start and finish time of the replay operation.
$ wrc system/password@test mode=replay replaydir=/u01/app/oracle/db_replay_capture
Workload Replay Client: Release 11.1.0.6.0 - Production on Tue Oct 30 09:34:14 2007
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Wait for the replay to start (09:34:14)
Replay started (09:34:44)
Replay finished (09:39:15)
$Once complete, we can see the DB_REPLAY_TEST_TAB table has been created and populated in the DB_REPLAY_TEST schema.
SQL> CONN sys/password@test AS SYSDBA
Connected.
SQL> SELECT table_name FROM dba_tables WHERE owner = 'DB_REPLAY_TEST';
TABLE_NAME
------------------------------
DB_REPLAY_TEST_TAB
SQL> SELECT COUNT(*) FROM db_replay_test.db_replay_test_tab;
COUNT(*)
----------
500000
SQL>Information about the replay processing is available from the DBA_WORKLOAD_REPLAYS view.
COLUMN name FORMAT A30
SELECT id, name FROM dba_workload_replays;
ID NAME
---------- ------------------------------
11 test_capture_1
1 row selected.
SQL>In addition, a report can be generated in text or HTML format using the REPORT function.
DECLARE
l_report CLOB;
BEGIN
l_report := DBMS_WORKLOAD_REPLAY.report(replay_id => 11,
format => DBMS_WORKLOAD_REPLAY.TYPE_HTML);
END;
/
Oracle 11g Query Result Cache
Query Result Cache in Oracle Database 11g Release 1
Oracle 11g allows the results of SQL queries to be cached in the SGA and reused to improve performance. Set up the following schema objects to see how the SQL query cache works.
CREATE TABLE qrc_tab (
id NUMBER
);
INSERT INTO qrc_tab VALUES (1);
INSERT INTO qrc_tab VALUES (2);
INSERT INTO qrc_tab VALUES (3);
INSERT INTO qrc_tab VALUES (4);
INSERT INTO qrc_tab VALUES (5);
CREATE OR REPLACE FUNCTION slow_function(p_id IN qrc_tab.id%TYPE)
RETURN qrc_tab.id%TYPE DETERMINISTIC AS
BEGIN
DBMS_LOCK.sleep(1);
RETURN p_id;
END;
/
SET TIMING ONThe function contains a one second sleep so we can easily detect if it has been executed by checking the elapsed time of the query.
Next, we query the test table using the slow function and check out the elapsed time. Each run takes approximately five seconds, one second sleep for each row queried.
SELECT slow_function(id) FROM qrc_tab;
SLOW_FUNCTION(ID)
-----------------
1
2
3
4
5
5 rows selected.
Elapsed: 00:00:05.15
SQL>Adding the RESULT_CACHE hint to the query tells the server to attempt to retrieve the information from the result cache. If the information is not present, it will cache the results of the query provided there is enough room in the result cache. Since we have no cached results, we would expect the first run to take approximately five seconds, but subsequent runs to be much quicker.
SELECT /*+ result_cache */ slow_function(id) FROM qrc_tab;
SLOW_FUNCTION(ID)
-----------------
1
2
3
4
5
5 rows selected.
Elapsed: 00:00:05.20
SELECT /*+ result_cache */ slow_function(id) FROM qrc_tab;
SLOW_FUNCTION(ID)
-----------------
1
2
3
4
5
5 rows selected.
Elapsed: 00:00:00.15
SQL>The default action of the result cache is controlled by the RESULT_CACHE_MODE parameter. When it is set to MANUAL, the RESULT_CACHE hint must be used for a query to access the result cache.
SHOW PARAMETER RESULT_CACHE_MODE
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
result_cache_mode string MANUAL
SQL>If we set the RESULT_CACHE_MODE parameter to FORCE, the result cache is used by default, but we can bypass it using the NO_RESULT_CACHE hint.
ALTER SESSION SET RESULT_CACHE_MODE=FORCE;
SELECT slow_function(id) FROM qrc_tab;
SLOW_FUNCTION(ID)
-----------------
1
2
3
4
5
5 rows selected.
Elapsed: 00:00:00.14
SELECT /*+ no_result_cache */ slow_function(id) FROM qrc_tab;
SLOW_FUNCTION(ID)
-----------------
1
2
3
4
5
5 rows selected.
Elapsed: 00:00:05.14
SQL>
Oracle 11g allows the results of SQL queries to be cached in the SGA and reused to improve performance. Set up the following schema objects to see how the SQL query cache works.
CREATE TABLE qrc_tab (
id NUMBER
);
INSERT INTO qrc_tab VALUES (1);
INSERT INTO qrc_tab VALUES (2);
INSERT INTO qrc_tab VALUES (3);
INSERT INTO qrc_tab VALUES (4);
INSERT INTO qrc_tab VALUES (5);
CREATE OR REPLACE FUNCTION slow_function(p_id IN qrc_tab.id%TYPE)
RETURN qrc_tab.id%TYPE DETERMINISTIC AS
BEGIN
DBMS_LOCK.sleep(1);
RETURN p_id;
END;
/
SET TIMING ONThe function contains a one second sleep so we can easily detect if it has been executed by checking the elapsed time of the query.
Next, we query the test table using the slow function and check out the elapsed time. Each run takes approximately five seconds, one second sleep for each row queried.
SELECT slow_function(id) FROM qrc_tab;
SLOW_FUNCTION(ID)
-----------------
1
2
3
4
5
5 rows selected.
Elapsed: 00:00:05.15
SQL>Adding the RESULT_CACHE hint to the query tells the server to attempt to retrieve the information from the result cache. If the information is not present, it will cache the results of the query provided there is enough room in the result cache. Since we have no cached results, we would expect the first run to take approximately five seconds, but subsequent runs to be much quicker.
SELECT /*+ result_cache */ slow_function(id) FROM qrc_tab;
SLOW_FUNCTION(ID)
-----------------
1
2
3
4
5
5 rows selected.
Elapsed: 00:00:05.20
SELECT /*+ result_cache */ slow_function(id) FROM qrc_tab;
SLOW_FUNCTION(ID)
-----------------
1
2
3
4
5
5 rows selected.
Elapsed: 00:00:00.15
SQL>The default action of the result cache is controlled by the RESULT_CACHE_MODE parameter. When it is set to MANUAL, the RESULT_CACHE hint must be used for a query to access the result cache.
SHOW PARAMETER RESULT_CACHE_MODE
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
result_cache_mode string MANUAL
SQL>If we set the RESULT_CACHE_MODE parameter to FORCE, the result cache is used by default, but we can bypass it using the NO_RESULT_CACHE hint.
ALTER SESSION SET RESULT_CACHE_MODE=FORCE;
SELECT slow_function(id) FROM qrc_tab;
SLOW_FUNCTION(ID)
-----------------
1
2
3
4
5
5 rows selected.
Elapsed: 00:00:00.14
SELECT /*+ no_result_cache */ slow_function(id) FROM qrc_tab;
SLOW_FUNCTION(ID)
-----------------
1
2
3
4
5
5 rows selected.
Elapsed: 00:00:05.14
SQL>
Oracle 11g Flashback Data Archive (Oracle Total Recall)
Flashback Data Archive (Oracle Total Recall)
Most flashback features work at the logical level, in that they don't directly allow you to recover an object. They simply give you a view of how the data was in the past, which in turn can be used to recover from logical corruption, such as accidental deletions. Typically, this view of the past is constructed using undo segments, which are retained for a period of time indicated by the UNDO_RETENTION parameter. Once the undo information is lost, the view of the past is lost also. At least that's how it was before Oracle 11g introduced the Flashback Data Archive functionality.
A flashback data archive is essentially an extended store of undo information, allowing some logical flashback operations to extend way back into the past with no difference in how they are coded. An individual flashback archives consists of one or more tablespaces, or parts of tablespace. Each flashback archive has a name, retention period and a quota on each associated tablespace. The database can have multiple flashback data archives, but only a single default archive. When a DML transaction commits an operation on a flashback archive enabled table, the Flashback Data Archiver (FBDA) process stores the pre-image of the rows into a flashback archive, along with metadata of the current rows. The FBDA process is also responsible for managing the data within the flashback archives, such as purging data beyond the retention period.
The following script creates a new tablespace, then creates two flashback data archives using the CREATE FLASHBACK ARCHIVE command. The first is limited in size to 10Gig with a retention period of 1 year, while the second has an unlimited quota and a retention period of 2 years.
CREATE TABLESPACE fda_ts
DATAFILE '/u01/app/oracle/oradata/DB11G/fda1_01.dbf'
SIZE 1M AUTOEXTEND ON NEXT 1M;
CREATE FLASHBACK ARCHIVE DEFAULT fda_1year TABLESPACE fda_ts
QUOTA 10G RETENTION 1 YEAR;
CREATE FLASHBACK ARCHIVE fda_2year TABLESPACE fda_ts
RETENTION 2 YEAR;Management of flashback archives falls into three distinct categories:
Tablespace management.
-- Set as default FBA
ALTER FLASHBACK ARCHIVE fba_name SET DEFAULT;
-- Add up to 10G of the specified tablespace to the specified flashback archive.
ALTER FLASHBACK ARCHIVE fba_name ADD TABLESPACE ts_name QUOTA 10G;
-- Add an unlimited quota of the specified tablespace to the specified flashback archive.
ALTER FLASHBACK ARCHIVE fba_name ADD TABLESPACE ts_name;
-- Change the tablespace quota to 20G.
ALTER FLASHBACK ARCHIVE fba_name MODIFY TABLESPACE ts_name QUOTA 20G;
-- Change the tablespace quota to unlimited.ALTER FLASHBACK ARCHIVE fba_name MODIFY TABLESPACE ts_name;
-- Remove the specified tablespace from the archive.
ALTER FLASHBACK ARCHIVE fba_name REMOVE TABLESPACE ts_name;Modifying the retention period.
ALTER FLASHBACK ARCHIVE fba_name MODIFY RETENTION 2 YEAR;
Purging data.
-- Remove all historical data.
ALTER FLASHBACK ARCHIVE fba_name PURGE ALL;
-- Remove all data before the specified time.
ALTER FLASHBACK ARCHIVE fba_name PURGE BEFORE TIMESTAMP (SYSTIMESTAMP - INTERVAL '1' DAY);
-- Remove all data before the specified SCN.
ALTER FLASHBACK ARCHIVE fba_name PURGE BEFORE SCN 728969;Archives are removed using the DROP FLASHBACK ARCHIVE command, which drops the archive and all its historical data, but doesn't drop the associated tablespace.
DROP FLASHBACK ARCHIVE fba_name;
To enable flashback archiving on a specific table the user must have the FLASHBACK ARCHIVE object privilege on the specific flashback archive used. To try this out create a test user and grant the object privilege on the first flashback archive created earlier.
CONN sys/password AS SYSDBA
CREATE USER fda_test_user IDENTIFIED BY fda_test_user QUOTA UNLIMITED ON users;
GRANT CONNECT, CREATE TABLE TO fda_test_user;
GRANT FLASHBACK ARCHIVE ON fda_1year TO fda_test_user;
If we connect to the test user we are able to create a table and associate it with the default flashback archive as follows.
CONN fda_test_user/fda_test_user
CREATE TABLE test_tab_1 (
id NUMBER,
desription VARCHAR2(50),
CONSTRAINT test_tab_1_pk PRIMARY KEY (id)
)
FLASHBACK ARCHIVE;If we try to create a similar table, but point it at the second archive it fails, as we have no privileges on it.
CONN fda_test_user/fda_test_user
CREATE TABLE test_tab_2 (
id NUMBER,
desription VARCHAR2(50),
CONSTRAINT test_tab_2_pk PRIMARY KEY (id)
)
FLASHBACK ARCHIVE fda_2year;
CREATE TABLE test_tab_2 (
*
ERROR at line 1:
ORA-55620: No privilege to use Flashback Archive
SQL>The ALTER TABLE command allows existing tables to have flashback archiving switched on or off.
-- Enable using the default FBDA.
ALTER TABLE table_name FLASHBACK ARCHIVE;
-- Enable using specific FBDA.
ALTER TABLE table_name FLASHBACK ARCHIVE fda_name;
-- Disable flashback archiving.
ALTER TABLE table_name NO FLASHBACK ARCHIVE;
As with the CREATE TABLE statement, the FLASHBACK ARCHIVE object privilege must be granted on the flashback archive being used.
Once flashback archiving is enabled the table is protected, so it cannot be switched off unless you have the FLASHBACK ARCHIVE ADMINISTER system privilege, or are logged on as SYSDBA.
SQL> ALTER TABLE test_tab_1 NO FLASHBACK ARCHIVE;
ALTER TABLE test_tab_1 NO FLASHBACK ARCHIVE
*
ERROR at line 1:
ORA-55620: No privilege to use Flashback Archive
SQL>In addition, there are certain DDL restrictions associated with having flashback archiving enabled. The following operations result in a ORA-55610 error:
ALTER TABLE statements that drop, rename or modify columns.
ALTER TABLE statements that performs partition or subpartition operations.
ALTER TABLE statements that converts a LONG column to a LOB column.
ALTER TABLE statements that includes an UPGRADE TABLE clause, with or without an INCLUDING DATA clause.
DROP TABLE statements.
RENAME TABLE statements.
TRUNCATE TABLE statements.
Information about flashback data archives is displayed using the %_FLASHBACK_ARCHIVE view.
CONN sys/password AS SYSDBA
COLUMN flashback_archive_name FORMAT A20
SELECT flashback_archive_name, retention_in_days, status
FROM dba_flashback_archive;
FLASHBACK_ARCHIVE_NA RETENTION_IN_DAYS STATUS
-------------------- ----------------- -------
FDA_2YEAR 730
FDA_1YEAR 365 DEFAULT
2 rows selected.
SQL>The %_FLASHBACK_ARCHIVE_TS view displays the tablespaces and quotas associated with each flashback archive.
COLUMN flashback_archive_name FORMAT A20
COLUMN quota_in_mb FORMAT A10
SELECT flashback_archive_name, tablespace_name, quota_in_mb
FROM dba_flashback_archive_ts;
FLASHBACK_ARCHIVE_NA TABLESPACE_NAME QUOTA_IN_M
-------------------- ------------------------------ ----------
FDA_2YEAR FDA_TS
FDA_1YEAR FDA_TS 10240
2 rows selected.
SQL>
The %_FLASHBACK_ARCHIVE_TABLES view displays tables associated with each flashback archive, along with the name of the table holding the historical information.
COLUMN table_name FORMAT A15
COLUMN owner_name FORMAT A15
COLUMN flashback_archive_name FORMAT A20
COLUMN archive_table_name FORMAT A20
SELECT table_name, owner_name, flashback_archive_name, archive_table_name
FROM dba_flashback_archive_tables;
TABLE_NAME OWNER_NAME FLASHBACK_ARCHIVE_NA ARCHIVE_TABLE_NAME
--------------- --------------- -------------------- --------------------
TEST_TAB_1 FDA_TEST_USER FDA_1YEAR SYS_FBA_HIST_72023
1 row selected.
SQL>
Most flashback features work at the logical level, in that they don't directly allow you to recover an object. They simply give you a view of how the data was in the past, which in turn can be used to recover from logical corruption, such as accidental deletions. Typically, this view of the past is constructed using undo segments, which are retained for a period of time indicated by the UNDO_RETENTION parameter. Once the undo information is lost, the view of the past is lost also. At least that's how it was before Oracle 11g introduced the Flashback Data Archive functionality.
A flashback data archive is essentially an extended store of undo information, allowing some logical flashback operations to extend way back into the past with no difference in how they are coded. An individual flashback archives consists of one or more tablespaces, or parts of tablespace. Each flashback archive has a name, retention period and a quota on each associated tablespace. The database can have multiple flashback data archives, but only a single default archive. When a DML transaction commits an operation on a flashback archive enabled table, the Flashback Data Archiver (FBDA) process stores the pre-image of the rows into a flashback archive, along with metadata of the current rows. The FBDA process is also responsible for managing the data within the flashback archives, such as purging data beyond the retention period.
The following script creates a new tablespace, then creates two flashback data archives using the CREATE FLASHBACK ARCHIVE command. The first is limited in size to 10Gig with a retention period of 1 year, while the second has an unlimited quota and a retention period of 2 years.
CREATE TABLESPACE fda_ts
DATAFILE '/u01/app/oracle/oradata/DB11G/fda1_01.dbf'
SIZE 1M AUTOEXTEND ON NEXT 1M;
CREATE FLASHBACK ARCHIVE DEFAULT fda_1year TABLESPACE fda_ts
QUOTA 10G RETENTION 1 YEAR;
CREATE FLASHBACK ARCHIVE fda_2year TABLESPACE fda_ts
RETENTION 2 YEAR;Management of flashback archives falls into three distinct categories:
Tablespace management.
-- Set as default FBA
ALTER FLASHBACK ARCHIVE fba_name SET DEFAULT;
-- Add up to 10G of the specified tablespace to the specified flashback archive.
ALTER FLASHBACK ARCHIVE fba_name ADD TABLESPACE ts_name QUOTA 10G;
-- Add an unlimited quota of the specified tablespace to the specified flashback archive.
ALTER FLASHBACK ARCHIVE fba_name ADD TABLESPACE ts_name;
-- Change the tablespace quota to 20G.
ALTER FLASHBACK ARCHIVE fba_name MODIFY TABLESPACE ts_name QUOTA 20G;
-- Change the tablespace quota to unlimited.ALTER FLASHBACK ARCHIVE fba_name MODIFY TABLESPACE ts_name;
-- Remove the specified tablespace from the archive.
ALTER FLASHBACK ARCHIVE fba_name REMOVE TABLESPACE ts_name;Modifying the retention period.
ALTER FLASHBACK ARCHIVE fba_name MODIFY RETENTION 2 YEAR;
Purging data.
-- Remove all historical data.
ALTER FLASHBACK ARCHIVE fba_name PURGE ALL;
-- Remove all data before the specified time.
ALTER FLASHBACK ARCHIVE fba_name PURGE BEFORE TIMESTAMP (SYSTIMESTAMP - INTERVAL '1' DAY);
-- Remove all data before the specified SCN.
ALTER FLASHBACK ARCHIVE fba_name PURGE BEFORE SCN 728969;Archives are removed using the DROP FLASHBACK ARCHIVE command, which drops the archive and all its historical data, but doesn't drop the associated tablespace.
DROP FLASHBACK ARCHIVE fba_name;
To enable flashback archiving on a specific table the user must have the FLASHBACK ARCHIVE object privilege on the specific flashback archive used. To try this out create a test user and grant the object privilege on the first flashback archive created earlier.
CONN sys/password AS SYSDBA
CREATE USER fda_test_user IDENTIFIED BY fda_test_user QUOTA UNLIMITED ON users;
GRANT CONNECT, CREATE TABLE TO fda_test_user;
GRANT FLASHBACK ARCHIVE ON fda_1year TO fda_test_user;
If we connect to the test user we are able to create a table and associate it with the default flashback archive as follows.
CONN fda_test_user/fda_test_user
CREATE TABLE test_tab_1 (
id NUMBER,
desription VARCHAR2(50),
CONSTRAINT test_tab_1_pk PRIMARY KEY (id)
)
FLASHBACK ARCHIVE;If we try to create a similar table, but point it at the second archive it fails, as we have no privileges on it.
CONN fda_test_user/fda_test_user
CREATE TABLE test_tab_2 (
id NUMBER,
desription VARCHAR2(50),
CONSTRAINT test_tab_2_pk PRIMARY KEY (id)
)
FLASHBACK ARCHIVE fda_2year;
CREATE TABLE test_tab_2 (
*
ERROR at line 1:
ORA-55620: No privilege to use Flashback Archive
SQL>The ALTER TABLE command allows existing tables to have flashback archiving switched on or off.
-- Enable using the default FBDA.
ALTER TABLE table_name FLASHBACK ARCHIVE;
-- Enable using specific FBDA.
ALTER TABLE table_name FLASHBACK ARCHIVE fda_name;
-- Disable flashback archiving.
ALTER TABLE table_name NO FLASHBACK ARCHIVE;
As with the CREATE TABLE statement, the FLASHBACK ARCHIVE object privilege must be granted on the flashback archive being used.
Once flashback archiving is enabled the table is protected, so it cannot be switched off unless you have the FLASHBACK ARCHIVE ADMINISTER system privilege, or are logged on as SYSDBA.
SQL> ALTER TABLE test_tab_1 NO FLASHBACK ARCHIVE;
ALTER TABLE test_tab_1 NO FLASHBACK ARCHIVE
*
ERROR at line 1:
ORA-55620: No privilege to use Flashback Archive
SQL>In addition, there are certain DDL restrictions associated with having flashback archiving enabled. The following operations result in a ORA-55610 error:
ALTER TABLE statements that drop, rename or modify columns.
ALTER TABLE statements that performs partition or subpartition operations.
ALTER TABLE statements that converts a LONG column to a LOB column.
ALTER TABLE statements that includes an UPGRADE TABLE clause, with or without an INCLUDING DATA clause.
DROP TABLE statements.
RENAME TABLE statements.
TRUNCATE TABLE statements.
Information about flashback data archives is displayed using the %_FLASHBACK_ARCHIVE view.
CONN sys/password AS SYSDBA
COLUMN flashback_archive_name FORMAT A20
SELECT flashback_archive_name, retention_in_days, status
FROM dba_flashback_archive;
FLASHBACK_ARCHIVE_NA RETENTION_IN_DAYS STATUS
-------------------- ----------------- -------
FDA_2YEAR 730
FDA_1YEAR 365 DEFAULT
2 rows selected.
SQL>The %_FLASHBACK_ARCHIVE_TS view displays the tablespaces and quotas associated with each flashback archive.
COLUMN flashback_archive_name FORMAT A20
COLUMN quota_in_mb FORMAT A10
SELECT flashback_archive_name, tablespace_name, quota_in_mb
FROM dba_flashback_archive_ts;
FLASHBACK_ARCHIVE_NA TABLESPACE_NAME QUOTA_IN_M
-------------------- ------------------------------ ----------
FDA_2YEAR FDA_TS
FDA_1YEAR FDA_TS 10240
2 rows selected.
SQL>
The %_FLASHBACK_ARCHIVE_TABLES view displays tables associated with each flashback archive, along with the name of the table holding the historical information.
COLUMN table_name FORMAT A15
COLUMN owner_name FORMAT A15
COLUMN flashback_archive_name FORMAT A20
COLUMN archive_table_name FORMAT A20
SELECT table_name, owner_name, flashback_archive_name, archive_table_name
FROM dba_flashback_archive_tables;
TABLE_NAME OWNER_NAME FLASHBACK_ARCHIVE_NA ARCHIVE_TABLE_NAME
--------------- --------------- -------------------- --------------------
TEST_TAB_1 FDA_TEST_USER FDA_1YEAR SYS_FBA_HIST_72023
1 row selected.
SQL>
miércoles, 4 de noviembre de 2009
Oracle 10g Copiar una base de datos Windows
Copiar una base de datos.
La petición textual era la creación de una base de datos igual que otra, pero con otro nombre. En algunos casos se trataba de replicar el entorno de producción para usarlo como test. En otros, simplemente, testear que el backup permitía recuperar la base de datos sobre otra máquina y dejar esa base de datos operativa como entorno auxiliar.
Cuando la base de datos puede conservar el mismo nombre y mismo SID, es tan fácil como copiar datafiles, redolog, controlfiles y archivos ORA sobre los mismos directorios originales en una máquina con un servidor Oracle instalado*.
* Por supuesto, misma plataforma O.S., versión y release de Oracle.
No obstante, en los casos en los que el nombre debe ser diferente, hay que ser muy preciso con los pasos a seguir. Incluyo dos pasos previos como opcionales por si son de utilidad.
En este ejemplo se asume que disponemos de la posibilidad de hacer un backup en frío de la base de datos.
Pasos preliminares (recomendado):
- Backup frío, backup caliente, export, Transport Tablespaces, backup del backup, backup de todo lo posible.
- Reducción de tamaño de los datafiles. (Tom Kyte tiene un fabuloso script para ello). Y otra vez backup.
Pasos a seguir:
1.- Backup en frío de la BBDD original
2.- Generación del pfile para la nueva BBDD
3.- Edición del pfile para sustituir: CONTROL_FILES, DB_NAME, y carpetas _DUMP_DEST,...
4.- Definir el nuevo ORACLE_SID
5.- Crear el nuevo servicio.
6.- Creación del fichero de passwords (sólo si el pfile tiene REMOTE_LOGIN_PASSWORDFILE=exclusive)
7.- Conexión a sqlplus como SYSDBA
8.- Arranque de la instancia y creación del fichero de parámetros SPFILE
9.- Backup del controlfile de la BBDD original a traza
10.- Recreación del controlfile con la cláusula SET NAME.
11.- Abrir la base de datos con modo OPEN RESETLOGS.
1.- Backup en frío de la BBDD original.
Restauración del backup sobre nueva ubicación.
-- Ejecutar el resultado de la siguiente sentencia como script.
-- NOTA: cuidado con los nombres duplicados de fichero.
-------------------------------------------------------------
select 'shutdown immediate;' from dual
union all
select 'host copy '||name||' &&directorio_destino' from v$controlfile
union all
select 'host copy '||member||' &directorio_destino' from v$logfile
union all
select 'host copy '||name||' &directorio_destino' from v$datafile
union all
select 'startup' from dual;
-- copia de los ficheros a los directorios destino
---------------------------------------------------
2.- Generación del pfile para la nueva base de datos
SQL> create pfile='?\admin\sid\pfile\inittest.ora' from spfile;
Archivo creado.
3.- Edición del pfile para sustituir: CONTROL_FILES, DB_NAME, y carpetas _DUMP_DEST,...
4.- Definir el nuevo ORACLE_SID
c:\>set ORACLE_SID=test
5.- Crear el nuevo servicio.
c:\>oradim -NEW -SRVC OracleServicetest -startmode auto
6.- Creación del fichero de passwords
c:\>orapwd file=C:\orant\ora92\database\PWDtest.ora password=xxxxxxxxx
7.- Conexión a sqlplus como SYSDBA
C:\>sqlplus
SQL*Plus: Release 10.2.0.4 - Production on Vie Jul 29 16:41:22 2005
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Introduzca el nombre de usuario: sys/xxxxxxxxxx as sysdba
Conectado a una instancia inactiva.
8.- Arranque de la instancia y creación del fichero de parámetros SPFILE
SQL> STARTUP NOMOUNT PFILE='C:\DIRECTORIO_DESTINO\inittest.ora'
Instancia ORACLE iniciada.
Total System Global Area 1074866044 bytes
Fixed Size 456572 bytes
Variable Size 905969664 bytes
Database Buffers 167772160 bytes
Redo Buffers 667648 bytes
SQL> create spfile from pfile='C:\DIRECTORIO_DESTINO\inittest.ora';
Archivo creado.
9.- Backup del controlfile de PROD a trace.
SQL> alter database backup controlfile to trace;
Base de datos modificada.
10.- A partir de la traza del fichero de control.
Recreación del controlfile con el SET NAME al nuevo nombre.
CREATE CONTROLFILE SET DATABASE "TEST" RESETLOGS NOARCHIVELOG REUSE
MAXLOGFILES 50
MAXLOGMEMBERS 5
MAXDATAFILES 133
MAXINSTANCES 1
MAXLOGHISTORY 453
LOGFILE
GROUP 2 'C:\DATA\TEST\REDO\REDO02.LOG' SIZE 100M,
GROUP 3 'C:\DATA\TEST\REDO\REDO03.LOG' SIZE 100M,
GROUP 4 'C:\DATA\TEST\REDO\REDO04.LOG' SIZE 150M,
GROUP 5 'C:\DATA\TEST\REDO\REDO05.LOG' SIZE 150M,
GROUP 6 'C:\DATA\TEST\REDO\REDO06.LOG' SIZE 200M
-- STANDBY LOGFILE
DATAFILE
(... ficheros...)
'C:\DATA\TEST\SYSTEM\SYSTEM01.DBF',
'C:\DATA\TEST\DATA\DATA01.DBF'
CHARACTER SET WE8MSWIN1252
;
Archivo de control creado.
11.- Abrir la base de datos con modo OPEN RESETLOGS.
SQL> alter database open resetlogs;
Base de datos modificada.
12.- Verificación.
SQL> select instance_name from v$instance;
INSTANCE_NAME
----------------
test
SQL> select name from v$database;
NAME
---------
TEST
SQL> select status from v$thread;
STATUS
------
OPEN
12.- Shutdown y Open de la base de datos.
SQL> shutdown immediate;
Base de datos cerrada.
Base de datos desmontada.
Instancia ORACLE cerrada.
SQL> startup
Instancia ORACLE iniciada.
Total System Global Area 1074866044 bytes
Fixed Size 456572 bytes
Variable Size 905969664 bytes
Database Buffers 167772160 bytes
Redo Buffers 667648 bytes
Base de datos montada.
Base de datos abierta.
La petición textual era la creación de una base de datos igual que otra, pero con otro nombre. En algunos casos se trataba de replicar el entorno de producción para usarlo como test. En otros, simplemente, testear que el backup permitía recuperar la base de datos sobre otra máquina y dejar esa base de datos operativa como entorno auxiliar.
Cuando la base de datos puede conservar el mismo nombre y mismo SID, es tan fácil como copiar datafiles, redolog, controlfiles y archivos ORA sobre los mismos directorios originales en una máquina con un servidor Oracle instalado*.
* Por supuesto, misma plataforma O.S., versión y release de Oracle.
No obstante, en los casos en los que el nombre debe ser diferente, hay que ser muy preciso con los pasos a seguir. Incluyo dos pasos previos como opcionales por si son de utilidad.
En este ejemplo se asume que disponemos de la posibilidad de hacer un backup en frío de la base de datos.
Pasos preliminares (recomendado):
- Backup frío, backup caliente, export, Transport Tablespaces, backup del backup, backup de todo lo posible.
- Reducción de tamaño de los datafiles. (Tom Kyte tiene un fabuloso script para ello). Y otra vez backup.
Pasos a seguir:
1.- Backup en frío de la BBDD original
2.- Generación del pfile para la nueva BBDD
3.- Edición del pfile para sustituir: CONTROL_FILES, DB_NAME, y carpetas _DUMP_DEST,...
4.- Definir el nuevo ORACLE_SID
5.- Crear el nuevo servicio.
6.- Creación del fichero de passwords (sólo si el pfile tiene REMOTE_LOGIN_PASSWORDFILE=exclusive)
7.- Conexión a sqlplus como SYSDBA
8.- Arranque de la instancia y creación del fichero de parámetros SPFILE
9.- Backup del controlfile de la BBDD original a traza
10.- Recreación del controlfile con la cláusula SET NAME.
11.- Abrir la base de datos con modo OPEN RESETLOGS.
1.- Backup en frío de la BBDD original.
Restauración del backup sobre nueva ubicación.
-- Ejecutar el resultado de la siguiente sentencia como script.
-- NOTA: cuidado con los nombres duplicados de fichero.
-------------------------------------------------------------
select 'shutdown immediate;' from dual
union all
select 'host copy '||name||' &&directorio_destino' from v$controlfile
union all
select 'host copy '||member||' &directorio_destino' from v$logfile
union all
select 'host copy '||name||' &directorio_destino' from v$datafile
union all
select 'startup' from dual;
-- copia de los ficheros a los directorios destino
---------------------------------------------------
2.- Generación del pfile para la nueva base de datos
SQL> create pfile='?\admin\sid\pfile\inittest.ora' from spfile;
Archivo creado.
3.- Edición del pfile para sustituir: CONTROL_FILES, DB_NAME, y carpetas _DUMP_DEST,...
4.- Definir el nuevo ORACLE_SID
c:\>set ORACLE_SID=test
5.- Crear el nuevo servicio.
c:\>oradim -NEW -SRVC OracleServicetest -startmode auto
6.- Creación del fichero de passwords
c:\>orapwd file=C:\orant\ora92\database\PWDtest.ora password=xxxxxxxxx
7.- Conexión a sqlplus como SYSDBA
C:\>sqlplus
SQL*Plus: Release 10.2.0.4 - Production on Vie Jul 29 16:41:22 2005
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Introduzca el nombre de usuario: sys/xxxxxxxxxx as sysdba
Conectado a una instancia inactiva.
8.- Arranque de la instancia y creación del fichero de parámetros SPFILE
SQL> STARTUP NOMOUNT PFILE='C:\DIRECTORIO_DESTINO\inittest.ora'
Instancia ORACLE iniciada.
Total System Global Area 1074866044 bytes
Fixed Size 456572 bytes
Variable Size 905969664 bytes
Database Buffers 167772160 bytes
Redo Buffers 667648 bytes
SQL> create spfile from pfile='C:\DIRECTORIO_DESTINO\inittest.ora';
Archivo creado.
9.- Backup del controlfile de PROD a trace.
SQL> alter database backup controlfile to trace;
Base de datos modificada.
10.- A partir de la traza del fichero de control.
Recreación del controlfile con el SET NAME al nuevo nombre.
CREATE CONTROLFILE SET DATABASE "TEST" RESETLOGS NOARCHIVELOG REUSE
MAXLOGFILES 50
MAXLOGMEMBERS 5
MAXDATAFILES 133
MAXINSTANCES 1
MAXLOGHISTORY 453
LOGFILE
GROUP 2 'C:\DATA\TEST\REDO\REDO02.LOG' SIZE 100M,
GROUP 3 'C:\DATA\TEST\REDO\REDO03.LOG' SIZE 100M,
GROUP 4 'C:\DATA\TEST\REDO\REDO04.LOG' SIZE 150M,
GROUP 5 'C:\DATA\TEST\REDO\REDO05.LOG' SIZE 150M,
GROUP 6 'C:\DATA\TEST\REDO\REDO06.LOG' SIZE 200M
-- STANDBY LOGFILE
DATAFILE
(... ficheros...)
'C:\DATA\TEST\SYSTEM\SYSTEM01.DBF',
'C:\DATA\TEST\DATA\DATA01.DBF'
CHARACTER SET WE8MSWIN1252
;
Archivo de control creado.
11.- Abrir la base de datos con modo OPEN RESETLOGS.
SQL> alter database open resetlogs;
Base de datos modificada.
12.- Verificación.
SQL> select instance_name from v$instance;
INSTANCE_NAME
----------------
test
SQL> select name from v$database;
NAME
---------
TEST
SQL> select status from v$thread;
STATUS
------
OPEN
12.- Shutdown y Open de la base de datos.
SQL> shutdown immediate;
Base de datos cerrada.
Base de datos desmontada.
Instancia ORACLE cerrada.
SQL> startup
Instancia ORACLE iniciada.
Total System Global Area 1074866044 bytes
Fixed Size 456572 bytes
Variable Size 905969664 bytes
Database Buffers 167772160 bytes
Redo Buffers 667648 bytes
Base de datos montada.
Base de datos abierta.
Oracle Uso de Logminer
EXAMPLE 1
alter session set nls_date_format = 'dd-mm-yyyy hh24:mi:ss' ;
alter session set nls_language = american ;
set lines 4000
set trimspool on
set feed off
col session_info format a40 word_wrap
col sql_redo format a90 word_wrap
col sql_undo format a90 word_wrap
begin
sys.dbms_logmnr.add_logfile ('/SCEL/data14/archives/hagc/arch_1_189771.arc',sys.dbms_logmnr.new) ;
sys.dbms_logmnr.add_logfile ('/SCEL/data14/archives/hagc/arch_1_189772.arc',sys.dbms_logmnr.addfile) ;
sys.dbms_logmnr.add_logfile ('/SCEL/data14/archives/hagc/arch_1_189773.arc',sys.dbms_logmnr.addfile) ;
end ;
/
-- Para rastrear DMLs
--
exec sys.dbms_logmnr.start_logmnr (options => sys.DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + sys.DBMS_LOGMNR.COMMITTED_DATA_ONLY -
+ SYS.DBMS_LOGMNR.PRINT_PRETTY_SQL );
--
-- Para rastrear DDLs
--
--exec sys.dbms_logmnr.start_logmnr (options => sys.DBMS_LOGMNR.DDL_DICT_TRACKING)
spool /tmp/invest.lst
set feed on
set pages 200
set lines 4000
set trimspool on
set term off
select
username,
timestamp,
session_info,
sql_redo ,
sql_undo ,
operation
from
v$logmnr_contents t
WHERE
upper (seg_owner) = 'SISCEL'
and upper (seg_name) = 'GA_SERVSUPLABO'
--or lower (seg_name) = 'bpd_planes'
-- upper (username) in ('DYRUIZGO')
-- UPPER (session_info) like '%ELIPROGS%'
--operation = 'DDL'
;
spool off
EXEC sys.DBMS_LOGMNR.END_LOGMNR
EXAMPLE 2
SQL> connect / as sysdba
Conectado.
SQL> show parameters utl
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
utl_file_dir string c:\oraclefiles
SQL> exec DBMS_LOGMNR_D.BUILD( DICTIONARY_FILENAME =>'dictionary.ora', DICTIONARY_LOCATION => 'c:\oraclefiles');
Procedimiento PL/SQL terminado correctamente.
SQL> select member from v$logfile;
MEMBER
--------------------------------------------------------------------------------
C:\ORACLE\ORADATA\ORCL\REDO04A.LOG
C:\ORACLE\ORADATA\ORCL\REDO04B.LOG
C:\ORACLE\ORADATA\ORCL\REDO05A.LOG
C:\ORACLE\ORADATA\ORCL\REDO05B.LOG
C:\ORACLE\ORADATA\ORCL\REDO06A.LOG
C:\ORACLE\ORADATA\ORCL\REDO06B.LOG
6 filas seleccionadas.
SQL> exec DBMS_LOGMNR.add_logfile('C:\ORACLE\ORADATA\ORCL\REDO04A.LOG');
Procedimiento PL/SQL terminado correctamente.
SQL> exec DBMS_LOGMNR.add_logfile('C:\ORACLE\ORADATA\ORCL\REDO05A.LOG');
Procedimiento PL/SQL terminado correctamente.
SQL> exec DBMS_LOGMNR.add_logfile('C:\ORACLE\ORADATA\ORCL\REDO06A.LOG');
Procedimiento PL/SQL terminado correctamente.
SQL> EXECUTE DBMS_LOGMNR.START_LOGMNR(DICTFILENAME =>'c:\oraclefiles\dictionary.ora');
Procedimiento PL/SQL terminado correctamente.
SQL> set pages 100
SQL> set lines 120
SQL> column sql_redo format a50
SQL> column sql_undo format a50
SQL> select sql_redo, sql_undo from v$logmnr_contents where rownum<10;
SQL_REDO SQL_UNDO
-------------------------------------------------- --------------------------------------------------
alter session set nls_date_format = 'dd-mm-yyyy hh24:mi:ss' ;
alter session set nls_language = american ;
set lines 4000
set trimspool on
set feed off
col session_info format a40 word_wrap
col sql_redo format a90 word_wrap
col sql_undo format a90 word_wrap
begin
sys.dbms_logmnr.add_logfile ('/SCEL/data14/archives/hagc/arch_1_189771.arc',sys.dbms_logmnr.new) ;
sys.dbms_logmnr.add_logfile ('/SCEL/data14/archives/hagc/arch_1_189772.arc',sys.dbms_logmnr.addfile) ;
sys.dbms_logmnr.add_logfile ('/SCEL/data14/archives/hagc/arch_1_189773.arc',sys.dbms_logmnr.addfile) ;
end ;
/
-- Para rastrear DMLs
--
exec sys.dbms_logmnr.start_logmnr (options => sys.DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + sys.DBMS_LOGMNR.COMMITTED_DATA_ONLY -
+ SYS.DBMS_LOGMNR.PRINT_PRETTY_SQL );
--
-- Para rastrear DDLs
--
--exec sys.dbms_logmnr.start_logmnr (options => sys.DBMS_LOGMNR.DDL_DICT_TRACKING)
spool /tmp/invest.lst
set feed on
set pages 200
set lines 4000
set trimspool on
set term off
select
username,
timestamp,
session_info,
sql_redo ,
sql_undo ,
operation
from
v$logmnr_contents t
WHERE
upper (seg_owner) = 'SISCEL'
and upper (seg_name) = 'GA_SERVSUPLABO'
--or lower (seg_name) = 'bpd_planes'
-- upper (username) in ('DYRUIZGO')
-- UPPER (session_info) like '%ELIPROGS%'
--operation = 'DDL'
;
spool off
EXEC sys.DBMS_LOGMNR.END_LOGMNR
EXAMPLE 2
SQL> connect / as sysdba
Conectado.
SQL> show parameters utl
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
utl_file_dir string c:\oraclefiles
SQL> exec DBMS_LOGMNR_D.BUILD( DICTIONARY_FILENAME =>'dictionary.ora', DICTIONARY_LOCATION => 'c:\oraclefiles');
Procedimiento PL/SQL terminado correctamente.
SQL> select member from v$logfile;
MEMBER
--------------------------------------------------------------------------------
C:\ORACLE\ORADATA\ORCL\REDO04A.LOG
C:\ORACLE\ORADATA\ORCL\REDO04B.LOG
C:\ORACLE\ORADATA\ORCL\REDO05A.LOG
C:\ORACLE\ORADATA\ORCL\REDO05B.LOG
C:\ORACLE\ORADATA\ORCL\REDO06A.LOG
C:\ORACLE\ORADATA\ORCL\REDO06B.LOG
6 filas seleccionadas.
SQL> exec DBMS_LOGMNR.add_logfile('C:\ORACLE\ORADATA\ORCL\REDO04A.LOG');
Procedimiento PL/SQL terminado correctamente.
SQL> exec DBMS_LOGMNR.add_logfile('C:\ORACLE\ORADATA\ORCL\REDO05A.LOG');
Procedimiento PL/SQL terminado correctamente.
SQL> exec DBMS_LOGMNR.add_logfile('C:\ORACLE\ORADATA\ORCL\REDO06A.LOG');
Procedimiento PL/SQL terminado correctamente.
SQL> EXECUTE DBMS_LOGMNR.START_LOGMNR(DICTFILENAME =>'c:\oraclefiles\dictionary.ora');
Procedimiento PL/SQL terminado correctamente.
SQL> set pages 100
SQL> set lines 120
SQL> column sql_redo format a50
SQL> column sql_undo format a50
SQL> select sql_redo, sql_undo from v$logmnr_contents where rownum<10;
SQL_REDO SQL_UNDO
-------------------------------------------------- --------------------------------------------------
ORACLE Usuario que Ejecuto Sentencia SQL a Partir del SQL_ID
En ocasiones queremos conocer, quién fue el que ejecutó una sentencia "x" en la base de datos y no sabemos como hacerlo.
Este es un ejemplo sencillo como averiguarlo.
Nota: Cada vez que se reinicia una instancia, se pierde la información almacenada en el shared pool, por tanto, si tienes un SQL_ID de días atrás y la base de datos se reinició, no te servirá de nada este procedimiento.
Tomemos por ejemplo un SQL_ID de una sentencia cualquiera, ejecutada en la base de datos. Esto se hace consultando la vista V_$SQLTEXT:
SQL> select sql_id, sql_text from sys.V_$SQLTEXT where rownum <>
SQL_ID SQL_TEXT
------------- -------------------------------------------------------
ay9t40xq6c00t ODEGA" = :2 AND "COD_UBICACION" = :3 AND "NO_CIA" = :1
Ahora consultando en la vista V_$SQLAREA, podemos obtener la fecha que se ejecutó por primera vez:
SQL> select USERS_OPENING, FIRST_LOAD_TIME, USERS_EXECUTING, SQL_ID, ELAPSED_TIME,
2 LAST_LOAD_TIME, PROGRAM_ID from sys.V_$SQLAREA
3 where sql_id='ay9t40xq6c00t';
USERS_OPENING FIRST_LOAD_TIME USERS_EXECUTING SQL_ID ELAPSED_TIME LAST_LOAD PROGRAM_ID
------------- ------------------- --------------- ------------- ------------ --------- ----------
0 2009-10-09/16:14:22 0 ay9t40xq6c00t 0 09-OCT-09 0
Modificando la consulta anterior, podemos obtener también de la misma vista, el id, del usuario que ejecutó la sentencia:
SQL> select FIRST_LOAD_TIME,SQL_ID,PARSING_USER_ID from sys.V_$SQLAREA
2 where sql_id='ay9t40xq6c00t';
FIRST_LOAD_TIME SQL_ID PARSING_USER_ID
------------------- ------------- ---------------
2009-10-09/16:14:22 ay9t40xq6c00t 175
Finalmente, consultamos en la tabla all_users, utilizando el ID del usuario y obtenemos el username del usuario que ejecutó la sentencia.
SQL> select username, user_id, created from dba_users where user_id='175';
USERNAME USER_ID CREATED
------------------------------ ---------- ---------
LABORATORIO 175 06-APR-09
Este es un ejemplo sencillo como averiguarlo.
Nota: Cada vez que se reinicia una instancia, se pierde la información almacenada en el shared pool, por tanto, si tienes un SQL_ID de días atrás y la base de datos se reinició, no te servirá de nada este procedimiento.
Tomemos por ejemplo un SQL_ID de una sentencia cualquiera, ejecutada en la base de datos. Esto se hace consultando la vista V_$SQLTEXT:
SQL> select sql_id, sql_text from sys.V_$SQLTEXT where rownum <>
SQL_ID SQL_TEXT
------------- -------------------------------------------------------
ay9t40xq6c00t ODEGA" = :2 AND "COD_UBICACION" = :3 AND "NO_CIA" = :1
Ahora consultando en la vista V_$SQLAREA, podemos obtener la fecha que se ejecutó por primera vez:
SQL> select USERS_OPENING, FIRST_LOAD_TIME, USERS_EXECUTING, SQL_ID, ELAPSED_TIME,
2 LAST_LOAD_TIME, PROGRAM_ID from sys.V_$SQLAREA
3 where sql_id='ay9t40xq6c00t';
USERS_OPENING FIRST_LOAD_TIME USERS_EXECUTING SQL_ID ELAPSED_TIME LAST_LOAD PROGRAM_ID
------------- ------------------- --------------- ------------- ------------ --------- ----------
0 2009-10-09/16:14:22 0 ay9t40xq6c00t 0 09-OCT-09 0
Modificando la consulta anterior, podemos obtener también de la misma vista, el id, del usuario que ejecutó la sentencia:
SQL> select FIRST_LOAD_TIME,SQL_ID,PARSING_USER_ID from sys.V_$SQLAREA
2 where sql_id='ay9t40xq6c00t';
FIRST_LOAD_TIME SQL_ID PARSING_USER_ID
------------------- ------------- ---------------
2009-10-09/16:14:22 ay9t40xq6c00t 175
Finalmente, consultamos en la tabla all_users, utilizando el ID del usuario y obtenemos el username del usuario que ejecutó la sentencia.
SQL> select username, user_id, created from dba_users where user_id='175';
USERNAME USER_ID CREATED
------------------------------ ---------- ---------
LABORATORIO 175 06-APR-09
ORACLE Recompiling Invalid Schema Objects
Recompiling Invalid Schema Objects
Operations such as upgrades, patches and DDL changes can invalidate schema objects. Provided these changes don't cause compilation failures the objects will be revalidated by on-demand automatic recompilation, but this can take an unacceptable time to complete, especially where complex dependencies are present. For this reason it makes sense to recompile invalid objects in advance of user calls. It also allows you to identify if any changes have broken your code base. This article presents several methods for recompiling invalid schema objects.
Identifying Invalid Objects
The Manual Approach
Custom Script
DBMS_UTILITY.compile_schema
UTL_RECOMP
utlrp.sql and utlprp.sql
Identifying Invalid Objects
The DBA_OBJECTS view can be used to identify invalid objects using the following query:
COLUMN object_name FORMAT A30
SELECT owner,
object_type,
object_name,
status
FROM dba_objects
WHERE status = 'INVALID';
ORDER BY owner, object_type, object_name;With this information you can decide which of the following recompilation methods is suitable for you.
The Manual ApproachFor small numbers of objects you may decide that a manual recompilation is sufficient. The following example shows the compile syntax for several object types:
ALTER PACKAGE my_package COMPILE;
ALTER PACKAGE my_package COMPILE BODY;
ALTER PROCEDURE my_procedure COMPILE;
ALTER FUNCTION my_function COMPILE;
ALTER TRIGGER my_trigger COMPILE;
ALTER VIEW my_view COMPILE;Notice that the package body is compiled in the same way as the package specification, with the addition of the word "BODY" at the end of the command.
An alternative approach is to use the DBMS_DDL package to perform the recompilations:
EXEC DBMS_DDL.alter_compile('PACKAGE', 'MY_SCHEMA', 'MY_PACKAGE');
EXEC DBMS_DDL.alter_compile('PACKAGE BODY', 'MY_SCHEMA', 'MY_PACKAGE');
EXEC DBMS_DDL.alter_compile('PROCEDURE', 'MY_SCHEMA', 'MY_PROCEDURE');
EXEC DBMS_DDL.alter_compile('FUNCTION', 'MY_SCHEMA', 'MY_FUNCTION');
EXEC DBMS_DDL.alter_compile('TRIGGER', 'MY_SCHEMA', 'MY_TRIGGER');This method is limited to PL/SQL objects, so it is not applicable for views.
Script Propio.set heading off
set feedback off
spool /export/home/oracle/kdbin/recompile.lst
SELECT 'ALTER ' || OBJECT_TYPE || ' ' || OWNER || '.' || OBJECT_NAME || ' COMPILE; ' FROM DBA_OBJECTS WHERE OBJECT_TYPE NOT IN ('PACKAGE BODY') AND OWNER = 'SPE' AND STATUS = 'IN
VALID';
spool off
@/export/home/oracle/kdbin/recompile.lst
spool /export/home/oracle/kdbin/recompile.lst
SELECT 'ALTER PACKAGE ' || OWNER || '.' || OBJECT_NAME || ' COMPILE BODY; ' FROM DBA_OBJECTS WHERE OBJECT_TYPE IN ('PACKAGE BODY') AND OWNER = 'SPE' AND STATUS = 'INVALID';
spool off
spool /export/home/oracle/kdbin/recompile.lst
SELECT 'ALTER ' || OBJECT_TYPE || ' ' || OWNER || '.' || OBJECT_NAME || ' COMPILE; ' FROM DBA_OBJECTS WHERE OBJECT_TYPE NOT IN ('PACKAGE BODY') AND STATUS = 'INVALID';
spool off
@/export/home/oracle/kdbin/recompile.lst
spool /export/home/oracle/kdbin/recompile.lst
SELECT 'ALTER PACKAGE ' || OWNER || '.' || OBJECT_NAME || ' COMPILE BODY; ' FROM DBA_OBJECTS WHERE OBJECT_TYPE IN ('PACKAGE BODY') AND STATUS = 'INVALID';
spool off
@/export/home/oracle/kdbin/recompile.lst
set heading on
set feedback on
exit
Custom Script
In some situations you may have to compile many invalid objects in one go. One approach is to write a custom script to identify and compile the invalid objects. The following example identifies and recompiles invalid packages and package bodies.
SET SERVEROUTPUT ON SIZE 1000000
BEGIN
FOR cur_rec IN (SELECT owner,
object_name,
object_type,
DECODE(object_type, 'PACKAGE', 1,
'PACKAGE BODY', 2, 2) AS recompile_order
FROM dba_objects
WHERE object_type IN ('PACKAGE', 'PACKAGE BODY')
AND status != 'VALID'
ORDER BY 4)
LOOP
BEGIN
IF cur_rec.object_type = 'PACKAGE' THEN
EXECUTE IMMEDIATE 'ALTER ' || cur_rec.object_type ||
' "' || cur_rec.owner || '"."' || cur_rec.object_name || '" COMPILE';
ElSE
EXECUTE IMMEDIATE 'ALTER PACKAGE "' || cur_rec.owner ||
'"."' || cur_rec.object_name || '" COMPILE BODY';
END IF;
EXCEPTION
WHEN OTHERS THEN
DBMS_OUTPUT.put_line(cur_rec.object_type || ' : ' || cur_rec.owner ||
' : ' || cur_rec.object_name);
END;
END LOOP;
END;
/This approach is fine if you have a specific task in mind, but be aware that you may end up compiling some objects multiple times depending on the order they are compiled in. It is probably a better idea to use one of the methods provided by Oracle since they take the code dependencies into account.
DBMS_UTILITY.compile_schema
The COMPILE_SCHEMA procedure in the DBMS_UTILITY package compiles all procedures, functions, packages, and triggers in the specified schema. The example below shows how it is called from SQL*Plus:
EXEC DBMS_UTILITY.compile_schema(schema => 'SCOTT');UTL_RECOMP
The UTL_RECOMP package contains two procedures used to recompile invalid objects. As the names suggest, the RECOMP_SERIAL procedure recompiles all the invalid objects one at a time, while the RECOMP_PARALLEL procedure performs the same task in parallel using the specified number of threads. Their definitions are listed below:
PROCEDURE RECOMP_SERIAL(
schema IN VARCHAR2 DEFAULT NULL,
flags IN PLS_INTEGER DEFAULT 0);
PROCEDURE RECOMP_PARALLEL(
threads IN PLS_INTEGER DEFAULT NULL,
schema IN VARCHAR2 DEFAULT NULL,
flags IN PLS_INTEGER DEFAULT 0);The usage notes for the parameters are listed below:
schema - The schema whose invalid objects are to be recompiled. If NULL all invalid objects in the database are recompiled.
threads - The number of threads used in a parallel operation. If NULL the value of the "job_queue_processes" parameter is used. Matching the number of available CPUs is generally a good starting point for this value.
flags - Used for internal diagnostics and testing only.
The following examples show how these procedures care used:
-- Schema level.
EXEC UTL_RECOMP.recomp_serial('SCOTT');
EXEC UTL_RECOMP.recomp_parallel(4, 'SCOTT');
-- Database level.
EXEC UTL_RECOMP.recomp_serial();
EXEC UTL_RECOMP.recomp_parallel(4);
-- Using job_queue_processes value.
EXEC UTL_RECOMP.recomp_parallel();
EXEC UTL_RECOMP.recomp_parallel(NULL, 'SCOTT');There are a number of restrictions associated with the use of this package including:
Parallel execution is perfomed using the job queue. All existing jobs are marked as disabled until the operation is complete.
The package must be run from SQL*Plus as the SYS user, or another user with SYSDBA.
The package expects the STANDARD, DBMS_STANDARD, DBMS_JOB and DBMS_RANDOM to be present and valid.
Runnig DDL operations at the same time as this package may result in deadlocks.
utlrp.sql and utlprp.sql
The utlrp.sql and utlprp.sql scripts are provided by Oracle to recompile all invalid objects in the database. They are typically run after major database changes such as upgrades or patches. They are located in the $ORACLE_HOME/rdbms/admin directory and provide a wrapper on the UTL_RECOMP package. The utlrp.sql script simply calls the utlprp.sql script with a command line parameter of "0". The utlprp.sql accepts a single integer parameter that indicates the level of parallelism as follows:
0 - The level of parallelism is derived based on the CPU_COUNT parameter.
1 - The recompilation is run serially, one object at a time.
N - The recompilation is run in parallel with "N" number of threads.
Both scripts must be run as the SYS user, or another user with SYSDBA, to work correctly.
For further information see:
DBMS_UTILITY.compile_schema
UTL_RECOMP
Operations such as upgrades, patches and DDL changes can invalidate schema objects. Provided these changes don't cause compilation failures the objects will be revalidated by on-demand automatic recompilation, but this can take an unacceptable time to complete, especially where complex dependencies are present. For this reason it makes sense to recompile invalid objects in advance of user calls. It also allows you to identify if any changes have broken your code base. This article presents several methods for recompiling invalid schema objects.
Identifying Invalid Objects
The Manual Approach
Custom Script
DBMS_UTILITY.compile_schema
UTL_RECOMP
utlrp.sql and utlprp.sql
Identifying Invalid Objects
The DBA_OBJECTS view can be used to identify invalid objects using the following query:
COLUMN object_name FORMAT A30
SELECT owner,
object_type,
object_name,
status
FROM dba_objects
WHERE status = 'INVALID';
ORDER BY owner, object_type, object_name;With this information you can decide which of the following recompilation methods is suitable for you.
The Manual ApproachFor small numbers of objects you may decide that a manual recompilation is sufficient. The following example shows the compile syntax for several object types:
ALTER PACKAGE my_package COMPILE;
ALTER PACKAGE my_package COMPILE BODY;
ALTER PROCEDURE my_procedure COMPILE;
ALTER FUNCTION my_function COMPILE;
ALTER TRIGGER my_trigger COMPILE;
ALTER VIEW my_view COMPILE;Notice that the package body is compiled in the same way as the package specification, with the addition of the word "BODY" at the end of the command.
An alternative approach is to use the DBMS_DDL package to perform the recompilations:
EXEC DBMS_DDL.alter_compile('PACKAGE', 'MY_SCHEMA', 'MY_PACKAGE');
EXEC DBMS_DDL.alter_compile('PACKAGE BODY', 'MY_SCHEMA', 'MY_PACKAGE');
EXEC DBMS_DDL.alter_compile('PROCEDURE', 'MY_SCHEMA', 'MY_PROCEDURE');
EXEC DBMS_DDL.alter_compile('FUNCTION', 'MY_SCHEMA', 'MY_FUNCTION');
EXEC DBMS_DDL.alter_compile('TRIGGER', 'MY_SCHEMA', 'MY_TRIGGER');This method is limited to PL/SQL objects, so it is not applicable for views.
Script Propio.set heading off
set feedback off
spool /export/home/oracle/kdbin/recompile.lst
SELECT 'ALTER ' || OBJECT_TYPE || ' ' || OWNER || '.' || OBJECT_NAME || ' COMPILE; ' FROM DBA_OBJECTS WHERE OBJECT_TYPE NOT IN ('PACKAGE BODY') AND OWNER = 'SPE' AND STATUS = 'IN
VALID';
spool off
@/export/home/oracle/kdbin/recompile.lst
spool /export/home/oracle/kdbin/recompile.lst
SELECT 'ALTER PACKAGE ' || OWNER || '.' || OBJECT_NAME || ' COMPILE BODY; ' FROM DBA_OBJECTS WHERE OBJECT_TYPE IN ('PACKAGE BODY') AND OWNER = 'SPE' AND STATUS = 'INVALID';
spool off
spool /export/home/oracle/kdbin/recompile.lst
SELECT 'ALTER ' || OBJECT_TYPE || ' ' || OWNER || '.' || OBJECT_NAME || ' COMPILE; ' FROM DBA_OBJECTS WHERE OBJECT_TYPE NOT IN ('PACKAGE BODY') AND STATUS = 'INVALID';
spool off
@/export/home/oracle/kdbin/recompile.lst
spool /export/home/oracle/kdbin/recompile.lst
SELECT 'ALTER PACKAGE ' || OWNER || '.' || OBJECT_NAME || ' COMPILE BODY; ' FROM DBA_OBJECTS WHERE OBJECT_TYPE IN ('PACKAGE BODY') AND STATUS = 'INVALID';
spool off
@/export/home/oracle/kdbin/recompile.lst
set heading on
set feedback on
exit
Custom Script
In some situations you may have to compile many invalid objects in one go. One approach is to write a custom script to identify and compile the invalid objects. The following example identifies and recompiles invalid packages and package bodies.
SET SERVEROUTPUT ON SIZE 1000000
BEGIN
FOR cur_rec IN (SELECT owner,
object_name,
object_type,
DECODE(object_type, 'PACKAGE', 1,
'PACKAGE BODY', 2, 2) AS recompile_order
FROM dba_objects
WHERE object_type IN ('PACKAGE', 'PACKAGE BODY')
AND status != 'VALID'
ORDER BY 4)
LOOP
BEGIN
IF cur_rec.object_type = 'PACKAGE' THEN
EXECUTE IMMEDIATE 'ALTER ' || cur_rec.object_type ||
' "' || cur_rec.owner || '"."' || cur_rec.object_name || '" COMPILE';
ElSE
EXECUTE IMMEDIATE 'ALTER PACKAGE "' || cur_rec.owner ||
'"."' || cur_rec.object_name || '" COMPILE BODY';
END IF;
EXCEPTION
WHEN OTHERS THEN
DBMS_OUTPUT.put_line(cur_rec.object_type || ' : ' || cur_rec.owner ||
' : ' || cur_rec.object_name);
END;
END LOOP;
END;
/This approach is fine if you have a specific task in mind, but be aware that you may end up compiling some objects multiple times depending on the order they are compiled in. It is probably a better idea to use one of the methods provided by Oracle since they take the code dependencies into account.
DBMS_UTILITY.compile_schema
The COMPILE_SCHEMA procedure in the DBMS_UTILITY package compiles all procedures, functions, packages, and triggers in the specified schema. The example below shows how it is called from SQL*Plus:
EXEC DBMS_UTILITY.compile_schema(schema => 'SCOTT');UTL_RECOMP
The UTL_RECOMP package contains two procedures used to recompile invalid objects. As the names suggest, the RECOMP_SERIAL procedure recompiles all the invalid objects one at a time, while the RECOMP_PARALLEL procedure performs the same task in parallel using the specified number of threads. Their definitions are listed below:
PROCEDURE RECOMP_SERIAL(
schema IN VARCHAR2 DEFAULT NULL,
flags IN PLS_INTEGER DEFAULT 0);
PROCEDURE RECOMP_PARALLEL(
threads IN PLS_INTEGER DEFAULT NULL,
schema IN VARCHAR2 DEFAULT NULL,
flags IN PLS_INTEGER DEFAULT 0);The usage notes for the parameters are listed below:
schema - The schema whose invalid objects are to be recompiled. If NULL all invalid objects in the database are recompiled.
threads - The number of threads used in a parallel operation. If NULL the value of the "job_queue_processes" parameter is used. Matching the number of available CPUs is generally a good starting point for this value.
flags - Used for internal diagnostics and testing only.
The following examples show how these procedures care used:
-- Schema level.
EXEC UTL_RECOMP.recomp_serial('SCOTT');
EXEC UTL_RECOMP.recomp_parallel(4, 'SCOTT');
-- Database level.
EXEC UTL_RECOMP.recomp_serial();
EXEC UTL_RECOMP.recomp_parallel(4);
-- Using job_queue_processes value.
EXEC UTL_RECOMP.recomp_parallel();
EXEC UTL_RECOMP.recomp_parallel(NULL, 'SCOTT');There are a number of restrictions associated with the use of this package including:
Parallel execution is perfomed using the job queue. All existing jobs are marked as disabled until the operation is complete.
The package must be run from SQL*Plus as the SYS user, or another user with SYSDBA.
The package expects the STANDARD, DBMS_STANDARD, DBMS_JOB and DBMS_RANDOM to be present and valid.
Runnig DDL operations at the same time as this package may result in deadlocks.
utlrp.sql and utlprp.sql
The utlrp.sql and utlprp.sql scripts are provided by Oracle to recompile all invalid objects in the database. They are typically run after major database changes such as upgrades or patches. They are located in the $ORACLE_HOME/rdbms/admin directory and provide a wrapper on the UTL_RECOMP package. The utlrp.sql script simply calls the utlprp.sql script with a command line parameter of "0". The utlprp.sql accepts a single integer parameter that indicates the level of parallelism as follows:
0 - The level of parallelism is derived based on the CPU_COUNT parameter.
1 - The recompilation is run serially, one object at a time.
N - The recompilation is run in parallel with "N" number of threads.
Both scripts must be run as the SYS user, or another user with SYSDBA, to work correctly.
For further information see:
DBMS_UTILITY.compile_schema
UTL_RECOMP
ORACLE Renaming or Moving Oracle Files
Renaming or Moving Oracle Files
Controlfiles
Logfiles
Datafiles
Recreating the Controlfile
Controlfiles
The current location of the controlfiles can be queried from the V$CONTROLFILE view, as shown below.
SQL> select name from v$controlfile;
NAME
-------------------------------------------------------------
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\CONTROL01.CTL
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\CONTROL02.CTL
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\CONTROL03.CTL
3 rows selected.
SQL>In order to rename or move these files we must alter the value of the control_files instance parameter.
SQL> show parameter control_files
NAME TYPE VALUE
------------------------------------ -------------------------------- ------------------------------
control_files string C:\ORACLE\ORADATA\DB10G\CONTRO
L01.CTL, C:\ORACLE\ORADATA\DB1
0G\CONTROL02.CTL, C:\ORACLE\OR
ADATA\DB10G\CONTROL03.CTL
SQL>To move or rename a controlfile do the following:
Alter the control_files parameter using the ALTER SYSTEM comamnd.
Shutdown the database.
Rename the physical file on the OS.
Start the database.
The following SQL*Plus output shows how this is done for an instance using an spfile. For instances using a pfile replace the spfile manipulation steps with an amendment of the parameter in the init.ora file.
SQL> ALTER SYSTEM SET control_files='C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\RENAME_CONTROL01.CTL', -
> 'C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\CONTROL02.CTL', -
> 'C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\CONTROL03.CTL' SCOPE=SPFILE;
System altered.
SQL> SHUTDOWN IMMEDIATE
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> HOST MOVE C:\ORACLE\ORADATA\DB10G\CONTROL01.CTL C:\ORACLE\ORADATA\DB10G\RENAME_CONTROL01.CTL
SQL> STARTUP
ORACLE instance started.
Total System Global Area 167772160 bytes
Fixed Size 787968 bytes
Variable Size 61864448 bytes
Database Buffers 104857600 bytes
Redo Buffers 262144 bytes
Database mounted.
SQL>Repeating the initial query shows that the the controlfile has been renamed in the data dictionary.
SQL> select name from v$controlfile;
NAME
-------------------------------------------------------------
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\RENAME_CONTROL01.CTL
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\CONTROL02.CTL
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\CONTROL03.CTL
3 rows selected.
SQL>Logfiles
The current location of the logfiles can be queried from the V$LOGFILE view, as shown below.
SQL> SELECT member FROM v$logfile;
MEMBER
-------------------------------------------------
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\REDO03.LOG
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\REDO02.LOG
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\REDO01.LOG
3 rows selected.
SQL>To move or rename a logfile do the following:
Shutdown the database.
Rename the physical file on the OS.
Start the database in mount mode.
Issue the ALTER DATABASE RENAME FILE command to rename the file within the Oracle dictionary.
Open the database.
The following SQL*Plus output shows how this is done.
SQL> SHUTDOWN IMMEDIATE
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> HOST MOVE C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\REDO01.LOG C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\RENAME_REDO01.LOG
SQL> STARTUP MOUNT
ORACLE instance started.
Total System Global Area 167772160 bytes
Fixed Size 787968 bytes
Variable Size 61864448 bytes
Database Buffers 104857600 bytes
Redo Buffers 262144 bytes
Database mounted.
SQL> ALTER DATABASE RENAME FILE 'C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\REDO01.LOG' -
> TO 'C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\RENAME_REDO01.LOG';
Database altered.
SQL> ALTER DATABASE OPEN;
Database altered.
SQL>Repeating the initial query shows that the the logfile has been renamed in the data dictionary.
SQL> SELECT member FROM v$logfile;
MEMBER
-------------------------------------------------
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\REDO03.LOG
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\REDO02.LOG
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\RENAME_REDO01.LOG
3 rows selected.
SQL>Datafiles
The process for renaming a datafile is the same as renaming a logfile, but for the same of clarity it is repeated below. The current location of the datafiles can be queried from the V$DATAFILE view, as shown below.
SQL> SELECT name FROM v$datafile;
NAME
---------------------------------------------------------
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\SYSTEM01.DBF
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\UNDOTBS01.DBF
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\SYSAUX01.DBF
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\USERS01.DBF
4 rows selected.
SQL>To move or rename a datafile do the following:
Shutdown the database.
Rename the physical file on the OS.
Start the database in mount mode.
Issue the ALTER DATABASE RENAME FILE command to rename the file within the Oracle dictionary.
Open the database.
The following SQL*Plus output shows how this is done.
SQL> SHUTDOWN IMMEDIATE
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> HOST MOVE C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\USERS01.DBF C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\RENAME_USERS01.DBF
SQL> STARTUP MOUNT
ORACLE instance started.
Total System Global Area 167772160 bytes
Fixed Size 787968 bytes
Variable Size 61864448 bytes
Database Buffers 104857600 bytes
Redo Buffers 262144 bytes
Database mounted.
SQL> ALTER DATABASE RENAME FILE 'C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\USERS01.DBF' -
> TO 'C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\RENAME_USERS01.DBF';
Database altered.
SQL> ALTER DATABASE OPEN;
Database altered.
SQL>Repeating the initial query shows that the the datafile has been renamed in the data dictionary.
SQL> SELECT name FROM v$datafile;
NAME
---------------------------------------------------------
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\SYSTEM01.DBF
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\UNDOTBS01.DBF
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\SYSAUX01.DBF
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\RENAME_USERS01.DBF
4 rows selected.
SQL>Recreating the Controlfile
For largescale rearrangements it may be easier to manipulate the controlfile contents manually by backing up the controlfile to trace.
SQL> CONN sys/password AS SYSDBA
Connected.
SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
Database altered.
SQL>The resulting trace file in the user_dump_dest directory contains commands and instructions for recreating the controlfile. The paths in the CREATE CONTROLFILE command can be manipulated to rename all datafiles and logfiles on one step.
Controlfiles
Logfiles
Datafiles
Recreating the Controlfile
Controlfiles
The current location of the controlfiles can be queried from the V$CONTROLFILE view, as shown below.
SQL> select name from v$controlfile;
NAME
-------------------------------------------------------------
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\CONTROL01.CTL
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\CONTROL02.CTL
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\CONTROL03.CTL
3 rows selected.
SQL>In order to rename or move these files we must alter the value of the control_files instance parameter.
SQL> show parameter control_files
NAME TYPE VALUE
------------------------------------ -------------------------------- ------------------------------
control_files string C:\ORACLE\ORADATA\DB10G\CONTRO
L01.CTL, C:\ORACLE\ORADATA\DB1
0G\CONTROL02.CTL, C:\ORACLE\OR
ADATA\DB10G\CONTROL03.CTL
SQL>To move or rename a controlfile do the following:
Alter the control_files parameter using the ALTER SYSTEM comamnd.
Shutdown the database.
Rename the physical file on the OS.
Start the database.
The following SQL*Plus output shows how this is done for an instance using an spfile. For instances using a pfile replace the spfile manipulation steps with an amendment of the parameter in the init.ora file.
SQL> ALTER SYSTEM SET control_files='C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\RENAME_CONTROL01.CTL', -
> 'C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\CONTROL02.CTL', -
> 'C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\CONTROL03.CTL' SCOPE=SPFILE;
System altered.
SQL> SHUTDOWN IMMEDIATE
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> HOST MOVE C:\ORACLE\ORADATA\DB10G\CONTROL01.CTL C:\ORACLE\ORADATA\DB10G\RENAME_CONTROL01.CTL
SQL> STARTUP
ORACLE instance started.
Total System Global Area 167772160 bytes
Fixed Size 787968 bytes
Variable Size 61864448 bytes
Database Buffers 104857600 bytes
Redo Buffers 262144 bytes
Database mounted.
SQL>Repeating the initial query shows that the the controlfile has been renamed in the data dictionary.
SQL> select name from v$controlfile;
NAME
-------------------------------------------------------------
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\RENAME_CONTROL01.CTL
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\CONTROL02.CTL
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\CONTROL03.CTL
3 rows selected.
SQL>Logfiles
The current location of the logfiles can be queried from the V$LOGFILE view, as shown below.
SQL> SELECT member FROM v$logfile;
MEMBER
-------------------------------------------------
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\REDO03.LOG
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\REDO02.LOG
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\REDO01.LOG
3 rows selected.
SQL>To move or rename a logfile do the following:
Shutdown the database.
Rename the physical file on the OS.
Start the database in mount mode.
Issue the ALTER DATABASE RENAME FILE command to rename the file within the Oracle dictionary.
Open the database.
The following SQL*Plus output shows how this is done.
SQL> SHUTDOWN IMMEDIATE
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> HOST MOVE C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\REDO01.LOG C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\RENAME_REDO01.LOG
SQL> STARTUP MOUNT
ORACLE instance started.
Total System Global Area 167772160 bytes
Fixed Size 787968 bytes
Variable Size 61864448 bytes
Database Buffers 104857600 bytes
Redo Buffers 262144 bytes
Database mounted.
SQL> ALTER DATABASE RENAME FILE 'C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\REDO01.LOG' -
> TO 'C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\RENAME_REDO01.LOG';
Database altered.
SQL> ALTER DATABASE OPEN;
Database altered.
SQL>Repeating the initial query shows that the the logfile has been renamed in the data dictionary.
SQL> SELECT member FROM v$logfile;
MEMBER
-------------------------------------------------
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\REDO03.LOG
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\REDO02.LOG
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\RENAME_REDO01.LOG
3 rows selected.
SQL>Datafiles
The process for renaming a datafile is the same as renaming a logfile, but for the same of clarity it is repeated below. The current location of the datafiles can be queried from the V$DATAFILE view, as shown below.
SQL> SELECT name FROM v$datafile;
NAME
---------------------------------------------------------
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\SYSTEM01.DBF
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\UNDOTBS01.DBF
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\SYSAUX01.DBF
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\USERS01.DBF
4 rows selected.
SQL>To move or rename a datafile do the following:
Shutdown the database.
Rename the physical file on the OS.
Start the database in mount mode.
Issue the ALTER DATABASE RENAME FILE command to rename the file within the Oracle dictionary.
Open the database.
The following SQL*Plus output shows how this is done.
SQL> SHUTDOWN IMMEDIATE
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> HOST MOVE C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\USERS01.DBF C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\RENAME_USERS01.DBF
SQL> STARTUP MOUNT
ORACLE instance started.
Total System Global Area 167772160 bytes
Fixed Size 787968 bytes
Variable Size 61864448 bytes
Database Buffers 104857600 bytes
Redo Buffers 262144 bytes
Database mounted.
SQL> ALTER DATABASE RENAME FILE 'C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\USERS01.DBF' -
> TO 'C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\RENAME_USERS01.DBF';
Database altered.
SQL> ALTER DATABASE OPEN;
Database altered.
SQL>Repeating the initial query shows that the the datafile has been renamed in the data dictionary.
SQL> SELECT name FROM v$datafile;
NAME
---------------------------------------------------------
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\SYSTEM01.DBF
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\UNDOTBS01.DBF
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\SYSAUX01.DBF
C:\ORACLE\PRODUCT\10.1.0\ORADATA\DB10G\RENAME_USERS01.DBF
4 rows selected.
SQL>Recreating the Controlfile
For largescale rearrangements it may be easier to manipulate the controlfile contents manually by backing up the controlfile to trace.
SQL> CONN sys/password AS SYSDBA
Connected.
SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
Database altered.
SQL>The resulting trace file in the user_dump_dest directory contains commands and instructions for recreating the controlfile. The paths in the CREATE CONTROLFILE command can be manipulated to rename all datafiles and logfiles on one step.
Suscribirse a:
Entradas (Atom)
