ORA-26988: Cannot grant Oracle GoldenGate privileges. The procedure GRANT_ADMIN_PRIVILEGE is disabled.

Problem:

While trying to grant the privilege to Golden Gate user in 23ai database, I received the following error:

SQL> EXEC DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE('GGADMIN');
BEGIN DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE('GGADMIN'); END;

*
ERROR at line 1:
ORA-26988: Cannot grant Oracle GoldenGate privileges. The procedure GRANT_ADMIN_PRIVILEGE is disabled.
ORA-06512: at "SYS.DBMS_LOGREP_UTIL", line 601
ORA-06512: at "SYS.DBMS_LOGREP_UTIL", line 636
ORA-06512: at "SYS.DBMS_GOLDENGATE_AUTH", line 38
ORA-06512: at line 1
Help: https://docs.oracle.com/error-help/db/ora-26988/

Explanation:

With Oracle Database release 23ai, procedures are replaced by roles.

Solution:

Grant the following Oracle GoldenGate roles: OGG_CAPTURE for Extract, OGG_APPLY for Replicat, and OGG_APPLY_PROCREP for procedural replication with Replicat.

grant OGG_APPLY to GGADMIN;
grant OGG_APPLY_PROCREP to GGADMIN;
grant OGG_CAPTURE to GGADMIN;

ORA-27106: system pages not available to allocate memory

Oracle error ORA-27106: system pages not available to allocate memory can appear when starting up a database instance, particularly when HugePages are misconfigured or unavailable. This post walks through a real-world scenario where the error occurs, explains the underlying cause, and provides step-by-step resolution.

Problem

Attempting to start up the Oracle database instance results in the following error:

oracle@mk23ai-b:~$ sqlplus / as sysdba

SQL*Plus: Release 23.0.0.0.0 - for Oracle Cloud and Engineered Systems on Thu Jul 3 00:15:46 2025
Version 23.7.0.25.01

Copyright (c) 1982, 2024, Oracle. All rights reserved.

Connected to an idle instance.

SQL> startup
ORA-27106: system pages not available to allocate memory
Additional information: 6506
Additional information: 2
Additional information: 3

Cause

This error is most often seen on Linux platforms when HugePages are either:

  • Not configured,
  • Insufficiently allocated,
  • and the database is explicitly configured to use only HugePages with: use_large_pages='ONLY'

Troubleshooting

1) Identify the SPFILE path of the database

$ srvctl config database -db orclasm

Output:

Database unique name: orclasm
Database name: orclasm
Oracle home: /u01/app/oracle/product/23ai/dbhome_1
Oracle user: oracle
Spfile: +DATA/ORCLASM/PARAMETERFILE/spfile.274.1201294643
Password file:
Domain:
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Disk Groups: DATA
Services:
OSDBA group:
OSOPER group:
Database instance: orclasm

2) Create a PFILE from the SPFILE

You can create a pfile from an spfile without starting the instance, which is particularly useful when the instance cannot be started.

$ export ORACLE_SID=orclasm
$ sqlplus / as sysdba

SQL> create pfile='/tmp/temppfile.ora' from spfile='+DATA/ORCLASM/PARAMETERFILE/spfile.274.1201294643';

File created.

SQL> exit

Now, inspect the HugePages configuration setting:

$ grep -i use_large_pages /tmp/temppfile.ora
*.use_large_pages='ONLY'

3) Check HugePages availability on the system

$ grep Huge /proc/meminfo

Example output (problem scenario):

HugePages_Total:       0
HugePages_Free: 0
HugePages_Rsvd: 0
Hugepagesize: 2048 kB

HugePages are not configured on the system in this case. If it is configured for you, then the HugePages_Free value is insufficient.

Solution

1) Estimate required HugePages

You can estimate the needed HugePages based on total SGA:

đť‘“: HugePages = (SGA size in MB) / Hugepagesize

For example, if SGA is 24 GB (24576 MB) and Hugepagesize = 2 MB, then required
HugePages = 24576 / 2 = 12288

2) Configure HugePages at OS level

Edit /etc/sysctl.conf:

vm.nr_hugepages = 12288

Then apply:

# sysctl -p

3) Start the database in nomount to verify it is startable

$ sqlplus / as sysdba
SQL>
startup nomount

4) Reboot and verify

Restart the system to ensure that everything is functioning properly after the reboot and double check the config:

$ grep Huge /proc/meminfo

Expected output:

HugePages_Total:    12288
HugePages_Free: 12288
Hugepagesize: 2048 kB

⚠️ Temporary Workaround (not recommended for production)

If you need to get the database up urgently and cannot configure HugePages immediately, change the parameter to:

use_large_pages='TRUE'

This allows fallback to regular memory pages. However, for best performance and to avoid fragmentation, it’s strongly recommended to configure HugePages correctly and use use_large_pages='ONLY' in production.

CLSRSC-400: A system reboot is required to continue installing during root.sh

Problem:

While running the root.sh script, I encountered the following error:

root@mk23ai-b:~# /u01/app/23ai/grid/root.sh
Performing root user operation.
...
/u01/app/oracle/crsdata/mk23ai-b/crsconfig/roothas_2025-05-16_07-10-12PM.log
2025/05/16 19:10:17 CLSRSC-400: A system reboot is required to continue installing.
Died at /u01/app/23ai/grid/crs/install/oraafd.pm line 688.

If you think rebooting the system and rerunning the root.sh script will help, well, no… I’ve already tried :).

Troubleshoot:

Check if the secure boot is enabled:

root@mk23ai-b:~# mokutil --sb-state
SecureBoot enabled

Based on the previous output, Secure Boot is enabled. If you received a different output, such as “Secure Boot disabled,” continue your search.

Solution:

To disable Secure Boot, you cannot do it from the terminal; you need to access your computer’s firmware settings (BIOS or UEFI) and disable the Secure Boot option there.

In my case, I am using an Azure VM, and I can show you how I disabled it using the Azure console.

Note: This action requires VM downtime.

VM -> Configuration -> Security type section -> uncheck “Enable secure boot” -> Apply

Connect to the VM and rerun root.sh script:

root@mk23ai-b:~# /u01/app/23ai/grid/root.sh
...

mk23ai-b 2025/05/16 19:32:48 /u01/app/oracle/crsdata/mk23ai-b/olr/backup_20250516_193248.olr 0
2025/05/16 19:32:50 CLSRSC-327: Successfully configured Oracle Restart for a standalone server

Oracle 23ai: ORA-40490 COLUMNS clause required

Problem:

While working with Oracle’s native JSON data type, I ran into a bit of a hiccup while trying to insert JSON data into a table:

SQL> insert into json_table(data) 
values(
json_object(
'name' value 'Mari',
'age' value 34,
'city' value 'Tbilisi'));

I get the following error:

ERROR at line 1:
ORA-40490: COLUMNS clause required

And similarly, for creating a JSON Search Index (this is the syntax that is provided by Oracle documentation by now)

CREATE SEARCH INDEX mk_search_idx ON json_table(data) FOR JSON;

It returns the same error:

ERROR at line 1:
ORA-40490: COLUMNS clause required

At this point, I figured the issue had to be about the “COLUMNS clause”, which the error clearly mentions – but where exactly is it supposed to go?

Solution:

Turns out, Oracle wants you to explicitly declare the COLUMNS clause right after the table name. Here’s the syntax that finally worked for me:

SQL> insert into json_table columns(data)
values(
json_object(
'name' value 'Salome',
'age' value 12,
'city' value 'Tbilisi'));
1 row created.

SQL> commit;

And similarly, for creating a JSON Search Index:

SQL> CREATE SEARCH INDEX mk_search_idx ON json_table columns(data) FOR JSON;

Index created.

Release Schedule of Current Database Releases

Determining the schedule for a new database release can be challenging. Online, you may encounter misleading information suggesting that the database has already launched when it is still not generally available (GA). To ensure you have accurate details, refer to the following metalink article.

Release Schedule of Current Database Releases (Doc ID 742060.1)

Also, verify the document’s update date found on the right side under Document Details -> Last Major Update -> Last Update.