Shmem problem installing Oracle 12 C on Ubuntu 18.04

Hi,

I'm a junior programmer. This is my first post here, please excuse me if that's not the correct place :slight_smile:

For days now I've been trying to install Oracle DB 12c R2 on Ubuntu 18.04. I'm at my wits' end. The software itself installs fine and a Listener can be started but I can't start Oracle nor create a database. After several attempts:

  • The GUI installer (DBCA) freezes at 2% at "Copying database files.."
  • Under CLI I can start sqlplus / as sysdba but it freezes after STARTUP NOMOUNT; command (nothing happens, SQL prompt doesn't come back, the cursor just moves to next line and blinks forever).

I ran perf top -p on the process, after a few minutes I was left with:

100,00% [kernel] [k] shmem_write_end

Do you have any suggestions? What can I try / which logs should I check?

My settings:

.bashrc

# Oracle Settings
export TMP=tmp
export TMPDIR=$TMP
export ORACLE_HOSTNAME=hyperbook-N650DU
export ORACLE_UNQNAME=mgdb5
export ORACLE_BASE=/oracle
export ORACLE_HOME=$ORACLE_BASE/product/12/db_1
export ORACLE_SID=mgdb5
export PATH=usr/sbin:$PATH
export PATH=$ORACLE_HOME/bin:$PATH
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib
export CLASSPATH=$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib

/etc/sysctl.conf

# for oracle 12C
fs.file-max = 6815744
kernel.sem = 250 32000 100 128
kernel.shmmni = 4096
kernel.shmall = 2042851
kernel.shmmax = 8367517696
kernel.panic_on_oops = 1
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576
net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 2
fs.aio-max-nr = 1048576
net.ipv4.ip_local_port_range = 9000 65500

pfile

db_name='mgdb5'
memory_target=1G
processes = 150
audit_file_dest='<ORACLE_BASE>/admin/mgdb5/adump'
audit_trail ='db'
db_block_size=8192
db_domain=''
db_recovery_file_dest_size=2G
diagnostic_dest='<ORACLE_BASE>'
dispatchers='(PROTOCOL=TCP) (SERVICE=MGDB5XDB)'
open_cursors=300 
remote_login_passwordfile='EXCLUSIVE'
undo_tablespace='UNDOTBS1'
# You may want to ensure that control files are created on separate physical
# devices
control_files = (ora_control1, ora_control2)
compatible ='11.2.0'

oracle user has no sudo rights, bu full access to $ORACLE_BASE

Hardware: Clevo N650DU notebook, i7700, 16 GB RAM.


Many thanks in advance to anyone who would help me.

Did you check to make sure you had enough disk space?

Yes, 80 GB partition, half empty:

Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/nvme0n1p5  77145836 37436396  35747536  52% /
tmpfs            8171404   164648   8006756   3% /dev/shm

Do you have equivalent of swap as your SGA size ?

If you are using DISM (which is default i think from 11 something) you will need to have swap space sized as your SGA to start the database.

Hope that helps
Regards
Peasant.

Yes, DISM.

MemTotal: 16342812 kB
SwapTotal: 8000508 kB

During installation I tried various configurations, with respectively 60, 40 and 25% of RAM value for total memory, of these % 3/4 was SGA, 1/4 PGA. So for example at 60% (10 GB) it was 7,5GB SGA + 2,5GB PGA. At one point I tried to go < 1 GB total.

So you are saying I must up the SGA value to mach (or exceed) swap?

Yes, if you are using DISM, your swap should match your SGA exactly.

But that should not effect the installer hanging, which is very hard to tell why.

If you run the installer from command line, when it's hanging, what does the output to console say?
Does it give any hints ?
How long does it hang ?
Oracle tends to compile and link, so that could take a while on laptop.

If the installer has not completed successfully, it is doubtful you will be able to start the database.

Regards
Peasant.

1 Like

Yes, it makes no sense to try to start the database when the installation process hangs and does not complete.

It's best to focus on the getting the install to work, not trying to get a database working when there is a clear error in the installation.

1 Like

Hi guys,

I feel you missed the very beginning of my post, perhaps I was not precise enough.

The Software-installer finished. So did the Network Configuration Assistant. Next step is trying to create a database, and here is where I encounter the problem.

ORACLE gui installer tries to bundle everything together, but I gave up on this approach after 1st time and instead installed all _but_ the database, and this was fine.

So when I'm ready to create a database I either start the database creation assistant ./dbca or start sqlplus and try to do it via cli. Firts case freezes after clicking "create database" with message "copying database files", 2nd freezes when I start an instance without mounting a database in order to create one.. (it freezes after SQL> STARTUP NOMOUNT; or rather seems to be doing something forever).

I will try with matching SGA and let you know how it goes.

Copying database files is not the same as "creating a database".

Is the error above which you posted the precise error / behavior or not?

Actually it only links: Oracle has a system user and this user (and its group, more precisely their UID/GID) is linked into the executable when the Oracle binaries are created. This is why you have to do a "relink" when you change that system user with

cd /$ORACLE_HOME/bin ; ./relink as_installed

You find the binaries under $ORACLE_HOME/install .

Notice that the relinking can cause troubles on some systems with memory constraints. You can patch the mentioned relink -script (its a simple shell-script) in this case. I can't remember what exactly i did ((IIRC it was something about temporary files, but i am not sure about what exactly) but i remember having to do that once and it was quite simple once i found the script itself.

@Neo: when the database (that is: the DB-files, not the DB-software, to be precise the database-instance) is created there are a lot of files copied (empty database files, redo-logs, catalogue files and what not) and i suppose this is what Marika is talking about - not the software (binaries) installation.

@Marika:

This is definitely wrong! It should be:

# Oracle Settings
export TMP=/tmp

I am not sure how Ubuntu does it, but might it be that /tmp is a "virtual filesystem" and in fact a part of RAM? If so: do yourself a favour, create a real filesystem on disk, mount that under /tmp and make sure it is big enough. Oracle creates some amount of temporary files and it might be that the space is simply too small or (if it is a virtual filesystem) its utilisation puts too much constraints on the RAM.

I hope this helps.

bakunin

2 Likes

Thanks, i cannot believe i missed that TMP variable export :frowning:

But the installer would not run with that kind of definition for sure.
Or would it ?
It would be strange for software not to check if the tmp is actually a directory, among other things.

Would could work (in theory) with that kind of definition, is that if user executed the installer while a tmp directory existed in his current working directory.

It has been some time since i clicked one of those OUI installers tho...

Regards
Peasant.

Hi,

finally go to try again, corrected .bashrc (export TMP=/tmp), set SGA to 8000508 KB to equal swap and PGA to 2GB.

First I tried reinstalling Oracle software completely and starting from scratch. I ran the graphic installer and at the end (at point of database creation), DBCA froze as per usual until I killed the process. Logs:

/oracle/cfgtoollogs/dbca/mgdb7/mgdb7.log

[ 2018-10-06 22:35:41.646 CEST ] Copying database files
DBCA_PROGRESS : 1%
DBCA_PROGRESS : 2%
[ 2018-10-06 22:35:46.156 CEST ] ORA-27104: system-defined limits for shared memory was misconfigured
DBCA_PROGRESS : 3%
[ 2018-10-06 22:35:46.156 CEST ] ORA-01034: ORACLE not available
[ 2018-10-06 22:35:47.188 CEST ] ORA-01034: ORACLE not available
[ 2018-10-06 22:35:47.190 CEST ] ORA-01034: ORACLE not available
[ 2018-10-06 22:35:52.346 CEST ] DBCA_PROGRESS : DBCA Operation failed.

/oracle/oraInventory/logs/installActions2018-10-06_10-24-49PM.log

...
INFO: Read: Copying database files
INFO: Copying database files
WARNING: Skipping line: Copying database files
INFO: Read: 1% complete
WARNING: Skipping line: 1% complete
INFO: Waiting for completion of background operations
...
WARNING: [WARNING] [INS-32091] Software installation was successful. But some configuration assistants failed, were cancelled or skipped.
   ACTION: Refer to the logs or contact Oracle Support Services.
INFO: Advice is WITHDRAW
 

After googling "ORA-27104: system-defined limits for shared memory was misconfigured" I tried fiddling with shmall and shmmax, but the result is the same: I start ./dbca and the installer stops at 2% and never finishes.

/oracle/cfgtoollogs/dbca/mgdb7$ gedit trace.log_2018-10-07_06-24-46-PM

...
[Thread-297] [ 2018-10-07 18:48:47.366 CEST ] [OsUtilsBase.copyFile:1582]  **write of file at destination complete...
[Thread-297] [ 2018-10-07 18:48:47.376 CEST ] [OsUtilsBase.copyFile:1617]  **file copy status:= true
[Thread-297] [ 2018-10-07 18:48:47.376 CEST ] [CloneRmanRestoreStep.executeImpl:376]  set _enable_pluggable_database to true
[Thread-297] [ 2018-10-07 18:48:47.378 CEST ] [BasicStep.execute:269]  Executing Step : RMAN_RESTORE_FROM_OFFLINE_BACKUP, Try count: 1
[Thread-297] [ 2018-10-07 18:48:47.379 CEST ] [BasicStep.configureSettings:383]  messageHandler being set=null
[Thread-297] [ 2018-10-07 18:48:47.379 CEST ] [Host.getRMANConnectionInfo:1239]  Connect to Instance mgdb7

/oracle/cfgtoollogs/dbca/mgdb7/DBDetails.log

...
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0

---------

Advice?

------ Post updated at 05:35 PM ------

And finally I can post links, so here are the complete logs: Dropbox - logs.7z + Screenshots Dropbox - screenshots.7z

At the danger of disappointing you: not yet. This looks like an interesting problem (in other words: you did nothing obvious wrong but it still doesn't work, so some culprit must exist but we don't know what it is) and it is time for serious debugging,

First, i googled the problem too and everywhere shared memory was mentioned. Have you had a look at the shared memory segments? You can do that with the ipcs command. See the man page for details. If a process crashes it happens that shared memory segments allocated by that process remain allocated but are in fact unusable. In such a case you need to manually remove them (otherwise your memory is made smaller effectively) or reboot, which also gets rid of them.

I also found this link which seems to be quite similar to your problem. Did you increase shared memory in the way the guy suggested? I also found this link effectively saying the same thing.

Another thing i remembered: Oracle has 2 settings: SGA_TARGET and SGA_MAXSIZE. You need to set both of them.

I hope this helps.

bakunin

Hi bakunin,

many thanks for your reply!

Ad. shmall & shmax

The first link you mention - yes, I tried it, and a few other combinations of shmall & shmax, still not quite sure what is correct. Tested values:

Calculated by script from here:

kernel.shmmax = 8367513600
kernel.shmall = 2042850

Calculated by hand as instructed here:

kernel.shmmax = 8367519744
kernel.shmall = 1634281

Tried also this:

kernel.shmmax = 17179869184
kernel.shmall = 4194304

Following your link:

kernel.shmall = 9272480

Tried Oracle:

kernel.shmmax = MemTotal 16342812 kB * 1024 = 16735039488 bytes
kernel.shmall = MemTotal 16342812 kB * 1024 * 0,4 / 4096 (page size) = 10214258 pages (???)

this didn't seem right, so I used this for shmall (assuming I wat to give 8GB):

kernel.shmall = 8 * 1024 * 1024 * 1024 ) / 4096 = 2097152 pages

Every source gives me another recommendation, none worked so far.

SGA_TARGET & SGA_MAX_SIZE

I was setting SGA target (to match swap of 8000508 kB), during installation process in DBCA , I can see in the logs that this was picked up:

--------------------------------------------------------------------------------
Initialization Parameters
--------------------------------------------------------------------------------

- audit_file_dest : {ORACLE_BASE}/admin/{DB_UNIQUE_NAME}/adump
- audit_trail : db
- compatible : 12.2.0
- control_files : ("{ORACLE_BASE}/oradata/{DB_UNIQUE_NAME}/control01.ctl", "{ORACLE_BASE}/oradata/{DB_UNIQUE_NAME}/control02.ctl")
- db_block_size : 8192 BYTES
- db_name : mgdb7
- diagnostic_dest : {ORACLE_BASE}
- dispatchers : (PROTOCOL=TCP) (SERVICE=mgdb7XDB)
- local_listener : LISTENER_MGDB7
- nls_language : POLISH
- nls_territory : POLAND
- open_cursors : 300
- pga_aggregate_target : 2 GB
- processes : 640
- remote_login_passwordfile : EXCLUSIVE
- sga_target : 7812 MB
- undo_tablespace : UNDOTBS1

As for SGA_MAX_SIZE, according to this page it's for 10g only. But this time I did try setting MEMORY_MAX_TARGET, which was 0 by default.

During this attempt:

kernel.shmmax = 16735039488
kernel.shmall = 2097152

001.png
002.png
003.png
004.png

So I check memory:

oracle@hyperbook-N650DU:/oracle/product/12/db_1/bin$ ipcs --human

------ Message Queues --------
key        msqid      owner      perms      size         messages    

------ Shared Memory Segments --------
key        shmid      owner      perms      size       nattch     status      
0x00000000 262144     oracle     600          128M     2          dest         
0x00000000 360449     oracle     600          512K     2          dest         
0x00000000 1114114    oracle     600          8,4M     2                       
0x00000000 491523     oracle     600          512K     2          dest         
0x00000000 524292     oracle     600          512K     2          dest         
0x00000000 557061     oracle     600          512K     2          dest         
0x00000000 1081350    oracle     600         82,8K     2          dest         
0x00000000 1146887    oracle     600          7,6G     1                       
0x00000000 1179656    oracle     600          7,6M     1                       
0x391430c8 1212425    oracle     600           36K     1                       

------ Semaphore Arrays --------
key        semid      owner      perms      nsems     
0x9d5ea68c 98304      oracle     600        161       
0x9d5ea68d 131073     oracle     600        161       
0x9d5ea68e 163842     oracle     600        161       
0x9d5ea68f 196611     oracle     600        161       
0x9d5ea690 229380     oracle     600        161 
oracle@hyperbook-N650DU:/oracle/product/12/db_1/bin$ free --mega
              total        used        free      shared  buff/cache   available
Mem:          16342        1595       12378         750        2368       13690
Swap:          8000           0        8000
oracle@hyperbook-N650DU:/oracle/product/12/db_1/bin$ cat /proc/meminfo
MemTotal:       16342812 kB
MemFree:        12371256 kB
MemAvailable:   13683224 kB
Buffers:          125812 kB
Cached:          2148640 kB
SwapCached:            0 kB
Active:          1724356 kB
Inactive:        1865320 kB
Active(anon):    1316344 kB
Inactive(anon):   754572 kB
Active(file):     408012 kB
Inactive(file):  1110748 kB
Unevictable:          16 kB
Mlocked:              16 kB
SwapTotal:       8000508 kB
SwapFree:        8000508 kB
Dirty:               100 kB
Writeback:             0 kB
AnonPages:       1315248 kB
Mapped:           807964 kB
Shmem:            755696 kB
Slab:             224248 kB
SReclaimable:      99952 kB
SUnreclaim:       124296 kB
KernelStack:       11888 kB
PageTables:        45148 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    16171912 kB
Committed_AS:   14328444 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      237476 kB
DirectMap2M:     4923392 kB
DirectMap1G:    11534336 kB

Logs not very helpful:

/oracle/cfgtoollogs/dbca/trace.log_2018-10-08_01-28-13-PM

/oracle/cfgtoollogs/dbca/mgdb7/trace.log_2018-10-08_01-28-13-PM

-----

Can you help interpret these results? Is Oracle getting the 8GB of memory or not?

Many thanks for any effort :slight_smile:

These lines looks like the problem :

[DBCreationMode.flowWorker] [ 2018-10-08 13:28:24.790 CEST ] [ASMUtils.initialize:271]  ASM SID: null
[DBCreationMode.flowWorker] [ 2018-10-08 13:28:24.791 CEST ] [KfodUtil.kfodOutput:375]  null/rdbms/bin/kfod
[DBCreationMode.flowWorker] [ 2018-10-08 13:28:24.791 CEST ] [KfodUtil.kfodOutput:375]  nohdr=TRUE
[DBCreationMode.flowWorker] [ 2018-10-08 13:28:24.791 CEST ] [KfodUtil.kfodOutput:375]  OP=GROUPS
[DBCreationMode.flowWorker] [ 2018-10-08 13:28:24.791 CEST ] [KfodUtil.kfodOutput:375]  status=true
[DBCreationMode.flowWorker] [ 2018-10-08 13:28:24.792 CEST ] [KfodUtil.kfodOutput:375]  asmcompatibility=true dbcompatibility=true
[DBCreationMode.flowWorker] [ 2018-10-08 13:28:24.792 CEST ] [KfodUtil.kfodOutput:382]  Cannot run program "null/rdbms/bin/kfod": error=2, No such file or directory
[DBCreationMode.flowWorker] [ 2018-10-08 13:28:24.792 CEST ] [KfodUtil.kfodOutput:383]  Cannot run program "null/rdbms/bin/kfod": error=2, No such file or directory

Are you sure you set your environment properly, looks like it is missing PATH definition, possibly for GRID_HOME.
You will need to set those environment variables every time you want to run oracle software, or put them into your .profile of oracle user.

This execution also never happened :

Thread-74] [ 2018-10-08 13:29:21.142 CEST ] [StreamReader.run:62]  In StreamReader.run 
[Thread-75] [ 2018-10-08 13:29:21.143 CEST ] [StreamReader.run:66]  ERROR>/bin/sh: /tmp/CVU_12.2.0.1.0_oracle//exectask.sh: No such file or directory

Are you sure you have a proper installer, with checksum verified and unpacked properly ?
ipcs shows that oracle has indeed 7.6 gb with one process attached.

Regards.
Peasant.

Hi Peasant,

the installer came straight from Oracle webpage.

Thank you all for your help, but I gave up and ended up installing the db on another machine, running Windows.

:expressionless: