Database Upgrade using Transportable Tablespaces

Upgrade methods

• DBUA
• Data Guard Logical Standby
• Streams
• Transportable Tablespaces (TTS)
• Data Unload / Reload

  • Data Pump, External table load CTAS/IAS

Which One to Use?

• DBUA
  • Simplest, safest – Test this first
• Data Guard Logical Standby (10.1.0.3 and later)
  • If DBUA does not meet outage window
  • Transient logical standby can use existing physical standby
• Streams (9.2 and later)
  • If you already use Streams
• TTS
  • If logical standby / Streams have data type support issues
  • Best with simple schemas

Something to Consider

• Data remains in place in data files
  • Bad practices brought forward to new version
  • Some attributes cannot change without reload
    • For example, warehouse on Exadata – 4MB ASM AU size, Large extents (8MB), Table compression, Partitioning scheme
• “Minimize downtime” is a goal
  • Yes, but implementing best practices may be more important
  • Unload / Reload (Data Pump, CTAS/IAS)

Database Upgrade using TTS

• Fast* upgrade to new database version
  • Patch set upgrades or major release upgrades
  • Use when datafiles can be used in place, and
  • Use when database has simple schemas
• Compared to DBUA
  • Pro: No waiting for upgrade of installed options / components
  • Pro: Will be faster for simple schemas
  • Con: Requires more manual steps
  • Con: Very large number of schema objects may not be faster

What is TTS?

• Method of copying tablespaces from one database to another
  • Data is not touched – data files are copied
  • Object metadata is unloaded from source, loaded into target
    • Export/Import, or Data Pump
  • Copy user data
    • Cannot transport SYSTEM, SYSAUX, UNDO, TEMP
  • TTS set must be self-contained
• Source and target can be different versions
• In 10g, source and target can be different platforms

10.2.0.4 primary with physical standby upgrade to 11.1.0.6.  Here are the high-level steps:
Assume 10.2 source primary database and physical standby for it
Create 11g target primary database shell
Create physical standby database for target (set standby_file_management=auto)
Create metadata required for TTS in target primary (users, roles, etc)
Export source primary database metadata
Disconnect sessions from source primary
Make source primary tablespaces read only
Switch logfiles on source primary and ensure source standby is caught up
TTS export from source primary
Copy source primary datafiles into place for target primary
Copy source standby datafiles into place for target standby
TTS import into target primary (once this redo is replayed, TTS import occurs on standby)
Tablespaces read write on target primary
Finish remaining steps for database metadata, sequences, system privs, invalid objects

© 2010, www.oracledatabase12g.com. 版权所有.文章允许转载,但必须以链接方式注明源地址,否则追究法律责任.

相关文章 | Related posts:

1. Upgrading to RAC 11g R2 What you should know
2. How we created a clone database from the datafiles image copies of a physical standby database
3. Upgrade to Oracle Database 11g:Single Instance to RAC & ASM
4. Upgrade from Oracle Database 10g to 11g:What to Expect From the Optimizer
5. How to create a GoldenGate uni-directional target database in a production database zero downtime
6. Oracle Database 11g: High Availability Student Guide
7. Oracle Database 11gR2 Upgrade Companion
8. Best Practices for Automatic Failover Using Oracle Data Guard 10g Release 2
9. Database Links: Troubleshooting ORA-2085 “database link %s connects to %s”
10. Oracle Database 10g Upgrade Companion