# Functionalities & Features ## 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 Supported login-shells are ksh and bash.\ Depending on your SHELL the profile in $HOME is: * for ksh: `.profile` * for bash: `.bash_profile`, fallback to `.profile` We recommend to use the same profile for both shells: `ln -s .bash_profile .profile`; (if re-sourcing .profile, it reduces the risk to accidentially 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 (within the same section): | 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/` | 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.* [] 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: ```bash # 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: ```bash # 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 #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\_\ 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 form 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 ….) and creates variables and aliases for it. Details of the feature: * For module directories located in $cdl, $DMK\_BASE (the directory above dmk, usually ${ORACLE\_BASE}/local), it creates aliases and variables, except: * Directories containing a dot "." or slash "-" are ignored (incl. 🐧 hidden files) * Directories beginning with a number are ignored * πŸͺŸ Subdirectory "local" is ignored ("local" in %DMK\_BASE% is OK) * Subdirectory "dmk" is ignored. For this core module, the handling is different. See below. * :warning:Caution! DO NOT rename old releases, it will be included as a "new" tool, except: you rename it with a pattern mentioned above (e.g. 2.1.0\_dmk or dmk-backup or .dmk) * For DMK modules (beginning with dmk\_), it creates shortname aliases prefixed with dmk to change to this directory * **dmkbackup** (cd $DMK\_BASE/dmk\_dbbackup) * **dmkcreate** (cd $DMK\_BASE/dmk\_dbcreate) * **dmkduplicate** (cd $DMK\_BASE/dmk\_dbduplicate) * **dmkha** (cd $DMK\_BASE/dmk\_ha) * **dmksql** (cd $DMK\_BASE/dmk\_sql) * For non-DMK directoris, it creates an alias with the lowercase directory-name * It creates an uppercase variable of the directory name containing the full path (DMK\_DBBACKUP=$DMK\_BASE/dmk\_dbbackup) * The System variable ${PATH} is extended with the β€œbin” directory * The Oracle variable ${SQLPATH} is extended with the β€œsql” directory ``` oracle@vmoraoel:/home/oracle/ [rdbms1120] ls -d /u01/app/oracle/local/Demo/* /u01/app/oracle/local/Demo/bin /u01/app/oracle/local/Demo/sql 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 ``` :information\_source: For the core "dmk" module, there is no alias "dmk" for "cd $DMK\_BASE/dmk". Instead, the alias is named `cdd` (the alias `dmk` is used to re-source the dmk environment). Additionally, there are aliases for the subdirectories in $DMK\_BASE/dmk with the following naming scheme: cdd.\, e.g. * alias **cdd.bin**='cd $DMK\_BASE/dmk/bin' * alias **cdd.templates**='cd $DMK\_BASE/dmk/templates'