Before you migrate: scope, cleanup, compatibility checks
Assess complexity and plan the team. Tibero recommends organizing database/application migration and testing teams, then sizing the project by object count and dependency complexity. Low‑complexity cases have a few users and simple dependencies; high‑complexity cases have many users, complex dependencies, and INVALID objects. Cleaning up INVALID objects in the source DB reduces validation time because errors in the source will surface again in Tibero.
Pick the right character set (important for JP/SEA/US). Tibero supports UTF8 and regional sets including JA16SJIS/JA16EUC for Japanese, TH8TISASCII for Thai, VN8VN3 for Vietnamese, and WE8MSWIN1252/ISO‑8859‑1 for Western European/English. Selecting a Tibero character set that corresponds to your Oracle character set is part of pre‑migration planning.
Confirm data type compatibility. Tibero provides an Oracle↔Tibero type mapping (e.g., VARCHAR2, NUMBER, DATE, TIMESTAMP). Two notable points:
- BFILE is not supported; use BLOB instead.
- XMLTYPE is supported, but creation syntax differs (Oracle uses SYS.XMLTYPE, Tibero uses XMLTYPE).
Analyze compatibility with T‑UP. Tibero’s pre‑migration workflow includes running a T‑UP analysis to validate compatibility before you move data/objects. The docs show the analysis and report flow you can expect.
Choose a migration method (mix and match for downtime, scale, and control)
Tibero documents five approaches. You can combine methods to minimize cutover time and tailor for data volume and operational constraints. The docs include guidance on when to prefer each.
A. T‑UP (GUI‑driven logical migration)
- Connects to the source Database and Tibero over JDBC; requires the source and Tibero JDBC drivers and a JDK/JRE.
- Data travels source DB → T‑UP → Tibero (two network hops), so for very large migrations it may be less advantageous.
- Supports whole, user, or table‑level migrations with a GUI; continues through issues and resolves after completion.
Use when: You want an easy, GUI‑based path—often in simple migrations or paired with manual object migration.
B. Table Migrator (command‑line, large‑table friendly)
- Command‑based tool that connects to both systems via JDBC; JDK/JRE and both JDBC drivers required.
- No intermediate server; can run on the source DB server or the Tibero server—so data crosses the network once.
- Optimized for moving one table at a time; supports conditional clauses and partitioned tables.
- Prerequisite: Create target tables in Tibero first before running Table Migrator.
Use when: You need controlled, large table moves or DB Link setup is complex.
C. DB Link (direct copy between Oracle and Tibero)
- Create a DB Link on the source or on Tibero; no intermediate server, so data crosses the network once.
- Works best at single‑table granularity (good for large tables).
- Prerequisite: Configure DB Link before migrating. If the source is Oracle, Tibero docs recommend configuring “Tibero → Oracle” because it has fewer limitations; see the DB Link Guide for setup.
Use when: You want straightforward network‑direct migration table by table—especially from Oracle.
D. tbLoader (bulk load from text/SAM files)
- Convert data to a SAM (text) file and load it in one operation; advantageous for large data.
- Prerequisite: Create the SAM file on the source DB and copy it to the Tibero server before running tbLoader.
Use when: Your source systems can produce flat files efficiently and you want predictable, batched bulk loads.
E. Manual migration (script‑first, repeatable)
- Extract DDL scripts using a client tool and apply to Tibero manually; data then migrates with a tool such as T‑UP.
- Lets you resolve issues step by step and automate via shell scripts for repeated moves.
Use when: Complexity is high, you need repeatable runs, or you must script a very controlled cutover.
Method selection quick guide (from the docs):
- T‑UP: GUI tool for simple total/user modes or pair with Manual.
- Table Migrator: Large tables, DB Link is complex.
- DB Link: Large tables when Table Migrator isn’t applicable.
- tbLoader: When you can produce SAM files.
- Manual: High complexity or repeated migrations over a period.
Executing the move: doc‑aligned patterns
Pattern 1 — Table Migrator flow (Oracle → Tibero).
The docs include a full execution example that creates a test tablespace/user/table in Oracle and performs a Table Migrator run into Tibero. Follow the docs’ execution method (edit migrator.sh/.bat, ensure the source JDBC driver is on the classpath) and the parameter configuration (e.g., set source type ORACLE, or GENERIC with SOURCE_DRIVER for non‑Oracle).
Pattern 2 — DB Link flow (Oracle source).
Per docs, set up the DB Link first; when the source is Oracle, prefer Tibero→Oracle configuration for fewer limitations, then move table‑by‑table. (If you use the Tiberostudio GUI, the DB Link creation steps and a built‑in link test are documented.)
Pattern 3 — Bulk file flow with tbLoader.
Generate SAM files from the source, copy them to the Tibero server, and load them with tbLoader. The tbLoader guide explains control/data/log/error files, control‑file options (e.g., FIELDS TERMINATED BY, CHARACTERSET), and examples.
Pattern 4 — Logical dump/restore with tbExport/tbImport.
For logical backups or cross‑machine transfers, Tibero provides tbExport/tbImport with full, user, and table modes. These utilities extract/import schema metadata and data; related objects (constraints, indexes) move together.
After the move: validate objects and constraints, then wire up apps
Validate object and constraint counts.
The Tibero “Validation” chapter (in the upgrade guide, but applicable as a technique) shows comparing counts on the target DB using DBA_TABLES, DBA_VIEWS, DBA_INDEXES, DBA_CONSTRAINTS, DBA_TRIGGERS, etc. Use it to quickly spot mismatches after migration.
Connect applications with tbJDBC (and enable HA behaviors).
The JDBC Developer’s Guide details DataSource properties and connection URLs. For resilience, Tibero documents failover (e.g., FAILOVER=SESSION or CURSOR) and load balancing via description‑style JDBC URLs—e.g., add (failover=session) with multiple (address=…) entries, or (load_balance=on) to spread connection initiations across nodes. See the exact property lists and examples in the docs.
Putting it together—Doc‑based migration checklist
- Pre‑migration
- Inventory users/objects; remove INVALID objects in source.
- Decide the Tibero character set; review Oracle↔Tibero type mapping (handle BFILE/XMLTYPE).
- Run T‑UP analysis to gauge compatibility hotspots.
- Method selection
- Pick Table Migrator for large tables (create target tables first).
- Use DB Link for direct table‑by‑table copy; with Oracle source, prefer Tibero→Oracle linking.
- Choose tbLoader when you can stage SAM files.
- Combine with T‑UP/Manual where appropriate.
- Execution
- Follow the docs’ execution method/parameters for Table Migrator; ensure JDBC drivers/JDK are in place.
- For tbLoader, prepare control/data files per the guide.
- For tbExport/tbImport, select the correct mode (full/user/table).
- Post‑migration
- Compare object/constraint counts using the DBA_* views listed in the validation chapter.
- Configure tbJDBC DataSource/URL with failover (and optionally load balancing) per the examples.
* Sources: Tibero Docs(https://docs.tmaxtibero.com/tibero/en)
