Docker-images: Startup scripts

[hillol-pal]

If I have one startup initiation script and several other supporting scripts how to arrange them. Suppose I want to create a schema(platform) in a pdb called XOOM. I have existing script create_platform_schema.sh and it uses apply.sql and post_apply.sql to create the schema, create tables and load data.

How should I name the create_platform_schema.sh inside -v /opt/oracle/scripts/startup if I mount the volume -v /opt/oracle/scripts/startup. Should I keep the the .sql scripts as it is. Will the container understand that it only has to run create_platform_schema.sh and rest will be used automatically.

[gvenzl]

The container will list through all files in the folder but only execute files ending with .sh and .sql.
That means:

For ordering, you can add simple NN_ in front of scripts, for example:

01_create_platform_schema.sh
02_create_tables.sql
03_create_test_data.sql

If you have script that are called by other scripts, and you do want to keep it that way - the container could just call them for you as well - then you will have to give them a different ending than .sh or .sql. SQL*Plus inside the container will not care whether it's executing a create_schema.sql or create_schema.mod or whatever else.

[hillol-pal]

Thank you gvenzl. I am wondering the container would not look into sub-directories inside the startup/setup directory to execute scripts (sh/sql). In that case I will rename the top level scripts with NN at the beginning and move all the scripts(.sql) which are called internally inside a sub-directory and modify the top level scripts with changed location for all other scripts. Will that work? What do you think?

[hillol-pal]

Unfortunately I am getting SP2-0310 error when the create_platform_schema.sh is getting executed and referring to sub-level scripts.
SP2-0310: Unable to open file "toplevel/define.sql:
SP2-0310: Unable to open file "toplevel/start.sql"

But permissions for that directory and files are writable and executable for all the Users and the files are visible within the container.

[gvenzl]

I think SQL Plus cannot find the path. Do you call the scripts with a relative path? ./toplevel/define.sql, etc?

[hillol-pal]

Yes. Snippet of the script

sqlplus -silent "$SYSTEM_USER_NAME"/"$SYSTEM_PASSWORD"@"$SYSTEM_SERVER" << EOF || true

@toplevel/define.sql

DEFINE platform_connection_string='$SERVER';
DEFINE system_connection_string='$SYSTEM_SERVER';
DEFINE system_user_name='$SYSTEM_USER_NAME';
DEFINE system_user_password='$SYSTEM_PASSWORD';
DEFINE platform_dbname='$PLATFORM_DB_NAME';
DEFINE platform_dbpwd='$PLATFORM_DB_PASSWORD';

@toplevel/start.sql

commit;

exit;
EOF

[gvenzl]

I think you will have to pass on the entire path by either getting it via $PWD or similar.

[hillol-pal]

It seems now it is working passing the absolute path. Thank you for the help.

[hillol-pal]

One more question! What will be the root and oracle user password for the container. I wanted to view the tnsnames.ora file within the container and couldn't install nano or vi. Thanks for your help.

[Djelibeybi]

There are no passwords for either. You need to install those prior to the image being built or access the files externally from the container itself.

[gvenzl]

If you just want to view the tnsnames.ora you can just do a simple cat tnsnames.ora.
However, the tnsnames.ora will be put into the volume anyway, so you can view and modify it in <volume>/dbconfig/<ORACLE_SID>/tnsnames.ora as well.

[hillol-pal]

I did that. I was wondering if DBA wants to do some configuration changes as a root/oracle how they will do it.

[gvenzl]

All database parameters are persisted inside the database and hence with the volume. If sqlnet.ora or tnsnames.ora changes are required, they can be also done in the files which are persisted in the volume. There should be no need to have to log into the container and perform any changes.

[hillol-pal]

Ok. Thank you Gerald for the information.

[gvenzl]

You are welcome!