Oracle 18c更新TIMEZONE版本
unzip DBMS_DST_scriptsV1.9.zip cd DBMS_DST_scriptsV1.9 @upg_tzv_check.sql @upg_tzv_apply.sql SELECT version FROM v$timezone_file;
DBMS_DST_scriptsV1.9.zip
首先从MOS上下载所需的升级脚本(文档 ID 1585343.1)，从Oracle 11.2开始提供了自动升级的脚本，非常方便。
1 查看当前版本
SQL> SELECT version FROM v$timezone_file;
VERSION
----------
14
2 解压文件，执行检查脚本
[oracle@cndba DBMS_DST_scriptsV1.9]$ ll
total 68
-rw-r--r-- 1 oracle oinstall 6294 Jan 8 2015 countstarTSTZ.sql
-rw-r--r-- 1 oracle oinstall 7213 Mar 17 18:30 countstatsTSTZ.sql
-rw-r--r-- 1 oracle oinstall 19502 Aug 22 2014 upg_tzv_apply.sql
-rw-r--r-- 1 oracle oinstall 31010 Aug 22 2014 upg_tzv_check.sql
检查当前环境
SQL> @/software/DBMS_DST_scriptsV1.9/upg_tzv_check.sql
INFO: Starting with RDBMS DST update preparation.
INFO: NO actual RDBMS DST update will be done by this script.
INFO: If an ERROR occurs the script will EXIT sqlplus.
INFO: Doing checks for known issues ...
INFO: Database version is 18.0.0.0 .
INFO: Database RDBMS DST version is DSTv14 .
INFO: No known issues detected.
INFO: Now detecting new RDBMS DST version.
A prepare window has been successfully started.
INFO: Newest RDBMS DST version detected is DSTv31 .
INFO: Next step is checking all TSTZ data.
INFO: It might take a while before any further output is seen ...
A prepare window has been successfully ended.
INFO: A newer RDBMS DST version than the one currently used is found.
INFO: Note that NO DST update was yet done.
INFO: Now run upg_tzv_apply.sql to do the actual RDBMS DST update.
INFO: Note that the upg_tzv_apply.sql script will
INFO: restart the database 2 times WITHOUT any confirmation or prompt.
更新TIMEZONE版本
这里需要注意，执行该脚本会自动重启数据库两次。如下：
SQL> @/software/DBMS_DST_scriptsV1.9/upg_tzv_apply.sql
INFO: If an ERROR occurs the script will EXIT sqlplus.
INFO: The database RDBMS DST version will be updated to DSTv31 .
WARNING: This script will restart the database 2 times --重启数据库两次
WARNING: WITHOUT asking ANY confirmation.
WARNING: Hit control-c NOW if this is not intended.
INFO: Restarting the database in UPGRADE mode to start the DST upgrade.
INFO: Upgrading all non-SYS TSTZ data.
INFO: It might take time before any further output is seen ...
INFO: Do NOT start any application yet that uses TSTZ data!
INFO: Next is a list of all upgraded tables:
Table list: "APEX_050100"."WWV_FLOW_DEBUG_MESSAGES"
Number of failures: 0
Table list: "APEX_050100"."WWV_FLOW_DEBUG_MESSAGES2"
Number of failures: 0
Table list: "APEX_050100"."WWV_FLOW_FEEDBACK"
Number of failures: 0
Table list: "APEX_050100"."WWV_FLOW_FEEDBACK_FOLLOWUP"
Number of failures: 0
Table list: "APEX_050100"."WWV_FLOW_WORKSHEET_NOTIFY"
Number of failures: 0
Table list: "GSMADMIN_INTERNAL"."AQ$_CHANGE_LOG_QUEUE_TABLE_S"
Number of failures: 0
Table list: "GSMADMIN_INTERNAL"."AQ$_CHANGE_LOG_QUEUE_TABLE_L"
Number of failures: 0
INFO: Total failures during update of TSTZ data: 0 .
An upgrade window has been successfully ended.
INFO: Your new Server RDBMS DST version is DSTv31 .
INFO: The RDBMS DST update is successfully finished.
INFO: Make sure to exit this sqlplus session.
INFO: Do not use it for timezone related selects.
3 检查版本
版本号已成功更新为31
SQL> SELECT version FROM v$timezone_file;
VERSION
----------
31
1 row selected.
| Scripts to automatically update the RDBMS DST (timezone) version in an 11gR2 or 12c database . (文档 ID 1585343.1) |
In this Document
| Purpose |
| Requirements |
| Configuring |
| Instructions |
| Upgrading Timezone file on Oracle Releases post 12cR2 |
| 1) (optional) run countstatsTSTZ.sql or countstarTSTZ.sql and removed uneeded TSTZ data to reduce the time needed to run upg_tzv_check.sql and upg_tzv_apply.sql |
| 2) run upg_tzv_check.sql using SQL*PLUS from the database home |
| 3) if upg_tzv_check.sql has run sucessfully , run upg_tzv_apply.sql using SQL*PLUS from the database home |
| 4) Selects to see what is happening / what do if the scripts "hang": |
| 5) Can the RDBMS DST version be updated without downtime? Or in a "rolling" fashion on RAC? |
| 6) CDB /PDB (Multitenant) database and DST updates. |
| Sample Code |
| Sample Output |
| 1) countstatsTSTZ.sql output |
| 2) upg_tzv_check.sql output |
| 3) upg_tzv_apply.sql output |
| References |
APPLIES TO:
Oracle Database Exadata Express Cloud Service - Version N/A and later
Oracle Database Cloud Exadata Service - Version N/A and later
Oracle Database Cloud Service - Version N/A and later
Oracle Database - Enterprise Edition - Version 11.2.0.1 to 12.2.0.1 [Release 11.2 to 12.2]
Oracle Database - Standard Edition - Version 11.2.0.1 to 12.2.0.1 [Release 11.2 to 12.2]
Information in this document applies to any platform.
PURPOSE
These scripts prepare and then upgrade an Oracle RDBMS 11.2.0.1 or higher database to the latest RDBMS DST version installed in the Oracle_Home.
Current version of the upg_tzv_check.sql and upg_tzv_apply.sql scripts is v1.9 released on 22 AUG 2014.
The DBMS_DST_SCRIPTSV1.9 zip file was re-uploaded on 8 JAN 2015 to include the (optional) countstatsTSTZ.sql and countstarTSTZ.sql scripts who replace the previous included countTSTZdata.sql script
The RDBMS DST version is the value seen in
Conn / as sysdba
-- this gives the current RDBMS DST version
SELECT version FROM v$timezone_file;
-- check also
SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value
FROM DATABASE_PROPERTIES
WHERE PROPERTY_NAME LIKE 'DST_%'
ORDER BY PROPERTY_NAME;
-- the output gives
-- PROPERTY_NAME VALUE
-- ------------------------------ ------------------------------
-- DST_PRIMARY_TT_VERSION <current DST version> <<<<------ this should match version FROM v$timezone_file if not make sure the database is open when selecting from v$timezone_file;
-- DST_SECONDARY_TT_VERSION 0 <<<<------ this should be "0" if not then see point 3a) in note 977512.1 (for 11gR2) or note 1509653.1 (for 12c)
-- DST_UPGRADE_STATE NONE <<<<------ this should be "NONE" if not then see point 3a) in note 977512.1 (for 11gR2) or note 1509653.1 (for 12c)
The scripts do all the actions in step 3) , 4) , 5) and 6) in note 1509653.1 Updating the RDBMS DST version in 12c Release 1 (12.1.0.1 and up) using DBMS_DST or Note 977512.1 Updating the RDBMS DST version in 11gR2 (11.2.0.1 and up) using DBMS_DST.
* The (optional) countstatsTSTZ.sql or countstarTSTZ.sql will give an idea about the amount of TSTZ rows and may be used to reduce the needed time for the DST update (= point 5) in above notes).
* The upg_tzv_check.sql script will
- check for all known issues ( = point 6) in above notes) provoking problems during the DST update and report these, before any DST update is done, if any are found.
- find the highest installed DST version in this $ORACLE_HOME and do all the pre checks on the data (= point 3) in above notes)
* The upg_tzv_apply.sql will do the actual DST update ( = point 4) in above notes) and need a succesful run of upg_tzv_check.sql to work.
Unless an error is raised all required information is in this note.
These scripts are provided "as is", feedback or enhancements are welcome (please use the feedback button) but please DO note that they are maintained on a "best effort" basis by Oracle support.
To avoid confusion:
To update an 11gR2 or 12cR1 database to the highest RDBMS DST version included by default in that 11gR2 or 12cR1 version (most likely after an Oracle RDBMS version upgrade to 11gR2 or 12cR1) there is no need to apply any "DST patch" , you can simply run the scripts in this note.
The highest RDBMS DST version included by default is for 11.2.0.1 DSTv11 , for 11.2.0.2, 11.2.0.3 and 11.2.0.4 DSTv14, for 12.1.0.1 and 12.1.0.2 DSTv18.
The scripts can also be used if you have applied a newer RDBMS DST patch than the highest RDBMS DST version included by default in that 11gR2 or 12cR1 version (= followed one of the "Applying the DSTvXX update for the Oracle Database" notes in NOTE 412160.1 Updated DST transitions and new Time Zones in Oracle Time Zone File patches).
The upg_tzv_check.sql and upg_tzv_apply.sql scripts then need to be run AFTER the newer Oracle RDBMs DST patch is applied to the oracle_home , as indicated in the "Applying the DSTvXX update for the Oracle Database" notes.
Used abbreviations:
TSTZ: Time Stamp with Time Zone
This document can be used only till release 12.2.0.1 . For the subsequent releases, the timezone upgrade scripts are included in the target ORACLE_HOME under rdbms/admin directory. Refer to Database Globalization Support Guide in " Upgrading the Time Zone File and Timestamp with Time Zone Data " Section.
REQUIREMENTS
- upg_tzv_check.sql and upg_tzv_apply.sql only work on an 11gR2 (11.2.0.1 and up) or 12cR1 (12.1.0.1 and up) database
- script specific information is found at the beginning of each script, it has been copied here :
Rem NAME
Rem upg_tzv_check.sql - time zone update check script for 11gR2 (and higher)
Rem Version 1.9
Rem published in note 1585343.1 Scripts to automatically update the RDBMS DST (timezone) version in an 11gR2 or 12cR1 database .
Rem
Rem NOTES
Rem * This script must be run using SQL*PLUS from the database home.
Rem * This script must be connected AS SYSDBA to run.
Rem * The database need to be 11.2.0.1 or higher.
Rem * The database will NOT be restarted .
Rem * NO downtime is needed for this script.
Rem * This script takes no arguments.
Rem * This script WILL exit SQL*PLUS when an error is detected
Rem * The dba_recyclebin WILL be purged.
Rem * This script will check for all known issues at time of last update.
Rem * An UPG_TZV table will be created.
Rem * TZ_VERSION in Registry$database will be updated with current version.
Rem * The upg_tzv_apply.sql script depends on this script.
Rem * The script will write a line into the alert.log when ending succesfully.
Rem NAME
Rem upg_tzv_apply.sql - time zone update apply script for 11gR2 (and higher)
Rem Version 1.9
Rem published in note 1585343.1 Scripts to automatically update the RDBMS DST (timezone) version in an 11gR2 or 12cR1 database .
Rem
Rem NOTES
Rem * The upg_tzv_check.sql script must be run before this script.
Rem * This script must be run using SQL*PLUS from the database home.
Rem * This script must be connected AS SYSDBA to run.
Rem * The database need to be 11.2.0.1 or higher.
Rem * The database need to be single instance ( cluster_database = FALSE ).
Rem * The database will be restarted 2 times without asking any confirmation.
Rem * This script takes no arguments.
Rem * This script WILL exit SQL*PLUS when an error is detected
Rem * The dba_recyclebin WILL be purged.
Rem * TZ_VERSION in Registry$database will be updated with new DST version after the DST upgrade.
Rem * The UPG_TZV table will be dropped.
Rem * the script will write a line into the alert.log before restarting the db and when ending succesfully.
* countstatsTSTZ.sql or countstarTSTZ.sql is optional, it's a simple script to estimate how much TSTZ data the database has stored.
CONFIGURING
Download the DBMS_DST_scriptsV1.9.zip file and unzip, it contains 4 files: upg_tzv_check.sql and upg_tzv_apply.sql , countstatsTSTZ.sql and countstarTSTZ.sql .
Copy the 4 files to your database server, the location of the scripts can be any directory on the server.
INSTRUCTIONS
UPGRADING TIMEZONE FILE ON ORACLE RELEASES POST 12CR2
From 12cR2 onwards, timezone upgrade scripts are included in the target ORACLE_HOME under rdbms/admin directory. Customer can use those files to perform time zone upgrade instead of the ones included in this document. Please refer to Oracle Documentation on how to upgrade a time zone file manually:
Database Globalization Support Guide
Section 4.7.3 Steps to Upgrade Time Zone File and Timestamp with Time Zone Data
1) (optional) run countstatsTSTZ.sql or countstarTSTZ.sql and removed uneeded TSTZ data to reduce the time needed to run upg_tzv_check.sql and upg_tzv_apply.sql
The countstatsTSTZ.sql will list the stats num_row of all tables that have a TSTZ column (= processed by DBMS_DST ) and have actual data according to the stats.
If your stats are up to date then use countstatsTSTZ.sql , no need to run then countstarTSTZ.sql .
The countstarTSTZ.sql will do a count(*) of all tables that have a TSTZ column (= processed by DBMS_DST ) and have actual data (= count (*) is >0 ).
A count(*) will be of course a lot slower than checking the stats as done by countstatsTSTZ.sql and may give a give different result than countstatsTSTZ.sql .
There is no added value in having the EXACT nr of rows, these countstatsTSTZ.sql or countstarTSTZ.sql scripts are pure to give an indication of what tables have a lot of TSTZ data.
And again, countstatsTSTZ.sql or countstarTSTZ.sql are OPTIONAL.
The countstatsTSTZ.sql (or countstarTSTZ.sql) script is NOT required for upg_tzv_check.sql and upg_tzv_apply.sql.
It's an (simple) optional script to give some idea about how much data need to be processed and if there is data that can be removed.
Conn / as sysdba
spool countstatsTSTZ.log
@countstatsTSTZ.sql
spool off
For most databases the biggest amount of data that is affected by DST updates will be in DBMS_SCHEDULER tables.
If DBMS_SCHEDULER is not used for own jobs or is used but there is no need to keep the history then it might be an idea to purge the DBMS_SCHEDULER logging information using
Conn / as sysdba
exec dbms_scheduler.purge_log;
Other often seen tables are SYS.WRI$_OPTSTAT_HISTGRM_HISTORY and SYS.WRI$_OPTSTAT_HISTHEAD_HISTORY, this can be used to remove / reduce the nr of rows if needed (if there are many rows in those tables ):
Conn / as sysdba
-- check current nr of rows in HISTHEAD / HISTGRM
select count(*) from SYS.WRI$_OPTSTAT_HISTGRM_HISTORY;
select count(*) from SYS.WRI$_OPTSTAT_HISTHEAD_HISTORY;
-- check the current retention of stats
-- the default value is 31
select systimestamp - dbms_stats.get_stats_history_availability from dual;
-- now disable stats retention
exec dbms_stats.alter_stats_history_retention(0);
-- remove all stats
exec DBMS_STATS.PURGE_STATS(systimestamp);
-- check result of purge
select count(*) from SYS.WRI$_OPTSTAT_HISTGRM_HISTORY;
select count(*) from SYS.WRI$_OPTSTAT_HISTHEAD_HISTORY;
-- AFTER the DST update you can set the retention back to the original value
exec dbms_stats.alter_stats_history_retention(31);
When doing a DST update together with an Oracle RDBMS version upgrade the stats can be purged before doing the version upgrade - no downtime required.
In 11.2.0.3 and higher DBMS_STATS.PURGE_STATS will be done in chunks of 10000 rows ( Bug 8553944 : SYSAUX TABLESPACE IS GROWING RAPIDLY )
In 11.2.0.2 and lower we suggest to use DBMS_STATS.PURGE_STATS in such a way it purges manually in chunks to avoid running out of undo space (ORA-1555), see note 1055547.1 SYSAUX Grows Because Optimizer Stats History is Not Purged.
PURGE_STATS normally does do a delete, it can use also a truncate in 11.2.0.3 and higher systems (where Bug 10279045 - ORA-12751 - CPU OR RUNTIME POLICY VIOLATION is fixed)
This can be done by using the SQL> exec DBMS_STATS.PURGE_STATS(DBMS_STATS.PURGE_ALL); command instead of SQL> exec DBMS_STATS.PURGE_STATS(systimestamp);
This can be useful if there are millions of rows in the SYS.WRI$_OPTSTAT_HIST% tables.
2) run upg_tzv_check.sql using SQL*PLUS from the database home
Note that upg_tzv_check.sql takes no arguments, it will detect the highest installed DST patch automatically and needs no downtime, this can be executed on a live production database but it WILL purge the dba_recyclebin.
Conn / as sysdba
spool upg_tzv_check.log
@upg_tzv_check.sql
spool off
A succesfull run will show at the end:
INFO: A newer RDBMS DST version than the one currently used is found.
INFO: Note that NO DST update was yet done.
INFO: Now run upg_tzv_apply.sql to do the actual RDBMS DST update.
INFO: Note that the upg_tzv_apply.sql script will
INFO: restart the database 2 times WITHOUT any confirmation or prompt.
If above is seen upg_tzv_apply.sql can be run.
upg_tzv_check.sql will after a succesfull run also write "upg_tzv_check sucessfully found newer RDBMS DSTv -new version- and took -time- minutes to run." to the alert.log
If upg_tzv_check.sql errors out and exits SQL*PLUS with "ORA-200xx: Stopping script - see previous message ....." check the last messages why this happend and what to do....
3) if upg_tzv_check.sql has run sucessfully , run upg_tzv_apply.sql using SQL*PLUS from the database home
Note:
- For RAC databases make sure the database is started as single instance
- Make sure any application accessing or storing TSTZ data is stopped
- upg_tzv_apply.sql will restart the database 2 times without asking any confirmation
- Typically upg_tzv_apply.sql will take less time than upg_tzv_check.sql
- When executed against the CDB of a Multitenant db all PDB will be closed
Conn / as sysdba
spool upg_tzv_apply.log
@upg_tzv_apply.sql
spool off
A succesfull run will show at the end:
INFO: The RDBMS DST update is successfully finished.
INFO: Make sure to exit this sqlplus session.
INFO: Do not use it for timezone related selects.
If upg_tzv_apply.sql errors out and exits SQL*PLUS with "ORA-200xx: Stopping script - see previous message ....." check the last messages why this happend and what to do....
upg_tzv_apply.sql will during a succesfull run also write :
"upg_tzv_apply is ready to update to RDBMS DSTv -new version- and will now restart the database in UPGRADE mode."
"upg_tzv_apply has processed all SYS TSTZ data and will now restart the database to update all non SYS TSTZ data."
"upg_tzv_apply sucessfully updated this database to RDBMS DSTv -new version- and took -time- minutes to run."
to the alert.log
4) Selects to see what is happening / what do if the scripts "hang":
upg_tzv_check.sql :
The time needed for upg_tzv_check.sql after "INFO: Next step is checking all TSTZ data. INFO: It might take a while before any further output is seen ..." depends on the amount of TSTZ data and might take considerable time when there is a large amount of TSTZ data.
If there is no user TSTZ data in this database then leave upg_tzv_check.sql running but before running upg_tzv_apply.sql check the output of countstatsTSTZ.sql or countstarTSTZ.sql and follow the suggestions to remove uneeded TSTZ data.
If upg_tzv_check.sql "hangs" a long time on "INFO: Doing checks for known issues ..." then first of all check if you are using the version 1.7 (or higher) of the upg_tzv_check.sql or upg_tzv_apply.sql scripts, if not then use the version 1.7 (or higher) scripts.
if you are using the version 1.7 (or higher) of the scripts then collect the output of "To see what's happening during upg_tzv_check.sql or upg_tzv_apply.sql " selects below and log a sr .
upg_tzv_apply.sql :
After the "INFO: Upgrading all non-SYS TSTZ data." message during upg_tzv_apply.sql one can connect with a second session and this count (*) should go down:
CONN / as sysdba
SELECT count(*) FROM ALL_TSTZ_TABLES where UPGRADE_IN_PROGRESS='YES';
as long as the count(*) goes down upg_tzv_apply.sql is working it's way trough the dataset , simply wait until it's done.
If there is no user TSTZ data in this database then for the next update check the output of countstatsTSTZ.sql or countstarTSTZ.sql and follow the suggestions to remove uneeded TSTZ data.
If it does not go down use below selects and check for locking issues who may be caused by an application that acesses TSTZ columns connecting. In that case stop the application.
To see what's happening during upg_tzv_check.sql or upg_tzv_apply.sql one can use:
CONN / as sysdba
set PAGES 1000
select TARGET, TO_CHAR(START_TIME,'HH24:MI:SS - DD-MM-YY'), TIME_REMAINING, SOFAR,
TOTALWORK, SID, SERIAL#, OPNAME from V$SESSION_LONGOPS
where sid in
(select SID from V$SESSION where CLIENT_INFO = 'upg_tzv')
and SOFAR < TOTALWORK
order by START_TIME;
select S.SID, S.SERIAL#, S.SQL_ID, S.PREV_SQL_ID,
S.EVENT#, S.EVENT, S.P1TEXT, S.P1, S.P2TEXT, S.P2, S.P3TEXT, S.P3, S.TIME_REMAINING_MICRO,
S.SEQ#, S.BLOCKING_SESSION, BS.PROGRAM "Blocking Program",
Q1.SQL_TEXT "Current SQL", Q2.SQL_TEXT "Previous SQL"
from V$SESSION S, V$SQLAREA Q1, V$SQLAREA Q2, V$SESSION BS
where S.SQL_ID = Q1.SQL_ID(+)
and S.PREV_SQL_ID = Q2.SQL_ID(+)
and S.BLOCKING_SESSION = BS.SID(+)
and S.CLIENT_INFO = 'upg_tzv';
5) Can the RDBMS DST version be updated without downtime? Or in a "rolling" fashion on RAC?
NO. Downtime is required to update RDBMS DST version
Detailed answer:
* ( if needed) For the apply of an RDBMS DST patch itself using Opatch or manually -> no downtime needed even if the readme of the patch may state otherwise.
* For the run of upg_tzv_check.sql -> no downtime needed.
* For the first part of upg_tzv_apply.sql after the "INFO: Restarting the database in UPGRADE mode to start the DST upgrade." message -> downtime needed and a RAC database need to be in single instance mode (cluster_database = false) , as required by the "startup UPGRADE" . upg_tzv_apply.sql will refuse to run if the database is started with cluster_database = true.
* For the second part of upg_tzv_apply.sql after the "INFO: Upgrading all non-SYS TSTZ data." message -> the DBMS_DST.UPGRADE_DATABASE used by upg_tzv_apply.sql will take exclusive locks on the non-SYS tables when they are actually upgraded, so this might provoke issues (deadlocks have been observed) and we strongly suggest to NOT start any applications who use the tables processed until the complete DST update is done. Other applications may already be restarted if needed.
6) CDB /PDB (Multitenant) database and DST updates.
Make sure to use version 1.9 or higher of the upg_tzv_check.sql and upg_tzv_apply.sql scripts.
Updating the RDBMS DST version of the CDB will not change the RDBMS_DST version of the PDB's in this CDB.
Updating the RDBMS DST version of a PDB will not change the RDBMS_DST version of the other PDB's or the CDB.
When creating a new PDB the RDBMS DST version of new PDB is the RDBMS DST version of PDB$SEED.
The RDBMS DST version of PDB$SEED is the RDBMS_DST version at the CDB creation time (default is DSTv18 for 12.1.0.2 and 12.1.0.1).
The RDBMS DST version of PDB$SEED can currently not be updated.
NOTE! When connecting to PDB, you can NOT just run "conn / as sysdba"! Please change "conn / as sysdba" accordingly which appears in this note when updating RDBMS DST version of PDB.
CAUTION
This sample code is provided for educational purposes only, and is not supported by Oracle Support. It has been tested internally, however, we do not guarantee that it will work for you. Ensure that you run it in your test environment before using.
SAMPLE CODE
See the DBMS_DST_SCRIPTSV1.9 zip file for the scripts
SAMPLE OUTPUT
1) countstatsTSTZ.sql output
Example output of countstatsTSTZ.sql (some output removed):
SQL> CONN / as sysdba
SQL> @countstatsTSTZ.sql
.
Amount of TSTZ data using num_rows stats info in DBA_TABLES.
.
For SYS tables first...
Note: empty tables are not listed.
Stat date - Owner.Tablename.Columnname - num_rows
08/01/2015 - SYS.AQ$_ALERT_QT_S.CREATION_TIME - 5
08/01/2015 - SYS.AQ$_ALERT_QT_S.DELETION_TIME - 5
...
...
08/01/2015 - SYS.WRI$_OPTSTAT_HISTGRM_HISTORY.SAVTIME - 23519
08/01/2015 - SYS.WRI$_OPTSTAT_HISTGRM_HISTORY.SPARE6 - 23519
08/01/2015 - SYS.WRI$_OPTSTAT_HISTHEAD_HISTORY.SAVTIME - 21596
08/01/2015 - SYS.WRI$_OPTSTAT_HISTHEAD_HISTORY.SPARE6 - 21596
08/01/2015 - SYS.WRI$_OPTSTAT_IND_HISTORY.SAVTIME - 2814
08/01/2015 - SYS.WRI$_OPTSTAT_IND_HISTORY.SPARE6 - 2814
08/01/2015 - SYS.WRI$_OPTSTAT_OPR.END_TIME - 9
08/01/2015 - SYS.WRI$_OPTSTAT_OPR.SPARE6 - 9
08/01/2015 - SYS.WRI$_OPTSTAT_OPR.START_TIME - 9
08/01/2015 - SYS.WRI$_OPTSTAT_TAB_HISTORY.SAVTIME - 2364
08/01/2015 - SYS.WRI$_OPTSTAT_TAB_HISTORY.SPARE6 - 2364
Total numrow of SYS TSTZ columns is : 101667
There are in total 129 non-SYS TSTZ columns.
.
For non-SYS tables ...
Note: empty tables are not listed.
Stat date - Owner.Tablename.Columnname - num_rows
08/01/2015 - SYSMAN.AQ$_MGMT_LOADER_QTABLE_S.CREATION_TIME - 2
08/01/2015 - SYSMAN.AQ$_MGMT_LOADER_QTABLE_S.DELETION_TIME - 2
08/01/2015 - SYSMAN.AQ$_MGMT_LOADER_QTABLE_S.MODIFICATION_TIME - 2
08/01/2015 - SYSMAN.AQ$_MGMT_NOTIFY_QTABLE_S.CREATION_TIME - 2
08/01/2015 - SYSMAN.AQ$_MGMT_NOTIFY_QTABLE_S.DELETION_TIME - 2
08/01/2015 - SYSMAN.AQ$_MGMT_NOTIFY_QTABLE_S.MODIFICATION_TIME - 2
08/01/2015 - WMSYS.AQ$_WM$EVENT_QUEUE_TABLE_S.CREATION_TIME - 1
08/01/2015 - WMSYS.AQ$_WM$EVENT_QUEUE_TABLE_S.DELETION_TIME - 1
08/01/2015 - WMSYS.AQ$_WM$EVENT_QUEUE_TABLE_S.MODIFICATION_TIME - 1
Total numrow of non-SYS TSTZ columns is : 15
There are in total 27 non-SYS TSTZ columns.
Total Minutes elapsed : 0
SQL>
2) upg_tzv_check.sql output
Example output of a successful run of upg_tzv_check.sql :
SQL> CONN / as sysdba
SQL> @upg_tzv_check.sql
INFO: Starting with RDBMS DST update preparation.
INFO: NO actual RDBMS DST update will be done by this script.
INFO: If an ERROR occurs the script will EXIT sqlplus.
INFO: Doing checks for known issues ...
INFO: Database version is 11.2.0.3 .
INFO: Database RDBMS DST version is DSTv17 .
INFO: No known issues detected.
INFO: Now detecting new RDBMS DST version.
A prepare window has been successfully started.
INFO: Newest RDBMS DST version detected is DSTv18 .
INFO: Next step is checking all TSTZ data.
INFO: It might take a while before any further output is seen ...
A prepare window has been successfully ended.
INFO: A newer RDBMS DST version than the one currently used is found.
INFO: Note that NO DST update was yet done.
INFO: Now run upg_tzv_apply.sql to do the actual RDBMS DST update.
INFO: Note that the upg_tzv_apply.sql script will
INFO: restart the database 2 times WITHOUT any confirmation or prompt.
SQL>
Example output of a successful run of upg_tzv_check.sql but with a warning ( = non fatal issue) :
SQL> CONN / as sysdba
SQL> @upg_tzv_check.sql
INFO: Starting with RDBMS DST update preparation.
INFO: NO actual RDBMS DST update will be done by this script.
INFO: If an ERROR occurs the script will EXIT sqlplus.
INFO: Doing checks for known issues ...
INFO: Database version is 12.1.0.1 .
INFO: This database is a Multitenant database.
INFO: Current container is CDB$ROOT .
INFO: Updating the RDBMS DST version of the CDB / CDB$ROOT database
INFO: will NOT update the RDBMS DST version of PDB databases in this CDB.
WARNING: There are 1 open PDBs .
WARNING: They will be closed when running upg_tzv_apply.sql .
INFO: Database RDBMS DST version is DSTv21 .
INFO: No known issues detected.
INFO: Now detecting new RDBMS DST version.
A prepare window has been successfully started.
INFO: Newest RDBMS DST version detected is DSTv22 .
INFO: Next step is checking all TSTZ data.
INFO: It might take a while before any further output is seen ...
A prepare window has been successfully ended.
INFO: A newer RDBMS DST version than the one currently used is found.
INFO: Note that NO DST update was yet done.
INFO: Now run upg_tzv_apply.sql to do the actual RDBMS DST update.
INFO: Note that the upg_tzv_apply.sql script will
INFO: restart the database 2 times WITHOUT any confirmation or prompt.
SQL>
Example output of an unsuccessful run of upg_tzv_check.sql due known issue :
SQL> CONN / as sysdba
SQL> @upg_tzv_check.sql
INFO: Starting with RDBMS DST update preparation.
INFO: NO actual RDBMS DST update will be done by this script.
INFO: If an ERROR occurs the script will EXIT sqlplus.
INFO: Database version is 11.2.0.3 .
INFO: Database RDBMS DST version is DSTv14 .
INFO: Doing checks for known issues ...
ERROR: Unused TSTZ columns exist.
ERROR: ORA-00904 will be seen during DBMS_DST.
ERROR: See the known issues section of
ERROR: note 977512.1 for 11gR2 or note 1509653.1 for 12c .
ERROR: for bug 14732853 .
declare
*
ERROR at line 1:
ORA-20060: Stopping script - see previous message .....
ORA-06512: at line 241
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Example output of an unsuccessful run of upg_tzv_check.sql seen no newer dst patch has been found:
SQL> CONN / as sysdba
SQL> @upg_tzv_check.sql
INFO: Starting with RDBMS DST update preparation.
INFO: NO actual RDBMS DST update will be done by this script.
INFO: If an ERROR occurs the script will EXIT sqlplus.
INFO: Doing checks for known issues ...
INFO: Database version is 12.1.0.1 .
INFO: This database is a Multitenant database.
INFO: Current container is CDB$ROOT .
INFO: Updating the RDBMS DST version of the CDB / CDB$ROOT database
INFO: will NOT update the RDBMS DST version of PDB databases in this CDB.
INFO: There are no open PDBs .
INFO: Database RDBMS DST version is DSTv22 .
INFO: No known issues detected.
INFO: Now detecting new RDBMS DST version.
ERROR: No newer RDBMS DST patch has been detected.
ERROR: Check if a newer RDBMS DST patch is actually installed.
DECLARE
*
ERROR at line 1:
ORA-20070: Stopping script - see previous message .....
ORA-06512: at line 36
Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
3) upg_tzv_apply.sql output
Example output of a successful run of upg_tzv_apply.sql :
SQL> sys/oracle@pdb1db as sysdba
SQL> @upg_tzv_apply.sql
INFO: If an ERROR occurs the script will EXIT sqlplus.
INFO: The database RDBMS DST version will be updated to DSTv21 .
INFO: This database is a Multitenant database.
INFO: This database is a PDB.
INFO: Current PDB is PDB1DB .
WARNING: This script will restart the database 2 times
WARNING: WITHOUT asking ANY confirmation.
WARNING: Hit control-c NOW if this is not intended.
INFO: Restarting the database in UPGRADE mode to start the DST upgrade.
Pluggable Database closed.
Pluggable Database opened.
INFO: Starting the RDBMS DST upgrade.
INFO: Upgrading all SYS owned TSTZ data.
INFO: It might take time before any further output is seen ...
An upgrade window has been successfully started.
INFO: Restarting the database in NORMAL mode to upgrade non-SYS TSTZ data.
Pluggable Database closed.
Pluggable Database opened.
INFO: Upgrading all non-SYS TSTZ data.
INFO: It might take time before any further output is seen ...
INFO: Do NOT start any application yet that uses TSTZ data!
INFO: Next is a list of all upgraded tables:
Table list: "GSMADMIN_INTERNAL"."AQ$_CHANGE_LOG_QUEUE_TABLE_S"
Number of failures: 0
Table list: "GSMADMIN_INTERNAL"."AQ$_CHANGE_LOG_QUEUE_TABLE_L"
Number of failures: 0
Table list: "DVSYS"."AUDIT_TRAIL$"
Number of failures: 0
Table list: "APEX_040200"."WWV_FLOW_FEEDBACK_FOLLOWUP"
Number of failures: 0
Table list: "APEX_040200"."WWV_FLOW_FEEDBACK"
Number of failures: 0
Table list: "APEX_040200"."WWV_FLOW_WORKSHEET_NOTIFY"
Number of failures: 0
Table list: "APEX_040200"."WWV_FLOW_DEBUG_MESSAGES2"
Number of failures: 0
Table list: "APEX_040200"."WWV_FLOW_DEBUG_MESSAGES"
Number of failures: 0
INFO: Total failures during update of TSTZ data: 0 .
An upgrade window has been successfully ended.
INFO: Your new Server RDBMS DST version is DSTv21 .
INFO: The RDBMS DST update is successfully finished.
INFO: Make sure to exit this sqlplus session.
INFO: Do not use it for timezone related selects.
SQL>
Example output of an unsuccessful run of upg_tzv_apply.sql seen upg_tzv_check.sql was not executed:
SQL> CONN / as sysdba
SQL> @upg_tzv_apply.sql
INFO: If an ERROR occurs the script will EXIT sqlplus.
ERROR: UPG_TZV does not exist.
ERROR: You need to run upg_tzv_check.sql BEFORE upg_tzv_apply.sql .
ERROR: NO update of the DST version was done !
DECLARE
*
ERROR at line 1:
ORA-20215: Stopping script - see previous message .....
ORA-06512: at line 33
Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
REFERENCES
NOTE:1509653.1 - Updating the RDBMS DST version in 12c Release 1 (12.1.0.1 and up) using DBMS_DST
NOTE:412160.1 - Updated DST Transitions and New Time Zones in Oracle RDBMS and OJVM Time Zone File Patches
NOTE:977512.1 - Updating the RDBMS DST version in 11g Release 2 (11.2.0.1 and up) using DBMS_DST
| 附件 |
-
DBMS_DST_SCRIPTSV1.9