docker-oracle-xe-11g
docker-oracle-xe-11g copied to clipboard
wnameless
Restarting docker image wipes out all Oracle DB data
I stop and start Docker container and I see that all of my Oracle DB data is wiped out. Why ? I see that someone has posted to run like this: docker run -d -p 49160:22 -p 49161:1521 -e ORACLE_ALLOW_REMOTE=true -v /local_path/to/oracle_home:/u01/app/oracle wnameless/oracle-xe-11g When i try above option for mounting the volume to host machine I get following error:
cp: cannot stat '/u01/app/oracle/product/11.2.0/xe/network/admin/listener.ora.tmpl': No such file or directory
/usr/sbin/startup.sh: line 19: sqlplus: command not found
/usr/sbin/startup.sh: ignoring /docker-entrypoint-initdb.d/*
Try this: docker run -d -p 49160:22 -p 49161:1521 -e ORACLE_ALLOW_REMOTE=true --mount source=oracle_vol,target=/u01/app/oracle wnameless/oracle-xe-11g
Gives error:
sudo docker run -p 49160:22 -p 49161:1521 -e ORACLE_ALLOW_REMOTE=true --mount source=/oracle, target=/u01/app/oracle wnameless/oracle-xe-11g invalid argument "source=/oracle," for --mount: invalid field '' must be a key=value pair
I tried various combinations of key:value pair but that fails too. Finally one combination that does not give this error but a different error is:
sudo docker run -p 49160:22 -p 49161:1521 -e ORACLE_ALLOW_REMOTE=true --mount "source=/oracle","target=/u01/app/oracle" wnameless/oracle-xe-11g docker: Error response from daemon: create /oracle: "/oracle" includes invalid characters for a local volume name, only "[a-zA-Z0-9][a-zA-Z0-9_.-]" are allowed. If you intended to pass a host directory, use absolute path.
Add volume when running the container.
docker run --name oracle11g -d -p 49161:22 -p 1522:1521 -p 49163:8080 -v /oracle11g-data/:/u01/app/oracle/oradata/oracle11g-data/ -e ORACLE_ALLOW_REMOTE=true --restart=always wnameless/oracle-xe-11g
Has there been any progress on this? wnameless I tried your version of the command and it ran without error but restarting docker still causes the database to come back empty.
I also tried dragonbest520's solution and it also still leaves me with an empty database on restart.
Hi! Solution proposed by dragonbest520 is the right one. Folder /oracle11g-data must be created at host on root. I use to create /srv/oradata for this. It must have read/write permissions.
When you run docker you must see data created on this folder. All data keep persistent no matter if docker stops.
Hi i followed dragonbest520, data seems to persist between container restarts but weirdly i can,t see any files in /oracle11g-data on my host machine. Any idea why? Thanks.
In Mac Wnameless's answer is good for my situation Thank you Wnameless docker run -d -p 49160:22 -p 49161:1521 -e ORACLE_ALLOW_REMOTE=true --mount source=oracle_vol,target=/u01/app/oracle wnameless/oracle-xe-11g
Sorry I never followed up on my own reply to this:
My issue was self inflicted, I wasn't starting the same container I had stopped so it kept creating new Oracle instances after the old one was stopped. Adding the restart always thing saved me. I realized what I had done after doing docker ps -a and seeing a gigantic list of shame.
Ubnutu 16.04 - still fails to start the container with a volume. What's the solution?
The @dragonbest520 solution works. Thanks! I'm wondering if it would be worth it to add this little tip to the docs since I'm sure it's a fairly common use case.
Yet, please add this very useful detail to the docs.
The solution of @dragonbest520 works for me, too.
Currently I am wondering about two things which might be the result of my little knowledge of docker/oracle-xe:
- My database files are not located in "/u01/.../oracle-xe-11g" but "/u01/.../XE", so I used that path for the volume.
- Restarting the container works fine and my modified data is still there. But: It doesn't work when I remove (docker rm) the container an rerun it later with the same volume. The files are still there but the database will not be accessible / will not successfully start.
This is my script to run the container:
docker run --name oracle-xe-master -d -p 1521:1521 -v db-master:/u01/app/oracle/oradata/XE -e ORACLE_ALLOW_REMOTE=true --restart=always wnameless/oracle-xe-11g
Hello, I have this error :
Starting Oracle Net Listener.
Starting Oracle Database 11g Express Edition instance.
ERROR:
ORA-01033: ORACLE initialization or shutdown in progress
Process ID: 0
Session ID: 0 Serial number: 0
SP2-0306: Invalid option.
Usage: CONN[ECT] [{logon|/|proxy} [AS {SYSDBA|SYSOPER|SYSASM}] [edition=value]]
where <logon> ::= <username>[/<password>][@<connect_identifier>]
<proxy> ::= <proxyuser>[<username>][/<password>][@<connect_identifier>]
/usr/sbin/startup.sh: ignoring /docker-entrypoint-initdb.d/*
and my conf is :
version: '3'
services:
oracle:
build:
context: docker/services/${ENV}/oracle
args:
DATABASE_NAME: ${DATABASE_NAME}
DATABASE_USER: ${DATABASE_USER}
DATABASE_PASSWORD: ${DATABASE_PASSWORD}
ports:
- "1521:1521"
- "8080:8080"
volumes:
- ./docker/data/oracle:/u01/app/oracle/oradata/XE:${RW_OPTIONS}
expose:
- "1521"
env_file:
- .env
When i removed the volumes oracle is running. Has you good any idea ?
I personnaly had the problem and it was a right problem. Inside your container go to
/u01/app/oracle/product/11.2.0/xe/bin and do chmod 6751 oracle (yep strange right), restart and it should work :)
When I start the container without volume it works. If I use a volume to mount as XE or oradata this overlays that folder in the container what is expected. However, the content of that folder is not create/initialized on startup of the container. So when I create an empty directory on my host and mount is as such volume it is also an empty folder in the container what makes the DB to fail.
I tried to mount it aside, bash into the container and copy -a the data over. Then I recreated the container with the volume mounted in the proper place. Now the data is there but for some reason then oracle startup fails for some reason and I also get the RA-01033: ORACLE initialization or shutdown in progress error. Oracle error reporting and logging is very crappy and a science of its own so that certified DBAs are worth their money...
I do not come to the point that @Skrrytch has reached what would be sufficient for me.
I made it somehow work once. But after restarting docker entirely my container is now booted up again but oracle is broken. Now I get this when I try to logon with SQL Developer:
An error was encountered performing the requested operation:
IO Error: Got minus one from a read call
Vendor code 17002
Never seen such error before...
Okay, found a more interesting log:
/u01/app/oracle/diag/rdbms/xe/XE/trace/alert_XE.log
Starting up:
Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production.
Using parameter settings in server-side spfile /u01/app/oracle/product/11.2.0/xe/dbs/spfileXE.ora
System parameters with non-default values:
sessions = 174
sga_target = 576M
control_files = "/u01/app/oracle/oradata/XE/control.dbf"
compatible = "11.2.0.0.0"
db_recovery_file_dest = "/u01/app/oracle/fast_recovery_area"
db_recovery_file_dest_size= 10G
undo_management = "AUTO"
undo_tablespace = "UNDOTBS1"
remote_login_passwordfile= "EXCLUSIVE"
dispatchers = "(PROTOCOL=TCP) (SERVICE=XEXDB)"
shared_servers = 4
job_queue_processes = 4
audit_file_dest = "/u01/app/oracle/admin/XE/adump"
db_name = "XE"
open_cursors = 300
pga_aggregate_target = 195840K
diagnostic_dest = "/u01/app/oracle"
Tue Jan 08 22:31:22 2019
PMON started with pid=2, OS id=41
Tue Jan 08 22:31:22 2019
PSP0 started with pid=3, OS id=43
Tue Jan 08 22:31:24 2019
VKTM started with pid=4, OS id=45
VKTM running at (100ms) precision
Tue Jan 08 22:31:24 2019
GEN0 started with pid=5, OS id=49
Tue Jan 08 22:31:24 2019
DIAG started with pid=6, OS id=51
Tue Jan 08 22:31:24 2019
DBRM started with pid=7, OS id=53
Tue Jan 08 22:31:24 2019
DIA0 started with pid=8, OS id=55
Tue Jan 08 22:31:24 2019
MMAN started with pid=9, OS id=57
Tue Jan 08 22:31:24 2019
DBW0 started with pid=10, OS id=59
Tue Jan 08 22:31:24 2019
LGWR started with pid=11, OS id=61
Tue Jan 08 22:31:24 2019
CKPT started with pid=12, OS id=63
Tue Jan 08 22:31:24 2019
SMON started with pid=13, OS id=65
Tue Jan 08 22:31:24 2019
RECO started with pid=14, OS id=67
Tue Jan 08 22:31:24 2019
MMON started with pid=15, OS id=69
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
Tue Jan 08 22:31:24 2019
MMNL started with pid=16, OS id=71
starting up 4 shared server(s) ...
ORACLE_BASE from environment = /u01/app/oracle
Tue Jan 08 22:31:24 2019
ALTER DATABASE MOUNT
Successful mount of redo thread 1, with mount id 2878167036
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: ALTER DATABASE MOUNT
Tue Jan 08 22:31:28 2019
ALTER DATABASE OPEN
Beginning crash recovery of 1 threads
Started redo scan
Completed redo scan
read 152 KB redo, 95 data blocks need recovery
Started redo application at
Thread 1: logseq 3, block 3
Recovery of Online Redo Log: Thread 1 Group 1 Seq 3 Reading mem 0
Mem# 0: /u01/app/oracle/fast_recovery_area/XE/onlinelog/o1_mf_1_fjv4kr08_.log
Completed redo application of 0.11MB
Completed crash recovery at
Thread 1: logseq 3, block 308, scn 396577
95 data blocks read, 95 data blocks written, 152 redo k-bytes read
Thread 1 advanced to log sequence 4 (thread open)
Thread 1 opened at log sequence 4
Current log# 2 seq# 4 mem# 0: /u01/app/oracle/fast_recovery_area/XE/onlinelog/o1_mf_2_fjv4krmr_.log
Successful open of redo thread 1
SMON: enabling cache recovery
[95] Successfully onlined Undo Tablespace 2.
Undo initialization finished serial:0 start:4294699046 end:4294699086 diff:40 (0 seconds)
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is AL32UTF8
Opening with Resource Manager plan: INTERNAL_PLAN_XE
Starting background process VKRM
Tue Jan 08 22:31:28 2019
VKRM started with pid=24, OS id=107
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Tue Jan 08 22:31:29 2019
QMNC started with pid=23, OS id=117
Completed: ALTER DATABASE OPEN
Starting background process CJQ0
Tue Jan 08 22:31:29 2019
CJQ0 started with pid=26, OS id=136
Tue Jan 08 22:31:29 2019
db_recovery_file_dest_size of 10240 MB is 0.98% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Tue Jan 08 22:36:29 2019
Starting background process SMCO
Tue Jan 08 22:36:29 2019
SMCO started with pid=22, OS id=2890
Tue Jan 08 22:39:23 2019
opiodr aborting process unknown ospid (2904) as a result of ORA-609
Tue Jan 08 22:41:07 2019
opiodr aborting process unknown ospid (2917) as a result of ORA-609
Tue Jan 08 22:41:28 2019
opiodr aborting process unknown ospid (2918) as a result of ORA-609
Does not really sound trustworthy. Aint a DB aiming for ACID and consistency of my data?
@hohwille I run into the same problem as yours. You might want to try "docker create volume" and "-v [volume-name]:/u01/app/oracle/oradata/XE" to run your container, for me, it works.
what I think is going on when you use the docker run command it creates a new container and that is why it seams you are loosing your database when you stop the container and run the docker run command again. If you give it a name in the initial run command that will link the container ID to the name. Then when you start or stop just use docker stop oracle11g and docker start oracle 11g. The container settings and the workspace will still exist on a restart.
what I think is going on when you use the docker run command it creates a new container and that is why it seams you are loosing your database when you stop the container and run the docker run command again. If you give it a name in the initial run command that will link the container ID to the name. Then when you start or stop just use docker stop oracle11g and docker start oracle 11g. The container settings and the workspace will still exist on a restart.
I always run it with a container name. It doesn't help the volume get persistent.
@hohwille I run into the same problem as yours. You might want to try "docker create volume" and "-v [volume-name]:/u01/app/oracle/oradata/XE" to run your container, for me, it works.
I don't want to create a volume because it can be wiped out more easily than the host's folder.
What's the difference between creating volume and having it mounted from the host?
How to make the mount work?
If this can help anyone, I've managed to make it work using docker-compose with this configuration :
version: '3.7'
services:
oracle-service:
container_name: oracle-service
image: wnameless/oracle-xe-11g-r2
volumes:
- type: volume
source: oracle
target: /u01/app/oracle
environment:
- ORACLE_ALLOW_REMOTE=true
ports:
- 1521:1521
networks:
oracle-service-docker:
volumes:
oracle:
networks:
oracle-service-docker:
driver: bridge
