Which Oracle workloads belong in the warehouse migration?
Name the analytical consumers and trace the tables, views, materialized outputs, packages and schedules that serve them. Distinguish reporting transformations from transactional application behavior. A package invoked during the warehouse run may also update operational state or call an external system, so its responsibility needs an explicit disposition.
Record the source database and client versions, data types, execution identity, session settings and the business calendar. Include dependencies outside the main schema: file exchanges, database links, reporting gateways and application-owned reference data. The boundary is the part of the estate that can be understood and accepted as one migration scope.
For an Exadata source, collect the actual workload and operational constraints rather than deriving a target design from the appliance name. Identify peak concurrency, long-running extracts, critical refresh windows and the source services that remain in use. The modernization service connects this inventory to a sequenced estate-level decision.
- 01
Warehouse calculation
The output is an analytical dataset with a defined grain.
Compare a target calculation against typed source results.Example: a reporting view and its business-date calculation.
- 02
Mixed package
A PL/SQL caller combines calculation, mutable state and side effects.
Separate the responsibilities and disposition each caller path.Example: a package both builds a report and records an external delivery.
- 03
Application transaction
The behavior belongs to an operational write path.
Retain or scope that application change separately.Example: an application transaction that happens to feed reporting.
Illustrative scope routing. Exadata describes source context; it does not turn every Oracle responsibility into an analytical warehouse workload.
Where can null and empty-field meaning be lost?
Keep SQL nulls, serialized empty fields and whitespace distinguishable through extraction and loading. Record what each representation means for the source column and the consumer. Oracle's Python driver documents binding None as a SQL NULL for character data; the file format and target loader still need their own explicit mapping.
The illustrative fixture below applies a declared missing-customer-code policy to four transport values: an explicit null marker, an empty field, one space and A. The assumed contract treats the first two as missing and preserves the space. A target check that counts only the explicit marker reports one missing value instead of two.
This is a transport-and-consumer contract example, not a measured Oracle or Snowflake engine result. Test the actual Oracle column, driver representation, serialization settings and target input format before selecting a normalization. Keep leading/trailing spaces meaningful where the business requires them; indiscriminate trimming can turn a reconciliation fix into another data change.
Illustrative missing-code contract: the explicit null marker and empty field are missing; one space is preserved. This is a declared policy, not a server-default test.
- 01
NULL marker - 02
empty field - 03
one space - 04
A
Declared missing set
2 values
Explicit null marker and empty field.
Marker-only check
1 value
The empty field falls outside the missing population.
Whitespace retained
1 space
The stated contract keeps its meaning visible.
Trace the Oracle column, driver value, file representation and loader setting before adopting a normalization. Keep meaningful spaces intact.
How should PL/SQL and application dependencies be classified?
Separate the relational calculation from procedural control, mutable state and side effects. Classify each package or procedure by the behavior its callers depend on. A replacement can be accepted only when those responsibilities have a named target component or a deliberately retained source owner.
Keep sequence/key behavior and package state in the inventory where consumers depend on them. Reproducing a numerical result does not establish the same concurrency or side-effect behavior. Use the Snowflake migration service to frame a bounded analytical scope with those responsibilities visible.
Keep procedural state and externally visible actions in a caller-oriented record. A package may share a name with a target procedure while differing in state, error handling or the side effects its caller expects. Separate the target's relational result from the component responsible for external action and retain the evidence needed to accept each. Do not make a warehouse scope silently responsible for an application rewrite.
| Dimension | Disposition question | Evidence needed |
|---|---|---|
| Relational transformation | Which rows and business calculations does the statement produce? | Typed expected outputs, null cases, joins and aggregation boundaries. |
| Procedural dependency | Does the package branch, keep state, publish a file or call another system? | Callers, branch outcomes, transaction boundaries and side-effect ownership. |
| Application transaction | Does the workload participate in an operational write path? | An explicit application boundary and a separate disposition for that behavior. |
| Extraction consistency | Which source state and subsequent changes are represented? | Consistent-load reference, change boundary and update/delete coverage. |
| Exadata context | Which observed workload properties affect the target decision? | Representative query mix, concurrency and publication-window evidence. |
What defines a consistent first load and change handoff?
Define the source state the first load represents and the point from which later changes are applied. Align related tables to that consistency model. Extracting each table successfully at unrelated times can produce a destination state that never existed as one coherent source view.
Record the capture or extraction method actually available, its permissions, retained history and treatment of committed updates and deletes. Include a late correction and a changed parent/child relationship in the comparison. A connector's ability to fetch rows is separate from the consistency and change-capture guarantees selected for the workload.
If extraction or application of changes stops, identify the checkpoint and the source history needed to resume. Compare a restart with the accepted consumer state, not just with a job's green status. The pipeline reliability guide explains why publication and restored consumer state belong in that evidence.
Use one consistent analytical reference for the comparison rather than independently timed source and target queries. Record what the selected extraction mechanism represents and how later changes are included or excluded. The handoff map deliberately leaves the mechanism open: a source version, available change history, operating constraints and the actual connector must determine it. The CDC, batch and streaming guide explains the different movement contracts.
- Source stateReference state recorded
Identify the analytical population and represented business boundary.
- Typed candidateChanges accounted for
Include updates/deletes within the chosen extraction method's scope.
- Accepted reportApplication owner retained
Keep transactions and side effects outside the warehouse scope assigned.
- Source stateTypes represented
Retain column, driver and serialization settings.
- Typed candidateMeaning compared
Check missing fields, precision, keys and date assignment.
- Accepted reportCandidate version fixed
Connect the target output to the source reference and its evidence.
- Source stateExisting report authoritative
A target load does not itself switch application behavior.
- Typed candidateActual identity checked
Compare report filters, allowed population and refresh boundary.
- Accepted reportReference acknowledged
Name recoverable data state and external actions outside it.
Illustrative analytical handoff. This is not a tested SCN/CDC recipe or a replacement design for Oracle application transactions.
Which outputs should the consuming team compare?
Compare the report, extract or governed dataset at the same business cutoff with its actual identity and filters. Include component values, missing-value populations, numeric scale, key relationships and time assignment. An administrator's successful query and a matching grand total leave many consumer-level differences untested.
Retain the input snapshot, transformation revision, session/context settings, output revision and expected values for each boundary fixture. Keep differences grouped by their effect: missing records, changed meaning, access discrepancies, freshness failures or unsupported dependencies. That makes the switch decision explainable.
Define the last recoverable publication and which operational effects remain outside a dataset restore. A target report may be reverted while an already exported file remains in circulation. Follow the warehouse migration playbook for the dependency-wave structure, and use the workflow below to make this Oracle consumer's acceptance concrete.
- 01Bound the scope
Separate analytical calculations from operational transactions.
Keep: consumer, package callers and external effects.
- 02Align the source state
Define the first-load reference and subsequent change boundary.
Keep: extraction method, history and update/delete coverage.
- 03Compare typed outputs
Reconcile missing values, precision, keys and date assignment.
Keep: source/target context and accepted result fixtures.
- 04Move the consumer
Switch the reporting reference with an owned recovery path.
Keep: publication versions, acknowledgement and exclusions.
Retain a separate disposition for operational side effects. Restoring an analytical table cannot prove that an external action has been reversed.
How should the destination design and economics be evaluated?
Evaluate the destination against equivalent analytical queries, representative concurrency, required freshness and the actual access model. Separate storage, ingestion, transformation, serving and operating effort in the comparison. An Exadata workload profile is evidence to bring into that evaluation, not a direct target sizing formula.
Keep data distribution and query conditions with observations. Compare the same reporting question and include source/target overlap, data transfer and any retained Oracle responsibilities. License implications depend on actual agreements and the estate that remains, so a warehouse migration guide cannot establish a license saving.
Use the Snowflake platform page for destination roles and the cost assessment for a bounded economic evidence request. State the measured workload range before generalizing a result to other applications or peak periods.
For an Exadata-backed workload, retain observed concurrency, query mix, refresh dependencies and source services that continue to run. Keep those observations separate from assumptions about target hardware or license savings. The edge cases below add identifier representation and business-date assignment to the missing-value fixture; each can change a consumer result even when the same rows reach the destination.
Illustrative expectations are defined by the consumer. No Oracle or Snowflake default is inferred from these inputs.
- 01
Missing versus meaningful space
Input / conditionNULL marker, empty field, one space, A
Expected contract2 missing values; the space stays distinct
Evidence to retainRetain source column, driver values, file markers and target input settings.
- 02
Key versus numeric display
Input / conditionBusiness identifier 00123
Expected contract00123 if the identifier contract preserves its text
Evidence to retainCompare the consumer key and joins; matching a display of 123 is insufficient.
- 03
Time versus calendar assignment
Input / conditionOne event near the reporting-day cutoff
Expected contractThe business date determined by the declared timezone/calendar
Evidence to retainKeep the event representation, zone rule and expected report date together.
Treat a changed identifier or business date as a result difference, even when row counts and displayed totals happen to match.
What makes an Oracle migration brief actionable?
Provide a representative analytical consumer, its package and data dependencies, the source context, a consistent accepted output and the required publication window. Include one meaningful null or precision edge case, the change-handling method and the person or function accountable for the consumer's definition.
Use synthetic records when the source contains personal or commercially sensitive data. Identify application write paths and external effects early so the assessment can give them an explicit disposition. A bounded brief can then connect source responsibilities to target choices without implying that the whole application estate moves with its warehouse tables.
For a different source, compare the Teradata migration guide and Netezza migration guide. Their worked examples address other failure modes; keep each source's semantics and extraction assumptions attached to its own scope.
Questions and trade-offs
Does moving an Oracle warehouse also replace the application database?
Only if that separate application scope has been explicitly defined and justified. This guide addresses selected analytical data, processing and consumers. Operational transactions, package side effects and application integrations need their own disposition and acceptance evidence.
Use the package's callers to identify the boundary. A report-generating branch and an operational-write branch can need separate dispositions even when they share a source package. Retain side effects, transaction assumptions and recovery exclusions with those decisions.
What does an Exadata source change in the migration assessment?
Exadata belongs in the source performance and operating context. Capture the analytical workload, concurrency, extraction constraints, refresh dependencies and Oracle services that remain in use. Use that evidence to select and compare a target design; the appliance name alone does not establish a one-to-one Snowflake implementation.
Keep performance observations separate from application responsibilities and extraction scope. A fast isolated query can still sit in a dependency chain that misses the reporting window. Compare the accepted consumer boundary before interpreting query speed or operating-cost observations.
Can null handling be fixed by trimming every string?
That changes values and can erase meaningful whitespace. Define the source-column and transport contract, then test explicit null markers, empty fields and spaces separately. The fixture's missing-code policy is illustrative and should not be applied automatically to every column.
Record the actual source column and extraction representation before deciding what an empty field means. Include a space and a leading-zero identifier in the comparison pack where the consumer treats them as meaningful. A transport-only normalization can change joins or filters downstream.
Can a duration or license saving be estimated from the table count?
Table count omits package behavior, extraction constraints, data/change volume, consumer dependencies and retained application responsibilities. Scope those inputs and the relevant agreements before producing an estimate. No fixed duration or license saving is established by this guide.
Retain the assumptions behind an estimate: source features represented, dependencies left outside the sample, source/target overlap, and the evidence still needed to accept a consumer. A change to that boundary should change the estimate rather than disappear into an unexplained contingency.
How should a large PL/SQL estate be assessed?
Start with the packages, procedures and callers that serve one analytical consumer. Classify calculation, control flow, mutable state, transaction assumptions and external effects. Then record the represented source features and their target or retained owners.
Use this decomposition to select a representative sample for conversion and comparison. A count of packages or lines of SQL does not identify the difficult behaviors, and an emitted target procedure is still a candidate until its represented contract is checked.
What determines whether batch or CDC is appropriate?
The consumer's required freshness, available source history, consistent-load method, update/delete coverage and operating constraints determine the choice. Name the source/client/connector versions and the target publication boundary before selecting a mechanism.
Retain a late correction and a partial-run case in the acceptance pack. A low-latency change feed is useful only when the resulting data product has a defined state, completeness rule and restart behavior.
How should Oracle migration effort and cost be estimated?
Estimate the analytical and application responsibilities separately. Include procedural exceptions, extraction/change volume, data-type comparisons, access, consumers and operating dependencies. Keep source/target overlap, retained Oracle services and target running cost as explicit lines.
Base the first estimate on a representative permitted workload and record assumptions. An Exadata label, table count or synthetic example does not establish a project price, licensing saving or delivery deadline.
Which report comparisons should run before switching?
Compare accepted source and target output at the same business boundary using the actual report identity. Include missing values, leading-zero identifiers, precision/rounding, keys, timestamp/calendar rules and the permitted record population. Compare component values as well as totals.
Keep discrepancy records with an owner and a disposition. A matching administrator query does not establish that the scheduled report or application follows the same access, filter and refresh path.
