# Oracle Schema Migration — Database CI/CD for Oracle > An Oracle schema is a web of dependencies — alter one table and the packages, views, and triggers that reference it go INVALID. Bytebase puts Oracle change on a CI/CD pipeline: reviewed, staged so the invalidations surface first, approved, and audited across Enterprise, Standard, Autonomous, Exadata, and RDS. Source: https://www.bytebase.com/databases/oracle/schema-migration/ --- ## Your app ships through CI/CD. Your Oracle schema ships from SQL*Plus. A developer runs the ALTER in SQL*Plus against production — no review, no staging, no record. On Oracle that one change ripples: alter a column and every package, view, and trigger that references it goes INVALID, and DDL auto-commits, so there's nothing to roll back. Bytebase puts Oracle change on the same pipeline as your code — reviewed, staged so the invalidations surface before production, approved, and audited — from a Git pull request or the Bytebase UI. On Oracle the ungoverned path skips every check that keeps a change safe — and a change reaches further than the table it touches: ### One ALTER invalidates the schema Alter a column and every package, view, and trigger that references it goes INVALID across the schema. A hard reference to what you changed won't recompile at all — the app finds out at the next call with ORA-04068, not at deploy. ### The migration is PL/SQL Oracle changes aren't just DDL — they're packages, procedures, types, and anonymous BEGIN…END blocks, and an EXECUTE IMMEDIATE can hide DDL inside what reads as one statement. An ungoverned block runs whatever it contains. ### One change, many schemas Oracle runs the same schema across many users, and 12c multitenant fans every change across pluggable databases. By hand that's the same change re-run per schema or PDB; miss one and they quietly diverge. ### Environments drift Dev, staging, and prod diverge the moment one change lands outside the pipeline — and a dependent that exists in one environment can be missing or INVALID in the next. Without drift detection, you find out at deploy. ## Every change runs the same path. A change starts as a Git pull request or in the Bytebase UI — and from there the path is one, the same across Enterprise, Standard, Autonomous, Exadata, and RDS. The migration script is the same in every environment. What changes is the gate in front of each. ### Validate SQL review runs on the change before it applies — 200+ rules catch a DROP that orphans dependents, an anonymous PL/SQL block hiding DDL, a missing index, and naming violations. The ruleset is strict on production, relaxed on dev. ### Promote The migration applies in dev, then staging, then production — and across every schema or PDB in one rollout, not re-run by hand. The same change meets progressively more realistic data, so a cascade of invalid objects surfaces in staging, not first in production. A failure stops the chain. ### Approve Approval gates sit between stages. Routine changes auto-promote into dev; production-bound DDL waits for a human who sees the SQL, the review results, and the rollout plan in one record. ### Record Every applied migration is logged with version, environment, executor, and timestamp. Schemas are compared automatically, and a change made outside the pipeline triggers a drift alert. ## The invalidation cascade, caught before it runs. A developer drops a column nine packages and views depend on. SQL review reads it before anything runs: ``` -- V042__drop_legacy_orders_status.sql ALTER TABLE orders DROP COLUMN legacy_status; -- ⚠ SQL review (production ruleset) -- • DROP COLUMN destroys data — legacy_status is not archived first -- • invalidates 9 dependents that reference it; PKG_ORDER_API won't recompile ``` The same script promotes through dev and staging before a human approves it for production. Each environment keeps its own audit trail. ## Planned schema change — and it says so. The pipeline gates one class of work, and gates it well: planned schema change. Emergency hotfixes, one-off data patches, and a GATHER_TABLE_STATS during an incident don't arrive as a reviewed change — and forcing them through the pipeline only teaches people to route around it. ## Common questions. ### Does Oracle have built-in schema migration or versioning? No database does, really — versioning is a tool's job. Oracle has Edition-Based Redefinition for online rollout and SQLcl ships a Liquibase integration, but neither reviews the change, gates it behind approval, or keeps an audited history. The pipeline adds review, promotion, and audit on top. ### Will a change invalidate my dependent objects? It can — alter a table and the packages, views, and triggers that reference it go INVALID until they recompile, and a hard reference to something you changed won't recompile at all (the classic ORA-04068 in production). Bytebase doesn't recompile for you, but review flags the high-fan-out change and staged rollout surfaces the invalidations in a lower environment, not first in prod. ### How does it handle PL/SQL, not just DDL? The same way as any change: a package, procedure, type, or anonymous block is a versioned, reviewable migration. Review reads the whole block — including the EXECUTE IMMEDIATE that hides DDL inside PL/SQL — then the pipeline promotes and audits it like any DDL. ### Which Oracle deployments are supported? Any Oracle Bytebase can connect to — on-prem Enterprise, Standard, and Express, Autonomous Database, Exadata, Database@AWS, @Azure, @Google Cloud, and AWS RDS for Oracle. The pipeline runs in front of the database, so there's no edition or option requirement. ### Can it roll back a migration? Oracle DDL auto-commits and isn't transactional, so a failed multi-statement migration leaves the earlier statements applied — there's no rollback the way Postgres or SQL Server have. That's exactly why review and staged rollout matter before production. To reverse a change already applied, the down migration runs as its own reviewed, audited change. ## Get Started - [Contact us](https://www.bytebase.com/contact-us/) - [Start now (cloud)](https://console.bytebase.com)