FLASHBACK : SETUP & MAINTENANCE

Limitations of Flashback Database

1. Flashback Database can only undo changes to a datafile made by an Oracle database. It cannot be used to repair media failures, or to recover from a deletion of datafiles.
2. You cannot use Flashback Database to undo a shrink datafile operation.
3. If the database control file is restored from backup or re-created, all accumulated flashback log information is discarded. You cannot use FLASHBACK DATABASE to return to a point in time before the restore or re-creation of a control file.
4. When using Flashback Database with a target time at which a NOLOGGING operation was in progress, block corruption is likely in the database objects and datafiles affected by the NOLOGGING operation. For example, if you perform a direct-path INSERT operation in NOLOGGING mode, and that operation runs from 9:00 to 9:15 on April 3, 2005, and you later need to use Flashback Database to return to the target time 09:07 on that date, the objects and datafiles updated by the direct-path INSERT may be left with block corruption after the Flashback Database operation completes. If possible, avoid using Flashback Database with a target time or SCN that coincides with a NOLOGGING operation. Also, perform a full or incremental backup of the affected datafiles immediately after any NOLOGGING operation to ensure recoverability to points in time after the operation. If you expect to use Flashback Database to return to a point in time during an operation such as a direct-path INSERT, consider performing the operation in LOGGING mode.

Requirements for Enabling Flashback Database

Your database must be running in ARCHIVELOG mode, because archived logs are used in the Flashback Database operation. You must have a flash recovery area enabled, because flashback logs can only be stored in the flash recovery area. For Real Application Clusters databases, the flash recovery area must be stored in a clustered file system or in ASM.

Enabling Logging for Flashback Database

To enable logging for Flashback Database, set the DB_FLASHBACK_RETENTION_TARGET initialization parameter and issue the ALTER DATABASE FLASHBACK ON statement.

1. Start SQL*Plus and ensure that the database is mounted, but not open.
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;

2. Optionally, set theDB_FLASHBACK_RETENTION_TARGET to the length of the desired flashback window in minutes:
SQL> ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=4320;
# 4320 = 3 days (By default DB_FLASHBACK_RETENTION_TARGET is set to one day (1440 minutes)).

3. Enable the Flashback Database feature for the whole database:
SQL> ALTER DATABASE FLASHBACK ON;

By default, flashback logs are generated for all permanent tablespaces. If you wish, you can reduce overhead by disabling flashback logging for specific tablespaces:
SQL> ALTER TABLESPACE tbs_3 FLASHBACK OFF;

You can re-enable flashback logging for a tablespace later with this command: SQL> ALTER TABLESPACE tbs_3 FLASHBACK ON;

Note: if you disable Flashback Database for a tablespace, then you must take its datafiles offline before running FLASHBACK DATABASE.

You can disable flashback logging for the entire database with this command: SQL> ALTER DATABASE FLASHBACK OFF;

Creating Normal and Guaranteed Restore Points

To create normal or guaranteed restore points, use the CREATE RESTORE POINT statement in SQL*Plus, providing a name for the restore point and specifying whether it is to be a guaranteed restore point or a normal one (the default). The database can be open or mounted when creating restore points. If it is mounted, then it must have been shut down cleanly.
SQL> CREATE RESTORE POINT before_upgrade;
Restore point created.
SQL> CREATE RESTORE POINT before_upgrade GUARANTEE FLASHBACK DATABASE;
Restore point created.

Listing Restore Points

To see a list of the currently defined restore points, use the V$RESTORE_POINT control file view, by means of the following query:

SQL> SELECT NAME, SCN, TIME, DATABASE_INCARNATION#, GUARANTEE_FLASHBACK_DATABASE, STORAGE_SIZE FROM V$RESTORE_POINT;

You can also use the following query to view only the guaranteed restore points:

SQL> SELECT NAME, SCN, TIME, DATABASE_INCARNATION#, GUARANTEE_FLASHBACK_DATABASE, STORAGE_SIZE FROM V$RESTORE_POINT WHERE GUARANTEE_FLASHBACK_DATABASE='YES';

For normal restore points, STORAGE_SIZE is zero. For guaranteed restore points, STORAGE_SIZE indicates the amount of disk space in the flash recovery area used to retain logs required to guarantee FLASHBACK DATABASE to that restore point.

Dropping Restore Points

When you are satisfied that you do not need an existing restore point, or when you want to create a new restore point with the name of an existing restore point, you can drop the restore point, using the DROP RESTORE POINT SQL*Plus statement.

SQL> DROP RESTORE POINT before_app_upgrade;
Restore point dropped.

The same statement is used to drop both normal and guaranteed restore points. Guaranteed restore points never age out of the control file. They remain until they are explicitly dropped.

Monitoring Space Usage For Guaranteed Restore Points

When guaranteed restore points are defined on your database, you should monitor the amount of space used in your flash recovery area for files required to meet the guarantee. Use the query for viewing guaranteed restore points in "Listing Restore Points" and refer to the STORAGE_SIZE column to determine the space required for files related to each guaranteed restore point. To see the total usage of your flash recovery area, use V$RECOVERY_FILE_DEST and V$FLASH_RECOVERY_AREA_USAGE".

Sizing the Flash Recovery Area to Include Flashback Logs

When using Flashback Database, you must add extra space to the flash recovery area to hold the flashback logs, along with the other files stored in the flash recovery area. The setting of the DB_FLASHBACK_RETENTION_TARGET initialization parameter determines, indirectly, how much flashback log data the database retains. The size of flashback logs generated by the database for a given time period can vary considerably, however, depending on the specific database workload. If more blocks are affected by database updates during a given interval, then more disk space is used by the flashback log data generated for that interval.


Estimating Disk Space Requirements for Flashback Database Logs

The V$FLASHBACK_DATABASE_LOG view can help you estimate how much space to add to your flash recovery area for flashback logs. After you have enabled logging for Flashback Database and set a flashback retention target, allow the database to run under a normal workload for a while, to generate a representative sample of flashback logs.
SQL> SELECT ESTIMATED_FLASHBACK_SIZE FROM V$FLASHBACK_DATABASE_LOG;

The result is an estimate of the disk space needed to meet the current flashback retention target, based on the database workload since Flashback Database was enabled. Add the amount of disk space specified in $FLASHBACK_DATABASE_LOG.ESTIMATED_FLASHBACK_SIZE to your flash recovery area size, to hold the expected database flashback logs.

Managing Space For Flashback Logs in the Flash Recovery Area

You cannot manage the flashback logs in the flash recovery area directly, other than by setting the flashback retention target or using guaranteed restore points. You can, however, manage flash recovery area space as a whole, in order to maximize space available for retention of flashback database logs.



Determining the Current Window for Flashback Database

When flashback logging is enabled, the earliest SCN in the flashback database window can be determined by querying
V$FLASHBACK_DATABASE_LOG.OLDEST_FLASHBACK_SCN and V$FLASHBACK_DATABASE_LOG.OLDEST_FLASHBACK_TIME.

SQL> SELECT OLDEST_FLASHBACK_SCN, OLDEST_FLASHBACK_TIME FROM V$FLASHBACK_DATABASE_LOG;

Calculate the size of the RMAN backup

Yesterday I went to see the backup team to see the ways we can reduce the cost of the backup ( recession time ...cost cutting ;)

I was told by backup team that oracle is taking lot of resources w.r.t tape ..thus they asked me to find out for each database what is the size of the backup ..

It is very difficult to get the size of the rman backup's directly but following SQL will help u to get the approx size in TB about the rman backup sets in tape . This is valid only for 9i ..It may work in 10G also but not checked and tested !!!

select sum(blocks*block_size)/1024/1024/1024/1024 from rc_backup_datafile ;

select sum(blocks*block_size)/1024/1024/1024/1024 from RC_BACKUP_REDOLOG ;

Above SQL's have to be run in sqlplus in RMAN catalog database ..

Some Basic Commands Of RMAN

Flash Recovery Area
The flash recovery area is a location on the filesystem or on an ASM disk group that holds files related to recovery including:

* Multiplexed controlfiles
* Multiplexed online redo logs
* Archived redo logs
* Flashback logs
* RMAN disk backups
* Files created by RESTORE and RECOVERY commands.

Space within the flash recovery area is managed by the database. If there is not enough space to complete an operation obsolete, backed up or redundant files are removed to free up some space.

The following example shows the parameters used to configure the flash recovery area:

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '/u01/app/oracle/flash_recovery_area';
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 2G;
ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET = 1440;

Incrementally Updated Backups
Using this feature all changes between the SCN of the original image copy and the SCN of the incremental backup are applied to the image copy, winding it forward to make the equivalent of a new database image copy without the overhead of such a backup. The following example shows how this can be used:

RUN {
RECOVER COPY OF DATABASE WITH TAG 'incr_backup' UNTIL TIME 'SYSDATE - 7';
BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_backup' DATABASE;
}

The RECOVER COPY... line will not do anything until the script has been running for more than 7 days. The BACKUP INCREMENTAL line will perform a complete backup (level 0) the first day it is run, with all subsequent backups being level 1 incremental backups. After 7 days, the RECOVER COPY... line will start to take effect, merging all incremental backups older than 7 days into the level 0 backup, effectively moving the level 0 backup forward. The effect of this is that you will permanently have a 7 day recovery window with a 7 day old level 0 backup and 6 level 1 incremental backups. Notice that the tag must be used to identify which incremental backups apply to which image copies.

If you wanted to keep your image copy as up to date as possible you might do the following:

RUN {
BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_backup' DATABASE;
RECOVER COPY OF DATABASE WITH TAG 'incr_backup';
}

In this example the incremental backup is merged into the image copy as soon as it is completed.

Fast Incremental Backups
There are performance issues associated with incremental backups as the whole of each datafile must be scanned to identify changed blocks. In Oracle 10g it is possible to track changed blocks using a change tracking file. Enabling change tracking does produce a small overhead, but it greatly improves the performance of incremental backups. The current change tracking status can be displayed using the following query:

SELECT status FROM v$block_change_tracking;

Change tracking is enabled using the ALTER DATABASE command:

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;

By default the change tracking file is created as an Oracle Managed File (OMF) in the location pointed to by the DB_CREATE_FILE_DEST parameter. An alternate location can be specified using the following command:

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
USING FILE '/u01/oradata/MYSID/rman_change_track.f' REUSE;

The tracking file is created with a minumum size of 10M and grows in 10M increments. It's size is typically 1/30,000 the size of the datablocks to be tracked.

Change tracking can be disabled using the following command:

ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;

Renaming or moving a tracking file can be accomplished in the normal way using the ALTER DATABASE RENAME FILE command. If the instance cannot be restarted you can simply disable and re-enable change tracking to create a new file. This method does result in the loss of any current change information.

BACKUP for Backupsets and Image Copies
In Oracle 10g the BACKUP command has been extended to allow it to initiate backups of image copies in addition to backupsets. As a result the COPY command has been deprecated in favour of this new syntax.

BACKUP AS COPY DATABASE;
BACKUP AS COPY TABLESPACE users;
BACKUP AS COPY DATAFILE 1;

RMAN supports the creation of image copies of datafiles and datafile copies, control files and controlfile copies, archived redo logs, and backup pieces.
Cataloging Backup Pieces

It is now possible to manually catalog a backup piece using the CATALOG commands in RMAN. This allows backup files to be moved to alternate locations or manually archived to tape and brought back for restore operations. In Oracle 9i this functionality was only availabale for controlfile copies, archivelog copies and datafile copies. In addition, there are some shortcuts to allow multiple files to be cataloged using a single command. The following examples give the general idea:

# Catalog specific backup piece.
CATALOG BACKUPPIECE '/backup/MYSID/01dmsbj4_1_1.bcp';

# Catalog all files and the contents of directories which
# begin with the pattern "/backup/MYSID/arch".
CATALOG START WITH '/backup/MYSID/arch';

# Catalog all files in the current recovery area.
CATALOG RECOVERY AREA NOPROMPT;

# Catalog all files in the current recovery area.
# This is an exact synonym of the previous command.
CATALOG DB_RECOVERY_FILE_DEST NOPROMPT;

The NOPROMPT clause supresses user confirmation for all matching files.

Improved RMAN Reporting Through V$ Views
Oracle 10g includes additional V$ views making the reporting of backup operations more transparent.

* V$RMAN_OUTPUT - This is an in-memory view of the messages reported by RMAN holding a maximum of 32767 rows. Since this information is not recorded in the controlfile it is lost on instance restart.
* V$RMAN_STATUS - This view displays progress and status information for in-progress and complete RMAN jobs. The information for the in-progress jobs is memory only, while the complete job information comes from the controlfile.
* V$BACKUP_FILES - This view display information about RMAN image copies, backupsets and archived logs, similar to the information listed by the RMAN commands LIST BACKUP and LIST COPY. This view relies on the DBMS_RCVMAN.SETDATABASE procedure being run to set the database.

The V$RMAN_CONFIGURATION view from Oracle 9i is still available in Oracle 10g.

Automatic Instance Creation for RMAN TSPITR
If a tablespace point-in-time recovery (TSPITR) is initiated with no reference to an auxillary instance RMAN now automatically creates an one. The auxillary instance configuration is based on that of the target database. As a result, any channels required for the restore operations must be present in the target database so they are configured correctly in the auxillary instance. The location of the datafiles for the auxillary instance are specified using the AUXILIARY DESTINATION clause shown below.

RECOVER TABLESPACE users
UNTIL LOGSEQ 2400 THREAD 1
AUXILIARY DESTINATION '/u01/oradata/auxdest';

The tablespace is taken offline, restored from a backup, recovered to the specified point-in-time in the auxillary instance and re-imported into the target database. The tablespace in the target database should then be backed up and the tablespace brought back online.

BACKUP TABLESPACE users;
SQL "ALTER TABLESPACE users ONLINE";

On successful completion the auxillary instance will be cleaned up automatically. In the event of errors the auxillary instance is left intact to aid troubleshooting.

Cross-Platform Tablespace Conversion
The CONVERT TABLESPACE allows tablespaces to be transported between platforms with different byte orders. The mechanism for transporting a tablespaces is unchanged, this command merely converts the tablespace to allow the transport to work.

The platform of the source and destination platforms can be identified using the V$TRANSPORTABLE_PLATFORM view. The platform of the local server is not listed as no conversion in necessary for a matching platform.

SQL> SELECT platform_name FROM v$transportable_platform;

PLATFORM_NAME
------------------------------------
Solaris[tm] OE (32-bit)
...
...
Microsoft Windows 64-bit for AMD

15 rows selected.

The tablespace conversion can take place on either the source or the destination server. The following examples show how the command is used in each case:

# Conversion on a Solaris source host to a Linux destincation file.
CONVERT TABLESPACE my_tablespace
TO PLATFORM 'Linux IA (32-bit)'
FORMAT='/tmp/transport_linux/%U';

# Conversion on a Linux destination host from a Solaris source file.
CONVERT DATAFILE=
'/tmp/transport_solaris/my_ts_file01.dbf',
'/tmp/transport_solaris/my_ts_file02.dbf'
FROM PLATFORM 'Solaris[tm] OE (32-bit)'
DB_FILE_NAME_CONVERT
'/tmp/transport_solaris','/u01/oradata/MYDB';

In the first example the converted files are placed in the directory specified by the FORMAT clause. In the second example the specified datafiles are converted to the local servers platform and placed in the correct directory specified by the DB_FILE_NAME_CONVERT clause.
Enhanced Stored Scripts Commands
Scripts can now be defined as global allowing them to be accessed by all databases within the recovery catalog. The syntax for global script manipulation is the same as that for regular scripts with the addition of the GLOBAL clause prior the word SCRIPT. Examples of it's usage are shown below:

CREATE GLOBAL SCRIPT full_backup
{
BACKUP DATABASE PLUS ARCHIVELOG;
DELETE FORCE NOPROMPT OBSOLETE;
}

CREATE GLOBAL SCRIPT full_backup FROM FILE 'full_backup.txt';

RUN { EXECUTE GLOBAL SCRIPT full_backup; }

PRINT GLOBAL SCRIPT full_backup;

LIST GLOBAL SCRIPT NAMES;
LIST ALL SCRIPT NAMES; # Global and local scripts.

REPLACE GLOBAL SCRIPT full_backup
{
BACKUP DATABASE PLUS ARCHIVELOG;
DELETE FORCE NOPROMPT OBSOLETE;
}

REPLACE GLOBAL SCRIPT full_backup FROM FILE 'full_backup.txt';

DELETE GLOBAL SCRIPT 'full_backup';

Backupset Compression
The AS COMPRESSED BACKUPSET option of the BACKUP command allows RMAN to perform binary compression of backupsets. The resulting backupsets do not need to be uncompressed during recovery. It is most useful in the following circumstances:

* You are performing disk-based backup with limited disk space.
* You are performing backups across a network where network bandwidth is limiting.
* You are performing backups to tape, CD or DVD where hardware compression is not available.

The following examples assume that some persistent parameters are configured in a similar manner to those listed below:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/backups/MYSID/%d_DB_%u_%s_%p';

The AS COMPRESSED BACKUPSET option can be used explicitly in the backup command:

# Whole database and archivelogs.
BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG;

# Datafiles 1 and 5 only.
BACKUP AS COMPRESSED BACKUPSET DATAFILE 1,5;

Alternatively the option can be defined using the CONFIGURE command:

# Configure compression.
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO COMPRESSED BACKUPSET;

# Whole database and archivelogs.
BACKUP DATABASE PLUS ARCHIVELOG;

Compression requires additional CPU cycles which may affect the performance of the database. For this reason it should not be used for tape backups where hardware compression is available.
Restore Preview
The PREVIEW option of the RESTORE command allows you to identify the backups required to complete a specific restore operation. The output generated by the command is in the same format as the LIST command. In addition the PREVIEW SUMMARY command can be used to produce a summary report with the same format as the LIST SUMMARY command. The following examples show how these commands are used:

# Preview
RESTORE DATABASE PREVIEW;
RESTORE TABLESPACE users PREVIEW;

# Preview Summary
RESTORE DATABASE PREVIEW SUMMARY;
RESTORE TABLESPACE users PREVIEW SUMMARY;

Managing Backup Duration and Throttling
The DURATION clause of the of the BACKUP command restricts the total time available for a backup to complete. At the end of the time window backup is interrupted with any incomplete backupsets discarded. All complete backupsets aer kept and used for future restore operations. The following examples show how it is used:

BACKUP DURATION 2:00 TABLESPACE users;
BACKUP DURATION 5:00 DATABASE PLUS ARCHIVELOGS;

Miscellaneous

* Disk Topology and Automatic Performance Tuning - RMAN includes a new disk topology API allowing it to work with more platforms and file types. The information from this API allows RMAN to automatically tune some parameters related to multiplexing and disk buffers, decreasing the need to human intervention.
* Automatic Datafile Creation - RMAN will automatically create missing datafiles in two circumstances. First, when the backup controlfile contains a reference to a datafile, but no backup of the datafile is present. Second, when a backup of the datafile is present, but there is no reference in the controlfile as it was not backed up after the datafile addition.
* Proxy Archived Log Backups - During a proxy backup the media manager takes over full control of the backup process. RMAN is now able to backup and restore proxy copies of archived redo logs if a suitable media manager is used. If a suitable media manager is not available PROXY clause is ignored and a regular backup is performed. Using the PROXY ONLY results in an error of a proxy backup cannot be performed.
* Restore Failover - RMAN now allows the recovery process to preceed from one incarnation through to another. The contents of the online redo logs are archived before being cleared when an OPEN RESTLOGS operation is issued. As a result it is no longer necessary to create a new backup after OPEN RESTLOGS operations.
* Recovery Through Restlogs - When a backup file contains corrupt blocks or is inaccesible during restore operations (RECOVER, BLOCKRECOVER, and FLASHBACK DATABASE) RMAN automatically looks for another copy of the file. If one is not available RMAN will use older versions of the file if available. Only if a suitable copy of the file cannot be found will an error be produced. Successful failover operations result in an associated output message.
* Channel Failover - When multiple channels are available for the same device type retriable errors in a backup step will automatically be retried on another channel. Retriable errors are usually associated with media managers failing to access tapes or instance failures in RAC environments.
* Deferred Error Reporting - In addition to error messages during the job execution, the error stack at the end of the command execution now displays errors for all failed steps, making identification of failed step easier.

THE RECYCLE BIN in Oracle 10g

Oracle has introduced "Recycle Bin" Oracle 10g where all dropped objects are stored. If you drop a table in Oracle 10g then any associated objects to this table such as indexes, constraints and other dependant objects are simply renamed with a prefix of BIN$$. Underneath the covers, the objects are occupying the same space as when they were created.

Example:

If table TEST1 was created in the USERS tablespace, the dropped table TEST1 remains in the USERS tablespace. Dropped tables and any associated objects such as indexes, constraints, nested tables, and other dependant objects are not moved, they are simply renamed with a prefix of BIN$$.


SQL> create table test1 ( a number);

Table created.

SQL> drop table test1;

Table dropped.

SQL> SHOW RECYCLEBIN
ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME
---------------- ------------------------------ ------------ -------------------
TEST1 BIN$Ik84R6rKEj7gRAgAIMR0GQ==$0 TABLE 2006-11-15:14:34:13
SQL>



You can continue to access the data in a dropped table. Each user has the same rights and privileges on Recycle Bin objects before it was dropped. You can view your dropped tables by querying the new RECYCLEBIN view.

How to clean recyclebin?

You can user purge recycle bin command to delete all the objects from recycle bin.


SQL> PURGE RECYCLEBIN;

Recyclebin purged.

SQL> SHOW RECYCLEBIN


What if I want to delete objects permanently?

In order to completely remove table from the DB and to release the space, you can use new PURGE command.

SQL> purge table test1;
Table purged.

In this case, table test1 will be deleted from the database permanently.

Space/Quota Issue?

Objects in the Recycle Bin will remain in the database until the owner of the dropped objects decides to permanently remove them using the new PURGE command. The Recycle Bin objects are counted against a user's quota. But Flashback Drop is a non-intrusive feature. Objects in the Recycle Bin will be automatically purged by the space reclamation process if

1. A user creates a new table or adds data that causes his/her quota to be exceeded.
2. The tablespace needs to extend its file size to accommodate create/insert operations.

Can I disable Recycle Bin?

Yes, you can disable it at your session level by using following command.
SQL> ALTER SESSION SET recyclebin = OFF;
SQL> ALTER SYSTEM SET recyclebin = OFF;

The dropped objects, when recyclebin was ON will remain in the recyclebin even if we set the recyclebin parameter to OFF.

Index montoring

You easily forget about all the options you have. I came across a situation, where 39 indexes where created on a single table. This extreme number was grown over the years. There was no administration on which indexes were needed for what purpose. Good luck!

Luckily, you have index monitoring that can be turned on.

alter index MY_IDX_1 monitoring usage;

If you wait for a considerable amount of time, you will see that v$object_usage will contain information on whether the index was used:

select index_name,monitoring,used,start_monitoring,end_monitoring
from v$object_usage;

Note that it is important to log on as the index owner and not as sysdba to see any information in this view. The USED column will probably (maybe) switch from NO to YES if the index is being used.

If you turn off the monitoring:

alter index MY_IDX_1 nomonitoring usage;

the END_MONITORING date field will be filled.

You should not turn off monitoring too soon, there might be monthly reports or hardly used screens that incidentally need the index.

There is a drawback on this. During statististics the index will be used. This will blurr your results. A solution might be to lock statistics during monitoring, using

exec dbms_stats.lock_table_stats(ownname=>'SCOTT',tabname=>'DEPT');

but on heavily changing tables locking statistics might be no such a good idea.

Correct NLS_LANG for exports

It's important to set the right NLS_LANG environment variable when doing exports/imports.
The following query makes it easy getting the syntax and values right.

set heading off
set feedback off
select 'export NLS_LANG=' || lan.value || '_' || ter.value || '.' || chr.value
from v$nls_parameters lan,
v$nls_parameters ter,
v$nls_parameters chr
where lan.parameter='NLS_LANGUAGE'
and ter.parameter='NLS_TERRITORY'
and chr.parameter='NLS_CHARACTERSET';
set heading on
set feedback on

This gives the line (e.g.)
export NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P15

which can easily be copied before the imp/exp is run.
For windows environments, you would need to replace 'export' by 'set' in the query.