Installation & Upgrade & De-installation (Unix)
This chapter describes all installation/upgrade/de-installation steps.
Last updated
This chapter describes all installation/upgrade/de-installation steps.
Last updated
There is no big difference between installation and upgrade. In both cases you will extract the software in the destination directory and call dmk.sh to configure it.
If it is a new installation, DMK will create the local configuration files.
If it is an upgrade, it will keep the already existing local configuration files, but it overwrites the default DMK configuration. That's the reason why you must not edit dmk.conf.default, but dmk.conf.local!
DMK requires the Korn-shell (ksh) for its shell-scrips.
The shell for interactive work (login shell) can be ksh or bash. We recommend the bash shell (possibility for command-completion).
Per default, DMK uses the "perl" executable from the current ORACLE_HOME. It determines automatically the required library path (PERLLIB). If in the current ORACLE_HOME no working Perl is found, the "initial" Perl is used as fallback.
DMK requires a Perl with the standard modules for the initial startup (source dmk.sh).
we recommend to use the Perl found via the $PATH variable (default)
alternatively, you can specify a Perl binary in the environment variable with export PERL_EXEC=/path/to/perl (e.g. in .bash_profile or .profile)..
As fallback, DMK looks for a perl in the first ORACLE_HOME found in /etc/oratab.
🐧The easiest way for an initial Perl is to use the Perl version shipped by the OS which is in the $PATH (/usr/bin/perl).
On Enterprise Linux systems (Redhat/Oracle) there is often only the perl-interpreter package installed, but not the required default Perl libraries. To fix it, do yum install perl.
🐧🪟 It is not recommended to use the Perl of an installed ORACLE_HOME via the PERL_EXEC variable for the initial startup. If you remove this Oracle-home once, the environment no longer works… Alternatively, you can copy the perl directory of an ORACLE_HOME to a persistent location.
Hints:
The ~/.DMK_PERL file of older DMK 1.x releases is no longer used.
After the initial startup, DMK uses the Perl of the current ORACLE_HOME (if present and working, otherwise fallback to the initial Perl).
We recommend installing a native version of rlwrap. On Enterprise Linux, you will find it in the EPEL repository. If EPEL is not configured, you can download and install the rpm directly:
EL9: https://yum.oracle.com/repo/OracleLinux/OL9/developer/EPEL/x86_64/getPackage/rlwrap-0.46.1-1.el9.x86_64.rpm
EL8: https://yum.oracle.com/repo/OracleLinux/OL8/developer/EPEL/x86_64/getPackage/rlwrap-0.46.1-1.el8.x86_64.rpm
EL7: https://yum.oracle.com/repo/OracleLinux/OL7/developer_EPEL/x86_64/getPackage/rlwrap-0.45.2-2.el7.x86_64.rpm
If it is missing, DMK provides a minimal binary as a fallback (see initial configuration).
If you upgrade a former installation, we recommend backing up your old installation.
Or you can also do a new installation and hide the old installation (for fallback/review). This is the recommended way if you upgrade from a DMK 1.x version.
⚠ IMPORTANT: move it to a hidden directory (beginning with a dot '.') or to another directory level! Otherwise DMK thinks it is an additional DMK package and integrates it in the environment :-(
If you upgraded from a DMK 1.x version, we recommend to cleanup the oratab file. Remove dummy-entries, remove PDB's from the SID-entries. The dmk.oratab file can be removed, it Is no longer used. It Is now handled in new configuration files (see later).
(Identical for new installation and upgrade)
Based on the dbi services and OFA (Oracle Flexible Architecture) best practices, extract the zipfile under ${ORACLE_BASE}/local:
(Installation/Upgrade) The initial configuration is done with the same script (dmk.sh) as you set the environment afterwards.
The first time it creates the ~/.DMK_HOME configuration file (if inexistent) with the location of DMK. For that step, the script can be executed or sourced.
Also the first time it configures rlwrap (if there is no symlink $DMK_HOME/bin/rlwrap).
If rlwrap is found in the PATH, it creates a symlink $DMK_HOME/bin/rlwrap to it.
if rlwrap is not found in the PATH, the dmk-provided version rlwrap.$(uname) will be moved to $DMK_HOME/bin/rlwrap_dmk and it creates a symlink $DMK_HOME/bin/rlwrap to it.
Additionally for Linux: it links the current /usr/lib64/libreadline.so.<version> to $DMK_HOME/lib/libreadline.so.6. With this, the provided version works with EL7 - EL9.
At the end, all $DMK_HOME/bin/rlwrap.<OS-Name> binaries will be removed.
In case of an upgrade from DMK 1.x: The former dmk.conf file will be converted to dmk.conf.local and the old file is renamed to dmk.conf.old; In the new file there are only the lines you changed/added. The unchanged lines from the template are removed.
The template lines are now in dmk.conf.default (do NOT change this file! it will be overwritten with the next update).
The oratab file should no longer be adapted for DMK specific settings. After the upgrade from DMK 1.x, we recommend to cleanup the oratab file. Remove dummy-entries, remove PDB's from the SID-entries. This information is now stored in new configuration files, see later.
Hint for upgrade: If you used dmk.bash / dmk.ksh in your scripts: There is no need to update it to dmk.sh; It references the same code (symlink).
Each time dmk.sh is called, it tries to automatically configure or update the environment. It detects the ORACLE_HOME's, the SIDs, then it creates or updates the configuration files. If this automatic procedure fails, it can be configured manually.
To activate DMK, it must be sourced (mind the dot and space before the script, otherwise the script is executed and not sourced)
Source dmk.sh in your profile.
Profile for ksh is ~/.profile
Profile for bash is ~/.bash_profile (or .profile if .bash_profile is missing). We recommend to use the same file for ksh and bash by creating a symlink: ln -s ~/.bash_profile ~/.profile
You can use the provided template
Or if you prefer a minimal version, add this line to your profile:
If you do not want to automatically activate DMK at login, create an easy to remember alias to source DMK manually:
Or if you want to activate DMK automatically only in interactive shells:
An existing DMK installation can also be used by other users, if the necessary privileges are correctly set (especially write-access to the log-directory: chmod 1777 $ORACLE_BASE/local/dmk/log).
For an installation of Grid Infrastructure with role separation (users grid and oracle), it is recommended to change all files and directories to the common oinstall group and give write-access to the group.
Ensure that /home/oracle/.DMK_HOME file is readable by the other user. Check that the files in $ORACLE_HOME/perl are readable/executable for the user (depending on the Oracle version these permissions are restricted and must be changed).
If you want to fully deinstall DMK:
If you used the DMK scripts for automatic Oracle services startup at boot-time, then you also have to revert that (as root).
🪟 For Windows we recommend installing .