Before transporting physical datafiles, identify both database platforms and choose a supported transport method. Endian format is the ordering of bytes within a multibyte value. A big-endian representation puts the most significant byte first. A little-endian representation puts it last. Correct conversion preserves the represented value while changing the required storage representation.
Oracle DBA Lesson 89 Part 1 — Platform and endian compatibility
For supported user-tablespace transport, matching endian formats normally avoid endian conversion. Different endian formats require conversion through a supported workflow. Neither result establishes every other compatibility requirement.
Identify the source and target
Read the connected database's platform and its endian format:
SELECT d.platform_name, p.endian_format
FROM v$database d
JOIN v$transportable_platform p
ON p.platform_id = d.platform_id;V$DATABASE identifies the connected database's platform. Joining its PLATFORM_ID to V$TRANSPORTABLE_PLATFORM supplies that platform's endian format. Running this query at the source describes the source. It does not discover an unconnected target.
List the platforms supported for cross-platform transport:
SELECT platform_id, platform_name, endian_format
FROM v$transportable_platform
ORDER BY platform_name;V$TRANSPORTABLE_PLATFORM lists platforms supported for cross-platform tablespace transport and the RMAN CONVERT TABLESPACE command. Locate the exact target entry. Verify the target's actual platform by running the identity query there, or from a verified platform inventory. A familiar operating-system family name is insufficient to establish an exact platform match. Stop if the platform is absent or its format is unknown, and investigate a documented alternative rather than guessing a platform string.
These queries inspect information. They do not perform conversion, transport, or a compatibility certification.
See V$DATABASE and V$TRANSPORTABLE_PLATFORM.
Compare endian formats
A source platform of Linux x86 64-bit has endian format Little. Compare these documented platform entries:
| Target platform | ID | Format | Endian decision for ordinary user tablespaces |
|---|---|---|---|
Microsoft Windows x86 64-bit | 12 | Little | Matching endian; no endian conversion required |
Solaris[tm] OE (64-bit) | 2 | Big | Different endian; conversion required |
The operating systems differ in both rows. The deciding property for endian conversion is byte order. Other restrictions must still pass before either move proceeds.
A two-byte diagram of the value 0x1234 shows the storage order. Big-endian bytes are 12 34. Little-endian bytes are 34 12, in increasing storage-address order. This is not the internal layout of Oracle's NUMBER datatype, a datafile block dump, or an instruction to reverse every byte in a file. Use Oracle's supported conversion tools, which understand the relevant file structures.
See Transporting Data.
Choose conversion within a complete method
RMAN can convert transported tablespace files on the source or the destination. Source-side conversion commonly uses CONVERT TABLESPACE ... TO PLATFORM. Destination-side conversion uses CONVERT DATAFILE ... FROM PLATFORM. The exact operands, file manifest, connection scope, and prerequisites depend on where conversion occurs. Documented cross-platform backup-set workflows provide another route, with their own rules. Do not combine steps from different procedures into an assumed universal recipe.
Keep original source files and write converted copies into separate, verified staging storage. Reserve capacity for the source, converted, and backup artifacts retained concurrently. Measure conversion and transfer time rather than treating conversion as free. Match transported files and metadata to the required consistent source state. Preserve the containment and target checks from the preceding transport lessons.
Before committing to the method, resolve:
- Source and target Oracle releases, Release Updates,
COMPATIBLEsettings, and the method's minimum requirements. Tablespace transport can fail when source compatibility exceeds target compatibility. An installed release number alone is insufficient. - Database and national character set compatibility, including the documented subset, length-semantics, and datatype conditions where relevant. Endian conversion is not a character set migration.
- Transport scope and supported files. User tablespaces, full transportable export/import, an RMAN whole-database move, and a pluggable-database move have different rules.
- Encryption and key handling. Oracle's transportable-tablespace restrictions require the same endian format for an encrypted tablespace. The documented decrypt, transport, and re-encrypt alternative needs its own planned procedure. Ordinary datafile conversion does not remove the restriction. Tables with encrypted columns have further limitations.
- Supported object and datatype conditions, containment, block-size configuration, target name conflicts, file accessibility, capacity, and entitlement for the exact feature. Opaque application-specific binary contents may need application handling of endian differences. Oracle cannot infer their private structure.
Whole-database transport needs its own preflight. RMAN whole-database cross-platform transport requires the same endian format. Even with matching endian formats, files containing undo require RMAN conversion. There are additional platform-specific rules, including documented Tru64 ASSM-header cases. This is distinct from full transportable export/import, which carries user datafiles physically and eligible administrative content logically into a target with its own dictionary files.
An available command or view does not establish edition, offering, or licence entitlement. See Transporting Data, Transporting Data Across Platforms, CONVERT, and Licensing Information.
No comments:
Post a Comment