Functionalities & Features

This chapter presents the built-in functionality and features of DMK.

Automatic activation of DMK

🪟 Windows desktop link

The first time you start dmk\bin\dmk.cmd, it creates a desktop icon to start DMK. These windows can be customized. Click on the top-left corner of the window, the you can adapt the properties (fontsize, color, terminalsize).

If you do not want such a desktop link, set the variable DMK_NO_DESKTOP_LINK=1 (in dmk.conf.local)

🐧 Linux/Unix login-Shell profile

Depending on your SHELL the profile in $HOME can be called “.profile” or “.bash_profile”. For bash, we recommend to 'ln -s .bash_profile .profile'; (reduces the risk to source .bash_history instead of .bash_profile)

cat ${DMK_HOME}/templates/profile/dmk.oracle.profile >> ~/.profile

Alias & Variable Management :

DMK uses the following configuration files (values in later listed files replaces values in earlier files):

File	Description
$DMK_HOME/etc/dmk.conf.default	Default configuration file provided by DMK. It must not be changed, it will be overwritten with the next upgrade. It is a symlink to templates/etc/dmk.conf.unix or a copy of dmk.conf.win
$DMK_HOME/etc/dmk.conf.global	Optional. You can create such a file to set your company-wide defaults
$DMK_HOME/etc/dmk.conf.local (1)	The configuration file for your changes of dmk.conf.default lines and for your additional configuration.
$DMK_ORA_ADMIN_SID/dmk/$ORACLE_SID.conf	SID-specific configuration
$DMK_ORA_ADMIN_SID/dmk/pdbs/<pdbname>	PDB specific configuration

For a database instance, the $ORACLE_SID.conf file will be automatically created the first time the SID is sourced. dmk tries to add the variables

• NLS_LANG (2)

• DMK_ORA_DB_NAME

• DMK_ORA_DB_UNIQUE_NAME For non-database SIDs you can manually create such a file if required (e.g. for "+ASM" SID) |

(1) 🐧 If upgrade from Release1: changed entries in dmk.conf will be migrated to dmk.conf.local; Afterwards, dmk.conf is ignored.

(2) The value of NLS_LANG (default is: NLS_LANGUAGE||'_'||NLS_TERRITORY||'.'||NLS_CHARACTERSET from nls_database_parameters) can be changed to any other valid string if you need a different setting in the shell (e.g., if you have 8bit sql-scripts, but your database is in AL32UTF8).

DMK set the environment in 3 steps.

All these steps match to a section from the configuration files listed above. Which are defined by brackets “[…]”, example follows:

[GLOBAL]
var::ORATAB::=::nooption::"/etc/oratab"::
…
alias::vio::novar_noforce::"vi ${ORATAB}"::
[SID]
var::DMK_ORA_ADMIN_SID::=::nowarn::"${ORACLE_BASE}/admin/${ORACLE_SID}"::
…
alias::cda::var_noforce::'cd ${DMK_ORA_ADMIN_SID}'::

## This section should be stored in a file per SID, not in $etc/dmk.*
[<ORACLE_SID>]
var::…

Environment files for Oracle

oratab

Before release 2 of DMK, additional information about ORACLE_SIDs had to be added to Oracle's "oratab" file. But these changes were not supported by Oracle. In Grid Infrastructure environments the entry was often replaced by clusterware processes.

From release 2, DMK will leave the oratab untouched (and the dmk.oratab is no longer used). The information that DMK needs is now stored in the following two files:

$DMK_HOME/etc/ora_homes: Information about ORACLE_HOME's

$DMK_HOME/etc/ora_sids: Information about ORACLE_SID's

The source of the information is oratab, oraInventory, oragchomelist and the cluster-registry.

ora_homes

The file is initially generated with a header explaining the format:

# ORACLE_HOME;product;version;inventoryname;ORACLE_BASE
# Directory of the software;
#     ;product;
#     ;rdbms_[ee|se|xe]; Database ee=Enterprise-, se=Standard-, xe=Express-Edition
#     ;grinf; Grid-infrastructure, clusterware
#     ;client; Oracle Client
#     ;em; Enterprise Manager
#     ;emagent; Enterprise Manager Agent
#     ;wls; Weblogic
#     ;OTHER; none of above products detected
#     ;HIDE; ignore this home, do not generate any aliases
#         ;version;
#         ;a.b.c; e.g. 9.2.0,12.2.0,19.16.0
#         ;AUTO; leave empty -> determine at runtime (recommended)
#         ;NA; not applicable, for products without this versioning schema
#             ;Name;
#             from oraInventory
#             $ORACLE_BASE/homes/name with read-only oracle-home's
#                 ORACLE_BASE
#                 Directory of DIAGNOSTIC_DEST and admin-dir.
/u00/app/oracle/product/12.2.0.1;db_ee;AUTO;OraDB12Home2;/u00/app/oracle
/u00/app/oracle/product/11.1.0;db_ee;AUTO;OraDB11Home1;/u00/app/oracle

The entries for database homes are automatically added if found in oraInventory/ContentsXML/inventory.xml or oratab;

ora_sids

This file is initially generated with a header explaining the format:

# ORACLE_SID;ORACLE_HOME;ADMIN_DIR;type;crstype;instances
# Name of the sid; (db_unique_name for RAC)
#     ;ORACLE_HOME;
#         ;ADMIN_DIR; usually $ORACLE_BASE/admin/$ORACLE_SID
#             ;type;
#             ;I; Database Instance (Non-RAC)
#             ;D; Db_unique_name of a RAC Database
#             ;A; ASM-Instance
#             ;H; oracle_Home - dummy entry not pointing to a real Instance
#             ;M; Grid-infra management repository database
#             ;HIDE; ignore this SID, do not generate any aliases
#                 ;crstype; GridInfra-/Clusterware-Type
#                 ;xy;
#                 x: R=RAC, O=RacOneNode, S=Single, F=Failover
#                 y: A=Admin-managed, P=Policy-managed
#                 ;RA; RAC Admin-managed
#                     ;instances
#                     ;rac1@host1,rac2@host2 Admin-managed
Instance(s) of RAC database
#                     ;rac% Policy-managed/RacOne Instance of RAC database
rdbms21ee;/u00/app/oracle/product/21;H;
DB2100;/u00/app/oracle/product/21;I;

The entries for Database-Instances are taken from the oratab file or the cluster registry (crsctl).

The order of the lines corresponds to the order in the DMK_LIST_SIDS* variables. With this order, you can priorize instances if you loop over the variable content.

If the former Dummy entries (field 3 is D) are present in oratab, it will be used as type "H".

Otherwise for each ORACLE_HOME a "H"ome entry is generated. There are defaults for the dummy SID-name, e.g.

rdbms1900          #Database Release 19c
grinf19            #Grid-infrastructure 19c
<product><xxyyzz>  #for any other products

Hint: afterwards, you can manually adapt the name in the ora_sids file.

The default for release < 18c is constant (rdbmsAABC). For releases 18c or later the default can be adapted with the variables DMK_HOMEFORMAT_RDBMS for databases or DMK_HOMEFORMAT_<product> for any other product as specified in ora_homes file (field2 in uppercase, e.g. GRINF, EMAGENT).

For a Release- or Version-number in the for m X.Y.Z you can use the following variables:

Version {{V01}} (for X), {{V02}} (for Y), {{V03}} (for Z) - each with 2digit.

Release {{R01}} (for X), {{R02}} (for Y), {{R03}} (for Z) - each with 2digit.

Release {{R1}} (for X), {{R2}} (for Y), {{R3}} (for Z) - 1 or 2 digit.

Edition: {{ed}} / {{ED}} se/SE Standard-, ee/EE Enterprise-, xe/XE Express-Edition

Examples :

DMK_HOMEFORMAT_RDBMS='{{V01}}{{V02}}{{V03}}' # 12.2.0 -> rdbms120200, 19.15.0 -> rdbms191500
DMK_HOMEFORMAT_RDBMS='dbhome{{R01}}_{{ed}}'  # 18.4.0 XE -> dbhome18_xe,
                                             # 19.15.0 Enterprise -> dbhome19_ee
DMK_HOMEFORMAT_GRINF='gi{{R01}'              # 21.5.0 -> gi19

Recommendation: If you only have one ORACLE_HOME per release and you apply release updates to the existing home, then we recommend DMK_HOMEFORMAT_RDBMS='rdbms{{R01}}{{R2}}{{R3}}' or 'rdbms{{R01}}', otherwise we recommend DMK_HOMEFORMAT_RDBMS='rdbms{{V01}}{{V02}}{{V03}}'.

If the name is already in use, a suffix "_a" to "_zz" is appended to make it unique.

rdbms191300;/u00/app/oracle/product/19.13.0;;H; # rdbms{{V01}}{{V02}}{{V03}}
rdbms1900;/u00/app/oracle/product/19.13.0;;H;   # rdbms{{R01}}{{R2}}{{R3}}
rdbms19;/u00/app/oracle/product/19.13.0;;H;     # rdbms{{R01}}
rdbms19_a;/u00/app/oracle/product/19.13.0se;;H; # rdbms{{R01}} -> dummy-name not unique,
 # _a appended

Defaults: If DMK_HOMEFORMAT_RDBMS is not specified, the default is rdbms{{R01}}{{R2}}{{R3}} for the first home of this release and rdbms{{V01}}{{V02}}{{V03}} for the other homes of this release. Example:

rdbms1800;/u00/app/oracle/product/xe-18.4.0;;H; # first home rdbms{{R01}}{{R2}}{{R3}}
rdbms181000;/u00/app/oracle/product/18;;H;      # next homes rdbms{{V01}}{{V02}}{{V03}}
rdbms180300;/u00/app/oracle/product/18.3.0;;H;

Usage: Instead of setting an environment with the dummy-SID, you can also set a dummy environment by specifying an ORACLE_HOME. In this case, the first "H" entry in ora_sids of this home will be used.

. dmk.sh /u00/app/oracle/product/21  # will set the environment for rdbms21ee in the above example

Automatic creation of aliases and variables for modules

DMK interacts with other dbi services toolkits (DMK_HA,DMK_DBBACKUP,DMK_SQL, aso ….).

Details of the feature:

• Directories located in $cdl (the directory above dmk, usually ${ORACLE_BASE}/local)

  • ⚠️Caution! DO NOT rename old releases, it will be included as a "new" tool, except: you rename it as a hidden Unix directory (beginning with '.') or it contains '-'

• Creates an alias and a variable with the name of the directory in Uppercase

• The System variable ${PATH} is extended with the “bin” directory

• The Oracle variable ${SQLPATH} is extended with the “sql” directory and ordered if the subdirectories “oracle10” and “oracle11” are created.

oracle@vmoraoel:/home/oracle/ [rdbms1120] ls -d /u01/app/oracle/local/demo/*
/u01/app/oracle/local/demo/bin
oracle@vmoraoel:/u01/app/oracle/local/ [rdbms112] alias demo
alias demo='cd /u01/app/oracle/local/demo'
oracle@vmoraoel:/u01/app/oracle/local/ [rdbms112] echo ${PATH}
...:/u01/app/oracle/local/demo/bin
oracle@vmoraoel:/u01/app/oracle/local/ [rdbms112] echo ${SQLPATH}
...:/u01/app/oracle/local/demo/sql
oracle@vmoraoel:/u01/app/oracle/local/ [rdbms112] echo ${DEMO}
/u01/app/oracle/local/demo

⚠️Aliases won’t be created for directories containing the hyphen “-“character.