Showing posts with label oracle. Show all posts
Showing posts with label oracle. Show all posts

Tuesday, June 24, 2008

Recompiling Invalid Schema Objects

I copied the following articles from http://www.oracle-base.com/articles/misc/RecompilingInvalidSchemaObjects.php
========================

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 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 Approach

For 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.

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:
Hope this helps. Regards Tim...

oracle imp/exp

These tools are used to transfer data from one oracle database to another oracle database. You Export tool to export data from source database, and Import tool to load data into the target database. When you export tables from source database export tool will extracts the tables and puts it into the dump file. This dump file is transferred to the target database. At the target database the Import tool will copy the data from dump file to the target database.

From Ver. 10g Oracle is recommending to use Data Pump Export and Import tools, which are enhanced versions of original Export and Import tools.

The export dump file contains objects in the following order:

  1. Type definitions
  2. Table definitions
  3. Table data
  4. Table indexes
  5. Integrity constraints, views, procedures, and triggers
  6. Bitmap, function-based, and domain indexes


When you import the tables the import tool will perform the actions in the following order, new tables are created, data is imported and indexes are built, triggers are imported, integrity constraints are enabled on the new tables, and any bitmap, function-based, and/or domain indexes are built. This sequence prevents data from being rejected due to the order in which tables are imported. This sequence also prevents redundant triggers from firing twice on the same data

Invoking Export and Import

You can run Export and Import tool in two modes

Command Line Mode

Interactive Mode

When you just type exp or imp at o/s prompt it will run in interactive mode i.e. these tools will prompt you for all the necessary input. If you supply command line arguments when calling exp or imp then it will run in command line mode

Command Line Parameters of Export tool

You can control how Export runs by entering the EXP command followed
by various arguments. To specify parameters, you use keywords:

Format: EXP KEYWORD=value or KEYWORD=(value1,value2,...,valueN)

Example: EXP SCOTT/TIGER GRANTS=Y TABLES=(EMP,DEPT,MGR)

or TABLES=(T1:P1,T1:P2), if T1 is partitioned table

Keyword Description (Default)

--------------------------------------------------------------

USERID username/password

BUFFER size of data buffer

FILE output files (EXPDAT.DMP)

COMPRESS import into one extent (Y)

GRANTS export grants (Y)

INDEXES export indexes (Y)

DIRECT direct path (N)

LOG log file of screen output

ROWS export data rows (Y)

CONSISTENT cross-table consistency(N)

FULL export entire file (N)

OWNER list of owner usernames

TABLES list of table names

RECORDLENGTH length of IO record

INCTYPE incremental export type

RECORD track incr. export (Y)

TRIGGERS export triggers (Y)

STATISTICS analyze objects (ESTIMATE)

PARFILE parameter filename

CONSTRAINTS export constraints (Y)
OBJECT_CONSISTENT transaction set to read only during object export (N)

FEEDBACK display progress every x rows (0)

FILESIZE maximum size of each dump file

FLASHBACK_SCN SCN used to set session snapshot back to

FLASHBACK_TIME time used to get the SCN closest to the specified time

QUERY select clause used to export a subset of a table

RESUMABLE suspend when a space related error is encountered(N)

RESUMABLE_NAME text string used to identify resumable statement

RESUMABLE_TIMEOUT wait time for RESUMABLE

TTS_FULL_CHECK perform full or partial dependency check for TTS

TABLESPACES list of tablespaces to export

TRANSPORT_TABLESPACE export transportable tablespace metadata (N)

TEMPLATE template name which invokes iAS mode export


The Export and Import tools support four modes of operation

FULL :Exports all the objects in all schemas
OWNER :Exports objects only belonging to the given OWNER
TABLES :Exports Individual Tables
TABLESPACE :Export all objects located in a given TABLESPACE.

Example of Exporting Full Database

The following example shows how to export full database

$exp USERID=scott/tiger FULL=y FILE=myfull.dmp

In the above command, FILE option specifies the name of the dump file, FULL option specifies that you want to export the full database, USERID option specifies the user account to connect to the database. Note, to perform full export the user should have DBA or EXP_FULL_DATABASE privilege.

Example of Exporting Schemas

To export Objects stored in a particular schemas you can run export utility with the following arguments

$exp USERID=scott/tiger OWNER=(SCOTT,ALI) FILE=exp_own.dmp

The above command will export all the objects stored in SCOTT and ALI’s schema.

Exporting Individual Tables

To export individual tables give the following command

$exp USERID=scott/tiger TABLES=(scott.emp,scott.sales) FILE=exp_tab.dmp

This will export scott’s emp and sales tables.

Exporting Consistent Image of the tables

If you include CONSISTENT=Y option in export command argument then, Export utility will export a consistent image of the table i.e. the changes which are done to the table during export operation will not be exported.

Using Import Utility

Objects exported by export utility can only be imported by Import utility. Import utility can run in Interactive mode or command line mode.

You can let Import prompt you for parameters by entering the IMP command followed by your username/password:

Example: IMP SCOTT/TIGER

Or, you can control how Import runs by entering the IMP command followed

by various arguments. To specify parameters, you use keywords:

Format: IMP KEYWORD=value or KEYWORD=(value1,value2,...,valueN)

Example: IMP SCOTT/TIGER IGNORE=Y TABLES=(EMP,DEPT) FULL=N

or TABLES=(T1:P1,T1:P2), if T1 is partitioned table

USERID must be the first parameter on the command line.

Keyword

Description (Default)

USERID

username/password

BUFFER

size of data buffer

FILE

input files (EXPDAT.DMP)

SHOW

just list file contents (N)

IGNORE

ignore create errors (N)

GRANTS

import grants (Y)

INDEXES

import indexes (Y)

ROWS

import data rows (Y)

LOG

log file of screen output

FULL

import entire file (N)

FROMUSER

list of owner usernames

TOUSER

list of usernames

TABLES

list of table names

RECORDLENGTH

length of IO record

INCTYPE

incremental import type

COMMIT

commit array insert (N)

PARFILE

parameter filename

CONSTRAINTS

import constraints (Y)

DESTROY

overwrite tablespace data file (N)

INDEXFILE

write table/index info to specified file

SKIP_UNUSABLE_INDEXES

skip maintenance of unusable indexes (N)

FEEDBACK

display progress every x rows(0)

TOID_NOVALIDATE

skip validation of specified type ids

FILESIZE

maximum size of each dump file

STATISTICS

import precomputed statistics (always)

RESUMABLE

suspend when a space related error is encountered(N)

RESUMABLE_NAME

text string used to identify resumable statement

RESUMABLE_TIMEOUT

wait time for RESUMABLE

COMPILE

compile procedures, packages, and functions (Y)

STREAMS_CONFIGURATION

import streams general metadata (Y)

STREAMS_INSTANITATION

import streams instantiation metadata (N)

Example Importing Individual Tables

To import individual tables from a full database export dump file give the following command

$imp scott/tiger FILE=myfullexp.dmp FROMUSER=scott TABLES=(emp,dept)

This command will import only emp, dept tables into Scott user and you will get a output similar to as shown below

Export file created by EXPORT:V10.00.00 via conventional path

import done in WE8DEC character set and AL16UTF16 NCHAR character set

. importing SCOTT's objects into SCOTT

. . importing table "DEPT" 4 rows imported

. . importing table "EMP" 14 rows imported

Import terminated successfully without warnings.

Example, Importing Tables of One User account into another User account

For example, suppose Ali has exported tables into a dump file mytables.dmp. Now Scott wants to import these tables. To achieve this Scott will give the following import command

$imp scott/tiger FILE=mytables.dmp FROMUSER=ali TOUSER=scott

Then import utility will give a warning that tables in the dump file was exported by user Ali and not you and then proceed.

Example Importing Tables Using Pattern Matching

Suppose you want to import all tables from a dump file whose name matches a particular pattern. To do so, use “%” wild character in TABLES option. For example, the following command will import all tables whose names starts with alphabet “e” and those tables whose name contains alphabet “d”

$imp scott/tiger FILE=myfullexp.dmp FROMUSER=scott TABLES=(a%,%d%)

Migrating a Database across platforms.

The Export and Import utilities are the only method that Oracle supports for moving an existing Oracle database from one hardware platform to another. This includes moving between UNIX and NT systems and also moving between two NT systems running on different platforms.

The following steps present a general overview of how to move a database between platforms.

  1. As a DBA user, issue the following SQL query to get the exact name of all tablespaces. You will need this information later in the process.

SQL> SELECT tablespace_name FROM dba_tablespaces;

  1. As a DBA user, perform a full export from the source database, for example:

> exp system/manager FULL=y FILE=myfullexp.dmp

  1. Move the dump file to the target database server. If you use FTP, be sure to copy it in binary format (by entering binary at the FTP prompt) to avoid file corruption.
  2. Create a database on the target server.
  3. Before importing the dump file, you must first create your tablespaces, using the information obtained in Step 1. Otherwise, the import will create the corresponding datafiles in the same file structure as at the source database, which may not be compatible with the file structure on the target system.
  4. As a DBA user, perform a full import with the IGNORE parameter enabled:

> imp system/manager FULL=y IGNORE=y FILE=myfullexp.dmp

Using IGNORE=y instructs Oracle to ignore any creation errors during the import and permit the import to complete.

Perform a full backup of your new database.

Monday, June 23, 2008

oracle的视图

必须意识到,操作系统的许多方面可以从数据库内部进行监视和修改。可以使用 Oracle 的固定视图(带 v$ 前缀的视图)确定计算机的主机名 (v$instance) 或数据库正在其中运行的平台的名称 (v$database) 。还可以通过这种方式确定与数据库相关的文件的位置和其他属性。可以直接从数据库中查询数据文件( v$datafile 、 dba_data_files )、临时文件( v$tempfile 、 dba_temp_files )、重做日志 (v$logfile) 、存档日志 (v$archived_log) 和控制文件 (v$controlfile) 的位置和其他属性。可以通过该视图以及通过查看某些 init.ora 参数( db_recovery_file_dest 、 db_recovery_file_dest_size )确定有关闪回恢复区 ($recovery_file_dest) 的信息。还可以查询进程 (v$process) 和内存( v$sga 、 v$sgastat 等)的状态。有各种内置的 PL/SQL 程序包,并能够创建允许对底层 OS 进行其他访问的 Java 和 C 数据库对象。

oracle data dictionary

select * from v$database;
select * from v$instance;
select * from v$version;

view oracle license

select * from v$license;

oracle automatic memory management

Note that after resetting various parameters I played with I realized that finally Oracle has implemented the human-friendly way for resetting parameters in SPFILE:
Sys@Lin11g> alter system reset pga_aggregate_target;  

System altered.

Sys@Lin11g> alter system reset sga_target;

System altered.

…no scope=spfile sid=’*’ is needed. This resets the parameter in spfile only, the values in memory persist.

Sunday, June 22, 2008

procedures,functions,packages

select object_name from dba_objects where owner='jephe' and object_type='PROCEDURE';
note: select all procedures from jephe tablespace.

generate 'create or replace public synonym' statement after export oracle database

SELECT 'CREATE or replace PUBLIC SYNONYM ' || synonym_name || ' FOR '|| table_owner || '.' || table_name || ';' cmd FROM dba_synonyms WHERE TABLE_OWNER in ('A','B','C') and owner='PUBLIC';

display oracle timezone

select dbtimezone from dual;

oracle object dependencies

SQL> select name,referenced_name,referenced_type from sys.dba_dependencies where owner='salary' and name='tablename';
==> inside schema 'jephe', which are the objects table 'tablename' depends on? List name,referenced_name,referenced_type


SQL> select name,type,referenced_type from sys.dba_dependencies where owner='C_UAT' and referenced_name='REPORT_MAP';
==> list which are the objects that refers to object 'REPORT_MAP'.

Saturday, June 21, 2008

synonym

select * from dba_synonyms where table_name='name';

switch from sysdba to another user without password

SQL> CONNECT / as sysdba
Connected.

SQL> SELECT password FROM dba_users WHERE username='SCOTT';
PASSWORD
--------------- ---------------
F894844C34402B67

in 11g, the password won't display anymore, instead, use this:

SQL> select name,password from sys.user$ where name='SCOTT';
SQL> ALTER USER scott IDENTIFIED BY anything;
User altered.

SQL> CONNECT scott/anything
Connected.

OK, we're in. Let's quickly change the password back before anybody notices.

SQL> ALTER USER scott IDENTIFIED BY VALUES 'F894844C34402B67';
User altered.

Friday, June 20, 2008

Renaming or Moving Oracle Files

I copied this article from http://www.oracle-base.com/articles/misc/RenamingOrMovingOracleFiles.php

================

This article presents a brief explanation of how assorted Oracle files can be renamed or moved to a new location. The examples are based on a default Oracle 10g installation on Windows, but the method is the same for different versions of Oracle on any platform, with the exception of the host command used to rename the file.

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.

This is quite a drastic step and it may affect the usefulness of existing backups, especially if the controlfile is being used as the recovery catlog.

For further information see:
Hope this helps. Regards Tim...

database startup process

Actually, it's a 3 step process for Oracle startup:

startup nomount;
alter database mount;
alter database open;

If you use automatic script to startup Oracle DB, then user cannot connect, the error message is :ERROR: ORA-01033: ORACLE initialization or shutdown in progress:

then you need to use 3 steps to startup to see which step got problem:

Wednesday, June 18, 2008

Tuesday, June 17, 2008

Oracle DBA必须了解得网站列表

(http: //www.peasland.net)开始。下面是一些Oracle DBA必须了解得网站列表:

  Ask Tom – http://asktom.oracle.com

  Jonathan Lewis web site - http://www.jlcomp.demon.co.uk/

  Ixora (Steve Adams) – http://www.ixora.com.au

  Orapub – http://www.orapub.com

  Metalink (Oracle支持网站) – http://metalink.oracle.com

   国内的:

   ITPUB论坛 - http://www.itpub.net

   Oracle技术网 - http://www.oradb.net

  还有许多其它的好网站。

Monday, June 16, 2008

Resizing Temporary Tablespace

by Jeff Hunter, Sr. Database Administrator


Contents

  1. Overview
  2. Dropping / Recreating Temporary Tablespace Method
  3. Drop Tempfile Command Method - (Oracle9i and higher)



Overview

In many database configurations, the DBA will choose to allow their temporary tablespace (actually the tempfile(s) for the temporary tablespace) to autoextend. A runaway query or sort can easily chew up valuable space on the disk as the tempfiles(s) extends to accommodate the request for space. If the increase in size of the temporary tablespace (the tempfiles) gets exceedingly large because of a particular anomaly, the DBA will often want to resize the temporary tablespace to a more reasonable size in order to reclaim that extra space. The obvious action would be to resize the tempfiles using the following statement:
SQL> alter database tempfile '/u02/oradata/TESTDB/temp01.dbf' resize 250M;
alter database tempfile '/u02/oradata/TESTDB/temp01.dbf' resize 250M
*
ERROR at line 1:
ORA-03297: file contains used data beyond requested RESIZE value
Ouch. You next bounce the database and attempt the same statement only to be greeted with the same error!

Several methods exist to reclaim the used space used for a larger than normal temporary tablespace depending on which release of Oracle you are running. The method that exists for all releases of Oracle is to simply drop and recreate the temporary tablespace back to its original (or another reasonable) size. If you are using Oracle9i or higher, you can apply another method which is to drop the large tempfile (which will drop the tempfile from the data dictionary AND the O/S file system) using the alter database tempfile '' drop including datafiles; command. Each method is explained below.



Dropping / Recreating Temporary Tablespace Method

Keep in mind that the procedures documented here for dropping and recreating your temporary tablespace should be performed during off hours with no users logged on performing work.

If you are working with a temporary tablespace in Oracle8i or a temporary tablespace in Oracle9i that is NOT the default temporary tablespace for the database, this process is straight forward. Simply drop and recreate the temporary tablespace:

SQL> DROP TABLESPACE temp;

Tablespace dropped.

SQL> CREATE TEMPORARY TABLESPACE TEMP
2 TEMPFILE '/u02/oradata/TESTDB/temp01.dbf' SIZE 500M REUSE
3 AUTOEXTEND ON NEXT 100M MAXSIZE unlimited
4 EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;

Tablespace created.
Oracle9i Default Temporary Tablespace

The procedures above document how to drop a temporary tablespace that is not the default temporary tablespace for the database. You will know fairly quickly if the tablespace is a default temporary tablespace when you are greeted with the following exception:

SQL> DROP TABLESPACE temp;
drop tablespace temp
*
ERROR at line 1:
ORA-12906: cannot drop default temporary tablespace
In cases where the temporary tablespace you want to resize (using the drop/recreate method) is the default temporary tablespace for the database, you have several more steps to perform, all documented below. The first step you need to perform is create another temporary tablespace (lets call it TEMP2). The next step would be to remove the temporary tablespace you want to resize from being the default temporary tablespace (in our example, this will be a tablespace named TEMP) by making TEMP2 the default. Drop / recreate the TEMP tablespace to the size you want. Finally, make the newly created TEMP tablespace your default temporary tablespace for the database and drop the TEMP2 tablespace. A full example session is provided below:
SQL> CREATE TEMPORARY TABLESPACE temp2
2 TEMPFILE '/u02/oradata/TESTDB/temp2_01.dbf' SIZE 5M REUSE
3 AUTOEXTEND ON NEXT 1M MAXSIZE unlimited
4 EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;

Tablespace created.


SQL> ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp2;

Database altered.


SQL> DROP TABLESPACE temp INCLUDING CONTENTS AND DATAFILES;

Tablespace dropped.

SQL> CREATE TEMPORARY TABLESPACE temp
2 TEMPFILE '/u02/oradata/TESTDB/temp01.dbf' SIZE 500M REUSE
3 AUTOEXTEND ON NEXT 100M MAXSIZE unlimited
4 EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;

Tablespace created.


SQL> ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp;

Database altered.


SQL> DROP TABLESPACE temp2 INCLUDING CONTENTS AND DATAFILES;

Tablespace dropped.



Drop Tempfile Command Method - (Oracle9i and higher)

If you are using Oracle9i or higher, another method exists that allows you to simply drop a tempfile. As with the above method, this should be performed during off hours with no users logged on performing work.

The first step is to obtain the name of the tempfile to drop. For this example, my temporary tablespace name is TEMP and the name of the tempfile is /u02/oradata/TESTDB/temp2_01.dbf:

SQL> SELECT tablespace_name, file_name, bytes
2 FROM dba_temp_files WHERE tablespace_name = 'TEMP';

TABLESPACE_NAME FILE_NAME BYTES
----------------- -------------------------------- --------------
TEMP /u02/oradata/TESTDB/temp01.dbf 13,107,200,000
The normal size of my temporary tablespace is 512MB which has always been more than adequate for this environment. A bad query, however, increased the size of this tablespace (my tempfile) to over 13GB and I would like to reclaim that space. In the example below, I simply drop and recreate the tempfile:
SQL> ALTER DATABASE TEMPFILE '/u02/oradata/TESTDB/temp01.dbf' DROP INCLUDING DATAFILES;

Database altered.


SQL> ALTER TABLESPACE temp ADD TEMPFILE '/u02/oradata/TESTDB/temp01.dbf' SIZE 512m
2 AUTOEXTEND ON NEXT 250m MAXSIZE UNLIMITED;

Tablespace altered.

On some platforms (i.e. Windows 2000), it is possible for the tempfile to be deleted from DBA_TEMP_FILES but not from the hard drive of the server.

If this occurs, simply delete the file using regular O/S commands.

SQL> SELECT tablespace_name, file_name, bytes
2 FROM dba_temp_files WHERE tablespace_name = 'TEMP';

TABLESPACE_NAME FILE_NAME BYTES
----------------- -------------------------------- --------------
TEMP /u02/oradata/TESTDB/temp01.dbf 536,870,912

If users are currently accessing the tempfile you are attempting to drop, you may receive the following error:
SQL> ALTER DATABASE TEMPFILE '/u02/oradata/TESTDB/temp01.dbf' DROP INCLUDING DATAFILES;
ALTER DATABASE TEMPFILE '/u02/oradata/TESTDB/temp01.dbf' DROP INCLUDING DATAFILES
*
ERROR at line 1:
ORA-25152: TEMPFILE cannot be dropped at this time
As for the poor users who were using the tempfile, their transaction will end and will be greeted with the following error message:
SQL> @testTemp.sql
join dba_extents c on (b.segment_name = c.segment_name)
*
ERROR at line 4:
ORA-00372: file 601 cannot be modified at this time
ORA-01110: data file 601: '/u02/oradata/TESTDB/temp01.dbf'
ORA-00372: file 601 cannot be modified at this time
ORA-01110: data file 601: '/u02/oradata/TESTDB/temp01.dbf'
If this happens, you should attempt to drop the tempfile again so the operation is successful:
SQL> ALTER DATABASE TEMPFILE '/u02/oradata/TESTDB/temp01.dbf' DROP INCLUDING DATAFILES;

Database altered.
==========================
In oracle 11g, you can shrink temp tablespace in the following simple way:
alter tablespace temp shrink space;
alter tablespace temp shrink space keep 10m;
alter tablespace temp shrink tempfile '/path/to/file.dbf';