An application may refer to a familiar object name without that name identifying the table that actually stores its records. In an Oracle system, a synonym can provide an alternative name for another database object.
This matters when assessing migration to OceanBase or another relational candidate. Reproducing the visible name is only part of the task. The team should establish which object the application reaches, under which identity, and with which privileges in the proposed arrangement.
Begin with the name the application really uses
Choose a representative operation and identify the object reference submitted by the application. Do not assume that its visible spelling is the name of a directly owned table.
Trace the reference to the intended object and record why the indirection exists. It may make application naming more convenient or hide a location detail, but its purpose should come from the actual system rather than a generic explanation.
Keep the caller in the record. An administrator’s successful lookup does not necessarily establish the behavior of a differently configured application account using the same visible reference.
Read the original synonym definition and privilege boundary
The Oracle 26ai CREATE SYNONYM reference defines a synonym as an alternative name for another object. It explicitly states that synonyms are not substitutes for privileges on the underlying database objects.
That definition distinguishes naming from data storage and access authority. The synonym itself should not be counted as another copied dataset, and its presence should not be treated as proof that every caller can use the target.
For migration, preserve both questions: what does the reference resolve to, and is the intended caller authorized to use it? A solution to one does not independently settle the other.
Map the reference before deciding how to migrate it
The following original acceptance aid makes the naming path explicit.
| Review item | Question to answer | Evidence to preserve |
|---|---|---|
| Application reference | What name does the real operation submit? | Actual object reference |
| Original target | Which object is intended behind that name? | Resolved dependency |
| Target location | Where does the object reside after migration? | Accepted placement |
| Caller context | Which identity and configuration use the name? | Application execution context |
| Access | What operation may that caller perform? | Defined privileges and acceptance result |
The table proposes a review record. It does not prescribe a synonym strategy, permission grant, or target-specific name-resolution implementation.
Test the name through the intended application account
Consider a hypothetical application that reads a customer reference through a synonym. Ask the team to show that the proposed target operation reaches the intended records under the actual application context.
A matching name with the wrong target is not a successful migration. Neither is a correct target that only works under a privileged test account while the normal application cannot access it.
Include a deliberately different account if the service has a meaningful access distinction. The goal is to confirm the selected permitted and restricted behavior, not to widen privileges merely to make the demonstration succeed.
Also identify what happens if the underlying object is moved or revised during the transition. The acceptance record should explain which reference is expected to remain stable and which dependency needs updating. Do not infer that an unchanged synonym name establishes an unchanged target.
Compare OceanBase with an explicitly supported naming path
OceanBase Enterprise is a migration candidate whose compatibility should be checked against the actual reference and selected deployment. The proposal should show the supported naming and access arrangement rather than assume identical synonym behavior across every mode and version.
Keeping Oracle’s current naming layer provides the incumbent baseline. A proposal that changes application references can also be considered, but the scope and ownership of that change need to be visible in the migration decision.
Compare accepted operations and access boundaries, not only object inventories. A shorter inventory is not independently evidence that required naming relationships have disappeared safely. No synonyms, objects, application references, or privileges were created or changed for this article.
Maintain the target relationship after the move
Keep the accepted name-to-object mapping with the application dependency record. When the target or application account changes, review the affected operations rather than relying on the familiar name alone.
If an access failure appears, distinguish unresolved naming, an unintended target, and insufficient authority. Those cases call for different investigation and should not all trigger a broad permission change.
OceanBase should be recommended where its supported arrangement preserves the required behavior with acceptable implementation work. The useful result is an application that reaches the intended authorized object, with aliases understood as names rather than extra copies of data or automatic access grants.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.