When evaluating an Oracle-to-GBase Database migration, one number often gets attention:
95% Oracle-mode syntax compatibility for GBase Database(GBase 8s).
But the more important question isn't the percentage.
It's:
What happens to the remaining 5%?
A compatibility percentage is useful for estimating migration effort, but real migration complexity depends heavily on which Oracle-specific features your application actually uses.
What Can Usually Migrate Directly?
A large amount of common Oracle SQL and procedural syntax can be handled through the Oracle-compatible direction of GBase Database(GBase 8s).
For example, a typical PL/SQL-style procedure may look like:
DECLARE
CURSOR c IS
SELECT * FROM log WHERE status = 'ERROR';
BEGIN
FOR r IN c LOOP
INSERT INTO archive_log
VALUES (r.log_id, r.msg, SYSDATE);
END LOOP;
COMMIT;
END;
For workloads relying primarily on standard SQL, common procedural syntax, tables, indexes, views, and conventional database objects, the migration path can be relatively straightforward.
But "95% compatible" does not mean "95% of your application requires no testing."
That's an important distinction.
What Usually Requires More Attention?
The remaining compatibility gap often comes from Oracle-specific functionality rather than basic SQL syntax.
Common areas to investigate include:
Oracle-Specific Packages
Applications that depend heavily on packages such as:
DBMS_SCHEDULER
DBMS_STATS
DBMS_*
may require additional assessment and replacement strategies.
Hierarchical Queries
Oracle-specific constructs such as:
SELECT ...
FROM employees
START WITH manager_id IS NULL
CONNECT BY PRIOR employee_id = manager_id;
may require rewriting depending on the target implementation and query requirements.
Recursive CTEs are one possible approach, but the correct rewrite depends on the actual query logic.
Optimizer Hints
Oracle applications sometimes contain proprietary hints such as:
/*+ PARALLEL(8) */
These should not simply be copied and assumed to have the same effect.
The corresponding GBase Database(GBase 8s) execution and optimization behavior needs to be validated separately.
Compatibility Is More Than Syntax
This is where many migration projects underestimate the work.
A database migration isn't just:
Oracle SQL
↓
GBase Database
A more realistic migration assessment looks like:
SQL Syntax
↓
Stored Procedures
↓
Oracle Packages
↓
Database Objects
↓
Drivers / Interfaces
↓
Operational Scripts
↓
Performance
You can have high SQL compatibility and still encounter significant migration work in application code, stored procedures, operational tooling, or performance tuning.
How Should You Assess a GBase Database Migration?
Don't manually inspect thousands of objects one by one.
Start with an automated assessment.
GBase Database provides MTK for migration assessment and related migration tasks. Use the assessment to identify:
- Incompatible SQL
- Oracle-specific objects
- Stored procedure dependencies
- Proprietary packages
- Potential conversion issues
Then classify the results into three groups:
Can migrate directly
↓
Can be automatically converted
↓
Requires manual rework
This gives you a much more useful number than a generic compatibility percentage.
The Real Question Behind "95%"
The value of the 95% Oracle compatibility figure isn't that it guarantees a 95% migration with zero effort.
Its real value is that it indicates a substantial compatibility foundation for Oracle migration scenarios.
The next question should always be:
"Where is my application's remaining 5%?"
If that 5% consists mostly of non-critical features, migration may be relatively straightforward.
If it contains your most important stored procedures, proprietary packages, or performance-critical SQL, the actual migration effort can be much higher.
That's why a proper GBase Database(GBase 8s) POC should test your real schema and real application workload—not just a compatibility checklist.
When migrating from Oracle, which causes more problems in your experience: SQL compatibility, stored procedures, proprietary packages, or performance tuning?
