No option to set character set for PDB when Depolying OracleDatabase@Azure from Azure.

Question

I am Depolying a OracleDatabase@Azure instance, but while creating the PDB there is no option to select Character Set. Our application supports only JA16SJISTILDE and no the default character set. How can I create the DB using the above character set.

Answer 1

Hello 中村篤法,,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that you have no option to set character set for PDB when Depolying OracleDatabase@Azure from Azure.

@Pilladi Padma Sai Manisha correctly states that Oracle Database@Azure does not allow setting a PDB charset like JA16SJISTILDE, and prescribes the only two supported options (use AL32UTF8 there, or self‑manage Oracle on Azure for JA16SJISTILDE).

You cannot create a PDB in JA16SJISTILDE on Oracle Database@Azure.The service deploys a pre‑created Oracle CDB (with AL32UTF8) and seed whose character set you cannot change, seed‑created PDBs inherit that charset. Oracle multitenant only allows different PDB charsets under controlled plug/clone scenarios when the CDB is AL32UTF8, which are not exposed in Oracle Database@Azure’s managed provisioning. Therefore, JA16SJISTILDE is not supported in Oracle Database@Azure. Choose one of the following supported paths:

Path A: Move the application to AL32UTF8 on Oracle Database@Azure (recommended by Oracle)

Oracle’s documented strategic guidance is to use Unicode (AL32UTF8). To migrate safely:

1. Assess and plan the conversion with Oracle’s Database Migration Assistant for Unicode (DMU) (scan for lossy/truncation risks, invalid bytes, and length semantic issues). - https://blog.yannickjaquier.com/oracle/convert-a-database-to-unicode-al32utf8.html
2. Resolve size semantics (e.g., switch critical columns to CHAR semantics or increase lengths) to absorb multi‑byte expansion. - https://docs.oracle.com/en/database/oracle/oracle-database/19/nlspg/character-set-migration.html
3. Cleanse corrupt data (invalid byte sequences) identified by DMU; these often surface when historic data were stored with mismatched client encodings. - https://docs.oracle.com/en/database/oracle/oracle-database/19/nlspg/character-set-migration.html, and https://github.com/laurenz/oracle_fdw/issues/334
4. Execute the conversion with DMU following Oracle’s runbook; validate with application test suites and round‑trip data checks. - https://docs.oracle.com/en/database/oracle/oracle-database/19/nlspg/character-set-migration.html) and https://blog.yannickjaquier.com/oracle/convert-a-database-to-unicode-al32utf8.html
5. Normalize clients/drivers to UTF‑8 end‑to‑end (JDBC/ODP.NET/ODBC settings, NLS_LANG, OS locale/code page) to prevent mojibake. - https://github.com/laurenz/oracle_fdw/issues/334

The out come was that you will stay on Oracle Database@Azure and meet Oracle’s long‑term recommendation with predictable supportability. - https://docs.oracle.com/en/database/oracle/oracle-database/19/nlspg/character-set-migration.html

Path B: Keep JA16SJISTILDE by deploying self‑managed Oracle on Azure VMs

If the application is hard‑bound to JA16SJISTILDE and cannot be remediated in a reasonable timeframe:

1. Deploy Oracle on Azure Virtual Machines (IaaS) from certified marketplace images or your own gold image. - https://learn.microsoft.com/en-us/azure/oracle/oracle-db/faq-oracle-database-azure
2. Create the database with JA16SJISTILDE during DB creation (choose the legacy charset up‑front; changing later is complex and discouraged). - https://docs.oracle.com/en/database/oracle/oracle-database/23//rilin/about-character-set-selection-during-installation.html
3. Ensure client encodings and gateway integrations (if any) are set to avoid conversion errors (NLS_LANG, HS_LANGUAGE for hetero services, etc.). - https://stackoverflow.com/questions/77323883/oracle-azure-sql-problem-with-encoding

This will make you preserve JA16SJISTILDE at the cost of managing the database yourself (patching, backups, HA/DR). This is the only supported way to retain that legacy charset on Azure. -https://learn.microsoft.com/en-us/azure/oracle/oracle-db/faq-oracle-database-azure

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

---

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

Answer 2

Hi 中村篤法,
Thankyou for reaching Microsoft Q&A!
The behavior you are seeing is expected. In Oracle Database@Azure, the base database is deployed as a pre-created CDB using Oracle-managed defaults, and the character set cannot be selected or changed during provisioning. Any PDB created in this environment must inherit the character set of the CDB, which is typically AL32UTF8.

Oracle does not support creating a PDB with a different character set than its CDB, and changing the character set after deployment (for example using INTERNAL_USE) is unsupported and not permitted in this managed service.

Because of this, JA16SJISTILDE cannot be used with Oracle Database@Azure.

To proceed, you have two supported options:

Validate and run the application on AL32UTF8, which is Oracle’s strategic Unicode character set and fully supports Japanese data.

If the application strictly requires JA16SJISTILDE, deploy Oracle Database on an Azure VM (self-managed) and create the database manually with that character set.

this is an Oracle architecture and service-design limitation, not a misconfiguration. Character set selection is not available in Oracle Database@Azure, and JA16SJISTILDE is only possible with a self-managed Oracle deployment.