Skip to main content

Command Palette

Search for a command to run...

Navigating the Cloud: My Transition to Oracle's Autonomous Transaction Database - Part 3

How to Use Different Buckets with One Database

Updated
•View as Markdown
Navigating the Cloud: My Transition to Oracle's Autonomous Transaction Database - Part 3
D
Oracle ACE Pro, founder of Enrol Consulting, and Oracle Database and APEX developer with more than two decades of experience building data-driven business applications. I write about Oracle Database, APEX, cloud and AI-assisted development.

Since I want to migrate many APEX applications to the same Autonomus database, it is obvious that each system needs its own object storage for the migration. Moreover, it may be useful later to store images or generated files in a separate bucket instead of in the database.

The question is how to separate the objects of each system within a tenancy in the Oracle Cloud. Or how can we give them individual, external access? In OCI we can assign privileges to registered users. However, we do not want each (technical) user to have access to the resources of another.

Architecture

In my architectural approach, a client has an APEX application (Application A). Each application has a separate workspace and a separate schema. It helps a lot to keep the architecture clean that each application, system, client, whatever you want to call it, is given an alias.

For example, Global Network Application has the alias GN. So the schema name is GN_PROD, the workspace is GN_PROD_WKS, and the application alias is GN. And in the DEV environment, GN_DEV, GN_DEV_WKS.

Following the logic above, each system also gets its own compartment (in our case, GN_Compartment).

Here, the DEV and PROD environments share the OCI resources. A bucket (GN_Bucket) is created under each compartment. The files created by the live and development environments can be separated within the bucket.

What about privilege management?

In OCI, permission roles are managed by policies. I created this policy in the root compartment, in our case called GN_ADMIN_POLICY.

I also created a special user group to which I added the system administrators and the technical user. GN_ADMIN_POLICY has the following policy statement:

Allow group GN_ADMIN_GROUP to manage all resources in compartment GN_compartment

This gives all members of GN_ADMIN_GROUP read and write access to GN_Bucket in GN_compartment.

Creating a technical user

In OCI, a user must have a unique email address. At least I did not find an alternative solution. For me, the problem was that as a Google Workspace subscriber, each new email address or user is a significant additional monthly cost.

Fortunately, Google allows up to 30 variations of an email address. So I didn't have to create the technical users as new Google users, that was enough in OCI.

Of course, there are many other combinations possible to separate permissions, but as a PROD and DEV ATP user, this seems to be the best solution.

My Journey to Oracle Cloud

Part 3 of 4

My practical journey from traditional Oracle infrastructure to Oracle Cloud. This series documents the decisions, challenges and lessons I have encountered while moving applications and databases toward OCI and Autonomous Database — from the first migration steps to learning, operating and evolving cloud-based Oracle environments. It is an ongoing journey rather than a fixed tutorial series.

Up next

How I Prepared for the Oracle Cloud Infrastructure 2025 Certified Foundations Associate Exam

About a year ago, I started working more seriously with Oracle Cloud, and looking back, I honestly regret not taking the OCI Foundations Associate certification sooner. Preparing for an exam forces yo

More from this blog

David Pataki

15 posts

Oracle ACE Pro, founder of Enrol Consulting, and Oracle Database and APEX developer with more than two decades of experience building data-driven business applications. I write about Oracle Database, APEX, cloud and AI-assisted development.