Three things that will trip you up running Oracle 23ai Free on OCI ARM

I stood up Oracle 23ai Free on an OCI ARM instance recently, and the experience was a reminder that the documentation is written for the path most people take, not the one I was on. On x86 the install is uneventful. On aarch64 it is mostly uneventful, right up until it is not, and the three places it stopped me cold all shared the same trait. The error message pointed somewhere other than the actual problem. None of these are hard to fix once you know what you are looking at. The cost is the hour you spend believing the error.

The aarch64 preinstall RPM is missing a compiler dependency

Oracle ships oracle-database-preinstall-23ai to set up the prerequisites, and on x86 it does its job. On ARM it has a gap. The package does not pull in gcc-gfortran, and that omission does not announce itself when you run the preinstall. Everything reports clean. You move on, you run your configure step, and the failure surfaces later during database creation, which is exactly the wrong place to be debugging a missing compiler. The stack you get back makes it look like a problem with the database build itself rather than a dependency that was never installed.

The fix is a single line, and you want it in place before you run configure rather than after you have watched a creation fail.

sudo dnf install -y gcc-gfortran

Install that first and the database creation proceeds the way the guide says it will. The lesson is that a clean preinstall run on ARM is not the same guarantee it is on x86.

The system Python is 3.6 and it will poison your tooling

Oracle Linux 8 ships Python 3.6 as the system interpreter. That interpreter is end of life, and it will not build python-oracledb. The trouble is that the failure does not say that. You go to install the driver, the build breaks with a Cython error, and the message sends you off chasing a Cython problem that does not exist. The real issue is the interpreter underneath it.

Do not touch the system Python. Oracle Linux uses it for its own tooling, and replacing it is how you break the operating system to fix a driver. Instead install 3.11 alongside it and build your virtual environment explicitly from that interpreter so nothing about the system default changes.

sudo dnf install -y python3.11
python3.11 -m venv .venv
source .venv/bin/activate
python --version
pip install --upgrade pip
pip install oracledb

The python --version line is there on purpose. Confirm the venv is actually running 3.11 before you build anything, because an activated environment that quietly fell back to the system interpreter will reproduce the exact failure you were trying to escape. There is one more implication that bites people in production. Anything you schedule under systemd or cron does not inherit your shell environment, so it will not pick up the activated venv. Point those jobs at the venv interpreter by its full path every time. Do not assume the activation carries over, because it does not.

DBMS_WORKLOAD_REPOSITORY cannot be granted by SYSTEM

This one is the most subtle of the three because it fails silently. You are setting up a user that needs to read AWR data, so you grant execute on DBMS_WORKLOAD_REPOSITORY. You issue it as SYSTEM because SYSTEM is the administrative account you reached for. The grant does not take, and nothing stops to tell you. It scrolls past in a wall of setup script output and you find out later when the user cannot run what it was supposed to run.

The package is owned by SYS, and granting execute on a SYS-owned package requires connecting as SYS. SYSTEM is not sufficient. The same boundary applies to the fixed views, so a select on v_$database has to come from SYS as well.

grant execute on sys.dbms_workload_repository to your_user;
grant select on sys.v_$database to your_user;

The practical takeaway is about how you build setup scripts. Sort your grants by who is allowed to issue them. Keep the statements that require SYS in their own connected block rather than scattering them through a script running as SYSTEM, because a privilege that fails quietly in the middle of two hundred lines of output is a privilege you will spend real time tracking down later.

Why a note like this is worth writing

None of these three appear in the main install documentation, and that is precisely why they are worth writing down. Each one produces an error that points away from the actual cause, and each one costs an evening if you are working through it cold with no idea the gap is there. Regent runs on Oracle 19c production rather than on a 23ai Free instance, so this is not the same environment. The discipline is the same one though. Most of the time on a database problem goes to finding the real failure point, not to fixing it, and the failure point is rarely where the error message is pointing. Writing down where it actually sits is how the next person, including the next version of me, gets that evening back.