In a recent migration using full transportable export/import, I noticed a lot of time spent on the following SQL:
SELECT NVL((SELECT 2
FROM sys.ku$_all_tsltz_tables
WHERE owner = :1 AND table_name = :2), 0)
FROM sys.dual
The SQL ID was g3qu7py3g0yg0. Each execution of the SQL was a few seconds, but Data Pump executed the statement many times.
Data Pump also wrote in the log file that the database timezone differed:
01-NOV-23 07:43:22.152: W-1 Source time zone is +00:00 and target time zone is -07:00.
The following applies to full transportable export/imports using the following Data Pump parameters:
full=y
transportable=always
What Happens?
In a full transportable import, if the database time zone is different, Data Pump translates any data of type Timestamp with local timezone (TSLTZ) to the new database timezone.
On startup, Data Pump detects the difference in the source and target database timezone. For each table Data Pump checks whether it must convert data. If needed, the data is converted from the source database timezone and stored in the target database timezone.
The check and conversion takes time. This is the price you must pay to change the database timezone on import.
Alternatively, you must import into a database with the same timezone. Then Data Pump completely skips the check and conversion.
In the migration, we could save 22 minutes on import by importing into the same database time zone.
Changing the Database Timezone
You can find the database timezone using:
select dbtimezone from dual;
If you don’t have any tables with TSLTZ columns, you can change the database timezone:
alter database set time_zone='+00:00';
shutdown immediate
startup
The database timezone affects only:
- TSLTZ columns
- Function
CURRENT_DATE
- Function
CURRENT_TIMESTAMP
- Function
LOCALTIMESTAMP
If you don’t use any of the above, it should be safe to change the database timezone.
Columns of type Timestamp with timezone (TSTZ) and the database timezone file (v$timezone_file
) are totally unrelated to the database timezone.
Full Transportable vs. Traditional Transportable
In a traditional transportable import, Data Pump does not import tables with columns of type TIMESTAMP WITH LOCAL TIME ZONE (TSLTZ). You must move such tables using a regular Data Pump import.
As mentioned above, a full transportable export/import Data Pump translates the data to match the new database timezone.
Other Blog Posts in This Series
- Introduction
- Prerequisites
- Full Transportable Export/Import
- What Is a Self-contained Transportable Tablespace Set
- How to Migrate a Database Using Full Transportable Export/Import and Incremental Backups
- Make It Fast
- Backup on Standby Database
- Slow Network Between Source and Target
- Bigfile Tablespaces
- Testing the Procedure On Activated Standby Database
- Testing the Procedure Multiple Times Using Read-Only Tablespaces
- Target Database and Data Guard
- ASM Aliases and Why You Should Get Rid of Them
- How to use Transportable Tablespace with TDE Tablespace Encryption
- Understand How a Change of Database Time Zone Affects Transportable Tablespaces
- Pro Tips