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

I stood up Oracle Database 23ai Free this week on an OCI Always Free ARM instance, an Ampere A1 running Oracle Linux 8. The install itself is well documented and mostly smooth. What cost me time was the handful of things that are not in the standard walkthrough, the small gaps that only show up on aarch64 or only show up when you start driving the database from Python. None of them are hard once you know. All of them are quietly frustrating if you do not. Here are the three worth writing down.

The aarch64 preinstall RPM is missing a compiler dependency

The normal first step is the preinstall package, oracle-database-preinstall-23ai, which creates the oracle user, sets kernel parameters, and pulls in the OS packages the database needs. On x86 that is enough. On ARM it is not.

The aarch64 preinstall RPM does not pull in gcc-gfortran. If you skip ahead and run the database configuration step without it, the configure does not fail cleanly up front. It runs partway and then dies during database creation with errors that point at internal failures rather than at a missing package, which sends you looking in the wrong direction entirely.

The fix is to install it yourself before you configure, right after the preinstall package:

sudo dnf install -y gcc-gfortran

Do that and the database creation step runs to completion. It is a one line fix that is almost impossible to guess from the error it produces, which is exactly the kind of thing worth having written down somewhere searchable.

The system Python is 3.6, and it will quietly poison your tooling

This one does not bite during the database install. It bites later, the moment you try to talk to the database from Python, which on a modern setup means the python-oracledb thin driver.

Oracle Linux 8 ships with Python 3.6 as the system python3. It has to, because OS tooling depends on it, so you should not touch it. The problem is that 3.6 is years past end of life, and a current python-oracledb will not even build against it. If you create a virtual environment with the bare python3 and then try to install the driver, the install fails on a Cython version check, because pip falls back to compiling an ancient source release that 3.6 is too old to build.

The trap is subtle because everything looks fine until that last step. The venv creates, it activates, and only the package install fails, with an error that talks about Cython rather than about your Python version.

The fix is to install a modern Python alongside the system one and build the venv from that explicitly. Oracle Linux ships newer interpreters as separate packages that do not disturb the system 3.6:

sudo dnf install -y python3.11

Then build the virtual environment from python3.11 by name, not from the bare python3:

python3.11 -m venv .venv
source .venv/bin/activate
python --version          # confirm 3.11.x, not 3.6
pip install --upgrade pip
pip install oracledb

With a current interpreter driving the venv, pip pulls a prebuilt wheel instead of trying to compile from source, and the driver installs in seconds. One thing to carry forward: that venv is now pinned to 3.11, but the bare python3 on the box is still 3.6. So always work inside the activated venv, and if you later schedule anything with cron or systemd, point it at the venv interpreter by full path rather than at python3, or you will silently be back on 3.6.

DBMS_WORKLOAD_REPOSITORY cannot be granted by SYSTEM

The last one caught me while setting up a test user that needed to force AWR snapshots on demand. The grant looks routine:

grant execute on sys.dbms_workload_repository to your_user;

Run that as SYSTEM and it fails with insufficient privileges. The reason is that SYSTEM, despite being a powerful account, cannot grant execute on a SYS-owned package. That is a SYS-only operation. The same applies to granting select on certain SYS views such as v_$database.

If you are running a setup script as SYSTEM, those particular grants will fail while everything around them succeeds, which makes it easy to miss in a wall of output. The fix is simply to run those specific grants as SYS:

-- connect as SYS, not SYSTEM
grant execute on sys.dbms_workload_repository to your_user;
grant select on sys.v_$database to your_user;

Worth knowing before you write any setup automation: sort your grants by who can actually issue them. Object privileges on SYS-owned objects belong in the SYS section of your script, not the SYSTEM section.

Why I bother writing these down

None of these are profound. Each is a line or two once you know the answer. But each one is the kind of gap that does not appear in the main install guide, produces an error that points somewhere other than the real cause, and costs an evening if you are figuring it out cold. Those are exactly the notes I most wish other people had published before me, so this is me paying it forward. If you are standing up 23ai on ARM and hit a wall, I hope a search lands you here and saves you the hour.