Andre Luiz Dutra Ontalba (Board Member)
Oracle E-Business Suite 12i Architecture (Part 2)
Category: E-Business Suite Author: Andre Luiz Dutra Ontalba (Board Member) Date: 4 years ago Comments: 0

Oracle E-Business Suite 12i Architecture (Part 2)


Shared Application System


A traditional multi-node installation of EBS 11i required each application layer to maintain its own file system, which consists of the APPL_TOP file system (APPL_TOP, COMMON_TOP, and some related directories) and application tier technology file stack layer (8.0 .6 ORACLE_HOME and IAS ORACLE_HOME).
Subsequently, this was modified to allow APPL_TOP to be shared between different machines, and subsequently to allow sharing of the entire application layer file system.
Continuing this quick installation strategy, for version 12 it creates a system that shares not only APPL_TOP and the COMMON_TOP file systems, but also the application tier technology stack layer.
Rapid Install sets this setting as the default for nodes running on the same operating system.
These files form the application layer of the file system, and can be shared between application nodes in multiple layers (as long as they are running the same operating system).
 
Note: Shared file system configuration is not currently supported on application tier nodes servers running Windows.
 
With a shared application layer file system, all files in this application layer are installed on a single shared disk that is mounted from each application layer node.
 
 Any application layer node can be used to provide standard services, such as a Forms, Web Pages or Concurrent server.

Shared application layer – Example
As well as reducing required disk space, there are several other benefits of setting up shared application levels:
 
  • More administrative tasks, patching and maintenance need to be done only once, instead of a single layer application node.
 
  • Changes made to the shared file system are immediately accessible on all nodes in the application layer.
 
  • Distributes task processing to run in parallel on multiple nodes (Distributed AD).
 
  • Reduces general disk requirements.
 
  • Add application nodes more easily.
 

Sharing the File System application between instances.

 

Capabilities to share the tiered file system application were further extended in version 12.0.4, which introduced the option to share an installation of Oracle E-Business Release 12 with another instance of the database.
 
An application file system layer installed and configured in this way can be used to access two (or more) database instances.
 
The restrictions to this are:
 
  • All database instances must have the same patches.
 
  • Only the application can be shared, the database cannot be shared.
Nota: For more information on features, options and implementation steps, see document 384248.1, Sharing the Application Tier File System in Oracle E-Business Suite Release 12.

 

 

Environment Setting

 

Rapid Install creates environment files to configure the Oracle database, Oracle’s technology suite, Oracle HTTP Server, and Oracle E-Business Suite environments.
 
The location of these environment files is shown in the following table:
 
Filename
Location
Path
Environment

<CONTEXT_NAME>.env or CONTEXT_NAME>.cmd

10.2.0.2 ORACLE_HOME

db/tech_st/10.2.0

Oracle Server Enterprise Edition

<CONTEXT_NAME>.env or <CONTEXT_NAME>.cmd

OracleAS 10.1.2 ORACLE_HOME

inst/apps/<context>/ora/10.1.2

Oracle tools technology stack

<CONTEXT_NAME>.env or <CONTEXT_NAME>.cmd

OracleAS 10.1.3 ORACLE_HOME

inst/apps/<context>/ora/10.1.3

Java technology stack

<CONTEXT_NAME>.env or <CONTEXT_NAME>.cmd

APPL_TOP

apps/apps_st/appl

Applications

APPS<CONTEXT_NAME>.env or APPS<CONTEXT_NAME>.cmd

APPL_TOP

apps/apps_st/appl

Consolidated setup file

 

On UNIX, Oracle E-Business Suite includes a consolidated file called APPS <CONTEXT_NAME> .Env, which establishes both Oracle E-Business Suite and Oracle technology stack environments.
 
  When you install Oracle E-Business Suite, Rapid Install creates this script in the APPL_TOP directory. Many of the parameters are specified during the installation process.
 
On Windows, the consolidated equivalent environment file is called% APPL_TOP% \ envshell <CONTEXT_NAME> .cmd.
 
When running it creates a command window with the necessary environment settings for Oracle E-Business Suite. All subsequent operations on APPL_TOP (for example, running adadmin or adpatch) must be performed from this window.
The following table lists the key environment settings in APPS <CONTEXT_NAME> .env.
 
Parameter
Description

APPLFENV

The name of the environment file, <CONTEXT_NAME>. env. If you rename the environment file, this parameter must be updated.

PLATFORM

The operating system in use. The value (for example, LINUX) must match the value in the APPL_TOP/admin/ adpltfrm.txt file.

APPL_TOP

The main directory for this Oracle E-Business Suite installation.

ADMIN_SCRIPTS_HOME

$ INST_TOP directory that identifies the location of scripts, such as adautocfg.sh, adpreclone.sh, adstrtal.sh and adstpall.sh.

FNDNAM

The name of the ORACLE scheme to which the System Administration responsibility connects. The default is APPS.

GWYUID

The public ORACLE username and password that gives access to the initial Oracle E-Business Suite sign-on form. The default is APPLSYSPUB/PUB.

FND_TOP

The path to the Application Library Object directory. For example, apps /apps_st/appl/fnd/12.0.0.

AU_TOP

The path to the Applications Utilities directory. For example, apps /apps_st/appl/au/12.0.0.

<PROD>_TOP

The path to a product’s top directory. There is an entry for each Oracle E-Business Suite product.

PATH

Sets the directory search path, for example, to FND_TOP and AD_TOP.

APPLDCP

Specifies whether the distributed Concurrent Process is in use. If it is the same it distributes the load in other Concurrent Process in other nodes.

APPCPNAM

Indicates whether the format of the Concurrent Manager log and the output files following the 8.3 file name convention (maximum 8 characters to the left of the dot and 3 to the right, for example, alogfile.log). If this parameter is set to “REQID” (required), Concurrent Manager uses filenames that meet 8.3 naming requirements.

APPLCSF

Identifies the top level directory for Concurrent Manager log and output files. They are consolidated into a single directory for all products.

For example, /inst/apps/<context>/logs/appl/conc.

APPLLOG

The subdirectory for Concurrent Manager concurrent log files. The default is extension .log

APPLOUT

The subdirectory for Concurrent Manager’s simultaneous output files. The default is .out

APPLTMP

Identifies the directory of temporary Oracle E-Business Suite files. The default is $ INST_TOP/tmp on UNIX.

APPLPTMP

Identifies the directory for the output temporary PL/SQL files. The possible directory options must be listed in the utl_file_dir parameter init.ora.

INST_TOP

Identifies the top level directory for this instance. For example, inst/apps/<context>.

Introduced with Release 12.

NLS_LANG

The language, territory, and character set installed in the database. The default for a new installation is “AMERICAN_AMERICA.US7ASCII”.

NLS_DATE_FORMAT

The National Language Support date format. The default is “DD-MON-RR”, for example, 14-July-19.

NLS_NUMERIC_CHARACTERS

The National Language Support numeric separators. The default is “.” (Semicolon).

 

Most temporary files are written to the location specified by the APPLTMP environment configuration, which is defined in the Rapid Install.
 
Oracle E-Business Suite products also create temporary PL/SQL output files used in simultaneous processing. These files are written to a location on the database server node specified by the APPLPTMP environment configuration.
 
The APPLPTMP directory must be the same directory specified by the utl_file_dir parameter in your database initialization file.
Rapid Install sets both APPLPTMP and the utl_file_dir parameter to the same default directory.
 
Some Oracle Utilities E-Business Suite use your temporary default operating system directory even if you configure the environment settings listed in the previous paragraph. You must therefore ensure that there is sufficient free disk space in this directory, as well as those indicated by APPLTMP and APPLPTMP.
 
In a multi-node system, the directory defined by APPLPTMP does not need to exist on application layer servers.
 
Nota: Temporary files placed in the utl_file_dir directory can be protected from unauthorized access, ensuring that this directory has read and write access to the Oracle database account only.
 

Other environments files

 

Several other key environment files are used in an Oracle E-Business Suite system.
 

O arquivo adovars.env

 

    The adovars.env file, located at $ APPL_TOP/admin, specifies the location of several files, such as Java files, HTML files and the JRE (Java Runtime Environment) files.

 

It is called from the main application environment file, <CONTEXT_NAME>. Env. The adovars.env file includes comments on the purpose and recommended configuration of each variable. In a 12 release environment, adovars.env is maintained by AutoConfig, and should not be edited manually.
 
The adovars.env file includes the following parameters:
 
Parameter
Description

AF_JLIB

Indicates the directory to which all Java archive files are copied. For example, apps /apps_st/COMn/java/lib. Introduced with Release 12.

JAVA_BASE

Indicates the top level of the Java directory. For example, apps/apps_st/COMn/java. Introduced with Release 12.

JAVA_TOP

Indicates the directory to which all Java class files are copied. For example, apps/apps_st/COMn/java/classes. Definition changed with version 12.

OA_JAVA

Indicates the directory to which all Java archive files are copied. For example, apps/apps_st/COMn/java/classes.

OA_JRE_TOP

Indicates the location where the JRE is installed. For example, /local/java/jdk1.5.0_08.

OAH_TOP

Sets the location to which HTML files are copied. For example, apps /apps_st/COMn/webapps/oacore.

OAD_TOP

Defines the locations to which context-sensitive documentation files are copied. For example, apps/apps_st/COMn.

LD_LIBRARY_PATH

Path used on many UNIX platforms to list the directories being scanned for dynamic library files needed at run time.

CLASSPATH

Lists scanned directories and zip files for Java class files needed at run time.

 

 

The adconfig.txt file

 

AD utility programs perform a variety of database and file management tasks. These utilities need to know information about the right configuration to run successfully. This configuration information is specified when Oracle E-Business Suite is installed and subsequently stored in the adconfig.txt file in <APPL_TOP> / admin. Once created, this file is used by other Oracle E-Business Suite utilities.
 
Nota: adconfig.txt is created with the APPL_TOP file system, and shows the layers that have been configured on a particular node. It is distinct from the config.txt file configured by Rapid Install.
 

The fndenv.env file

This file defines environment variables used by the application’s object library. For example, it defines APPLBIN as the name of the subdirectory where executable product programs and shell scripts are stored (bin). This file must not be modified: the default values are applicable for all customers. The file is located in the FND_TOP directory.

 

The devenv.env file

This file defines the variables that allow you to link third-party software and your own custom applications developed with Oracle E-Business Suite.
In version 12, this script is located in $ FND_TOP / usrxit, and is automatically called by fndenv.env. This allows you to compile and link custom forms for Oracle users to outbound and competing programs with Oracle E-Business Suite.
 
 
In the next articles, we will continue to understand the structure of the E-Business Suite and guide best practices for installing the product efficiently.

 

References
 
Oracle E-Business Suite Release 12 Technology Stack Documentation Roadmap [ID 380482.1]
 
I hope this help you !!

 

André Ontalba

 

Disclaimer: “The postings on this site are my own and don’t necessarily represent may actual employer positions, strategies or opinions. The information here was edited  to be useful for general purpose, specific data and identifications was removed to allow reach generic audience and to be useful.”

 


Oracle E-Business Suite 12i Architecture
Category: E-Business Suite Author: Andre Luiz Dutra Ontalba (Board Member) Date: 4 years ago Comments: 0

Oracle E-Business Suite 12i Architecture

Introduction

An Oracle E-Business Suite Release 12i is a system that uses components from various Oracle products.
These files are stored in a product structure, below we will see some of the top-level directories in the database and application server.
Depending on how you chose to install Oracle E-Business Suite, these product directories can be located on a single machine (1 node) or multiple machines  (multiple nodes).
Oracle E-Business Suite directory structure
  • The db/apps_st/datadirectory is located on the database node machine, and contains the system tablespaces, redo log files, data tablespaces, index tablespaces, and database files
  • The db/tech_st/11.1.0directory is located on the database node machine, and contains the ORACLE_HOME for the Oracle 11g database
  • The apps/apps_st/appl(APPL_TOP) directory contains the product directories and files for Oracle E-Business Suite
  • The apps/apps_st/comn(COMMON_TOP) directory contains Java classes, HTML pages, and other files and directories used by multiple products
  • The apps/tech_st/10.1.2directory contains the ORACLE_HOME used for the Oracle E-Business Suite technology stack tools components
  • The apps/tech_st/10.1.3directory contains the ORACLE_HOME used for the Oracle E-Business Suite technology stack Java components
 

Oracle E-Business Suite Environment

Oracle E-Business Suite makes extensive use of environment settings to find executable programs and other files essential to Oracle E-Business Suite.
These environment settings are set when you install Oracle E-Business Suite.
Many of the settings are set by information that you provide when running Rapid Install, while others have the same values across all installations.
Environment settings and their associated values are stored in environment files, which have a .env suffix in UNIX  or . cmd  in Windows.
Files and environment settings we will talk about the continuity of the blog.
Instance Home ($INST_TOP)
Oracle E-Business Suite Release 12i  introduces the concept of a directory to an Oracle E-Business Suite instance. This directory is referred to as Instance Home and denoted by the environment by the variable $INST_TOP.
Using an Instance Home, it also provides the ability to share applications and technology stack code between multiple instances for example, one a development instance and one test instance.  
Other benefits include support for read-only file systems and centralization of log files, these items among others will be covered in other blogs.
The basic structure of instance home is:
/inst/apps/, where APPS_BASE (which does not have or need a corresponding environment variable) is the highest level of the Oracle E-Business Suite installation and  the  is the highest level at which the applications context exists.
For example, the $INST_TOP setting can be /applmgr/inst/apps/test, where test is the context name.
All configuration files created by  AutoConfig are stored under  the Instance Home. This makes it easy to use a shared application filesystem.
 
Instance Home structure

Read-Only File Systems

One of the main benefits of moving to the new Instance Home model is that because AutoConfig no longer writes to directories APPL_TOP or ORACLE_HOME, both can be done on read-only file systems if necessary.

In earlier versions of Oracle E-Business Suite, the adpatch utility changed  $APPL_TOP/admin in a patching application.  Under the new template, $APPL_CONFIG_HOME/admin is used.

$APPL_CONFIG_HOME vai is equivalent to um value such as /u01/oracle/VIS/apps/apps_st/appl.

Important: In a shared file system environment, Oracle recommends that $INST_TOP should be located on a local disk and not on a shared resource, such as NFS, because of potential issues that store log files on shared resources.


Log Files

 

The advantage of employing the concept of an Instance Home is that log files can be centrally stored by an instance and therefore more easily managed.
The following diagram shows the directory structure used for log files in Release 12i, with some of the subdirectories used to sort the log files:
Log Files Structure

DATA Directory

The db/apps_st/data  directory stores the different file types used by the Oracle database. Rapid Install places the system, data, and index files in directories  with multiple file system mount points on the database machine. You can specify these mount points during installation.

COMN Directory

 The apps/apps_st/comn  (COMMON_TOP) contains files used by different Oracle E-Business Suite products, which can also be used with third-party products.
COMMON_TOP structure

ADMIN Directory

The admin directory, under the COMMON_TOP directory, is the default location for the concurrent manager log and output directories. When the concurrent managers run Oracle E-Business Suite reports, they write the log files and temporary files to the log subdirectory of the admin directory, and the output files to the out subdirectory of the admin directory.
You can change the location the concurrent managers write these files to, so that, for example, the log and output files are written to directories in each <PROD>_TOP directory.
This may be more desirable in terms of disk space management, or the need to avoid a possible performance bottleneck on a system that has a high concurrent processing throughput.
The install subdirectory of the admin directory contains scripts and log files used by Rapid Install. The scripts subdirectory of admin contains scripts used to start and stop services such as listeners and concurrent managers.

 

HTML Directory

The OA_HTML environment setting points to the html directory. The Oracle E-Business Suite HTML-based sign-on screen and Oracle HTML-based Applications HTML files are installed here.
The html directory also contains other files used by the HTML-based products, such as JavaServer Page (JSP) files, Java scripts, XML files, and style sheets.
Typically, the path will look like: <diskresource>/applmgr/apps/apps_st/comn/webapps/oacore/html.
Important: The META-INF and WEB-INF subdirectories were introduced in Release 12 to meet J2EE specifications.
 

JAVA Directory

Release 12 introduces some significant changes to the locations in which the various types of Java files are stored. Rapid Install installs all Oracle E-Business Suite class files in the COMMON_TOP/classes directory, pointed to by the $JAVA_TOP environment variable.
Zip and jar files are installed in the $COMMON_TOP/java/lib directory, pointed to by the $AF_JLIB environment variable (introduced with Release 12).
 The top-level Java directory, $COMMON_TOP/java, is pointed to by the $JAVA_BASE environment variable.

 

UTIL Directory

The util directory contains the third-party utilities licensed to use  with Oracle E-Business Suite. These include, for example, the Java Runtime Environment (JRE), Java Development Kit (JDK) and the Zip util.

 

The APPL  directory

Oracle E-Business Suite files are stored in the <dbname>APPL directory, which is generally known as the APPL_TOP directory.

 

APPL_TOP Directory Structure
The APPL_TOP directory contains:
  • The core technology files and directories.
  • The product files and directories (for all products).
  • The main Oracle E-Business Suite environment file, called <CONTEXT_NAME>.env on UNIX, and <CONTEXT_NAME>.cmdon Windows.
  • The consolidated environment file, called APPS<CONTEXT_NAME>.env on UNIX, and APPS<CONTEXT_NAME>.cmd on Windows.
Warning: Regardless of registration status, all Oracle E-Business Suite products are installed in the database and the file system. Do not attempt to remove files for any unregistered products.
Rapid Install installs a new APPL_TOP directory when you upgrade. Rapid Install does not delete any existing product files from earlier releases, but unloads new product files into a new apps/apps_st/appl directory tree.
Each APPL_TOP directory is associated with a single Oracle E-Business Suite database. If you install both a Vision Demo system and a test system, Rapid Install will lay down two file systems, one for each of these Oracle E-Business Suite systems.
 

Product Directory

Each product has its own subdirectory under APPL_TOP. Subdirectories are named according to the product’s default abbreviation, such as gl for Oracle General Ledger.
Within each product directory is a subdirectory that has the name using the Base Oracle E-Business Suite Release number, such as 12.0.0 for the initial release of 12. This directory contains the different subdirectories for the product files.

 

<PROD>_TOP Directory

The <APPL_TOP>/<prod>/<version> path is known as the product top directory (<PROD>_TOP), and its value is stored in the <PROD>_TOP environment variable.
For example, if APPL_TOP=/u01/prodapps, then the value contained in the AD_TOP environment variable is /u01/prodapps/ad/12.0.0, and the AD_TOP environment variable points to the <APPL_TOP>/ad/12.0.0 directory.
For the same APPL_TOP, the value of AU_TOP is /u01/prodapps/au/12.0.0, and the AU_TOP environment variable points to the <APPL_TOP>/au/12.0.0 directory. The same principle applies to all directories, apart for the admin directory.

 

Product Files

Each <PROD>_TOP directory, such as <APPL_TOP>/gl/12.0.0, contains subdirectories for product files. Product files include forms, report files, and files used to update the database.
To view the forms of data entry for Oracle General Ledger, for example, Oracle E-Business Suite accesses files in the subdirectory forms under directory 12.0.0.

 

APPL_TOP Directory Structure
Within each <PROD>_TOP directory, the product’s files are grouped into subdirectories according to file type and function. The next figure expands the inset to show the full directory structure for gl.
GL Structure Detail
The following table summarizes product subdirectories and the types of files each one may contain.

 

Subdirectory Name
Description
admin
The <PROD>_TOP/admin directory contains product-specific files used to upgrade each product. This is in distinction to the <APPL_TOP>/admin directory, which contains upgrade-related files for all products.
driver
Contains driver files (.drv files) used in upgrading.
import
Contains DataMerge files used to upgrade seed data.
odf
Contains object description files (.odf files) used to create tables and other database objects.
sql
Contains SQL*Plus scripts used to upgrade data, and .pkh, .pkb, and .pls scripts to create PL/SQL stored procedures.
bin
Contains concurrent programs, other C language programs and shell scripts for each product.
forms
Contains Oracle Forms generated runtime (.fmx) files (Oracle Forms form files).
help
Contains the online help source files. Within this directory are subdirectories for each language installed.
html
Contains HTML, JavaScript, and JavaServer Page (JSP) files, primarily for HTML-based Applications products.
include
Contains C language header (.h) files that my be linked with files in the lib directory. Not all products require this directory.
java
Contains JAR files (Java Archive files) and Java dependency files. Copies of JAR files are also located in the $AF_JLIB directory.
lib
Contains files used to relink concurrent programs with the Oracle server libraries. These files include:
·       object files (.o on UNIX, .OBJ on Windows), with compiled code specific to one of the product’s programs.
·       library files (.a on UNIX, various including .DLL on Windows), with compiled code common to the product’s programs.
make files (.mk) that specify how to create executables from object files and library files.
log and out
Contains output files for concurrent programs:
·       .mgr (master log file for concurrent manager)
·       .req (log file for a concurrent process)

Note that log and out subdirectories under a product directory are not used if you choose to set up a common directory for log and output files (FND_TOP is the only exception to this).
media
Contains .gif files used in the display of text and graphics on the desktop client.
mesg
Concurrent programs also print messages in the log and output files. This directory contains the .msb files (binary message files used at runtime), and language-specific message files (such as a US.msb file for American English and a D.msb file for German). The files contain the forms messages that are displayed at the bottom of the screen or in popup windows.
patch
Updates to the data or data model utilize this directory to store the patch files.
reports
Contains Oracle Reports platform-specific rdf binary report files for each product. Reports for each language are stored in subdirectories of the reports directory.
resource
Contains .pll files (PL/SQL library files for Oracle Forms), which, like the plsql directory files, are later copied to AU_TOP.
sql
Contains .sql files (SQL*Plus scripts) for concurrent processing.

 

 

Language Files

When you install Oracle E-Business Suite in a language other than American English, each product tree includes directories that use the relevant NLS language code. These directories hold translated data, forms, and message files.
For example, the language directory named D designates German. The data loader files in the D subdirectory of the admin directory contain the German translation of the product seed data.
The US subdirectory in the forms directory contains Oracle Forms forms in American English. The D directory in the forms directory contains the same forms, translated into German. However, the mesg directory contains message files in both American English and German.

 

Core Technology Directory

 

The administrator, ad, au, and FND directories are the central directories of technology.

 

The admin directory

This directory and its subdirectories contain files and scripts used by AD during the upgrade and maintenance processes.
These files and scripts include:
  • The adovars.env environment file, which defines certain file and directory locations
  • Scripts run during the upgrade
  • <SID>/log and <SID>/out directories for upgrade, log, and output files respectively
  • A <SID>/restart directory where AD programs create restart files
 

The ad (Applications DBA) directory

This directory and its subdirectories contains installation and maintenance utilities, including:
  • AD Administration (adadmin)
  • AutoConfig (adconfig.sh)

 

The au (Applications Utilities) directory

This directory and its subdirectories contain product files that are consolidated in one place for optimal processing. These files include:
  • PL/SQL libraries used by Oracle Forms, in the resource subdirectory
  • Oracle Forms source files, in the forms subdirectory
  • A copy of all Java files used when regenerating the desktop client JAR files, in the java subdirectory
  • Certain reports needed by products such as Discoverer, in the reports subdirectory
 

The fnd (Application Object Library) directory

This directory and its subdirectories contain the scripts and programs that are used as the foundation for all Oracle E-Business Suite products to build data dictionaries, forms and C object libraries.

 

 

Conclusions

 

In version 12i of E-Business Suite, there were several changes to version 11i and the inclusion of SOA architecture, already giving adherence to new integration technologies and process workflow.
 
In the next articles we will continue on understanding the structure of the E-Business Suite and guide best practices for installing the product efficiently.

 

 
References
 
Oracle E-Business Suite Release 12 Technology Stack Documentation Roadmap [ID 380482.1]

 

 

See you next time!

 

Andre Ontalba

 

Disclaimer: “The postings on this site are my own and don’t necessarily represent my actual employer positions, strategies or opinions. The information here was edited to be useful for general purpose, specific data and identifications were removed to allow reach the generic audience and to be useful for the community.”

 


Cleaning up JOB’s with erros in OEM 13c.
Category: Database Author: Andre Luiz Dutra Ontalba (Board Member) Date: 5 years ago Comments: 0

Cleaning up JOB's with OEM 13c errors

Today a simple but useful article, in OEM 13c we have the very useful job schedulling system.
 
However, as we can see in the image below when we have several errors, it is difficult to clean the jobs using the web interface or EMCLI.

 

EMCLI verb “get_jobs” reports all runs of the jobs, and “delete job” can delete job and its all runs but it’s not possible to delete a specific run of a job. For example, if you want to delete hundreds of “failed” (or “skipped”) runs of a job, EMCLI won’t help you and doing it through the web interface will be very time consuming.
 
We can easily solve this with a PL/SQL script to clean up jobs.

 

Connect to sqlplus with the sysman account:




[oracle@dbadutra:/home/oracle] sqlplus sysman@OEM13c




SQL*Plus: Release 19.0.0.0.0 – Production on Fri 28 08:15:03 2020

Version 19.3.0.0.0




Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 – Production

Version 19.3.0.0.0




SQL>

BEGIN
   FOR C IN
   (SELECT SCHEDULED_TIME, JOB_ID
   FROM MGMT$JOB_EXECUTION_HISTORY
    WHERE JOB_OWNER = ‘SYSMAN’
   AND JOB_ID IN (SELECT DISTINCT(JOB_ID) FROM MGMT$JOB_EXECUTION_HISTORY WHERE STATUS=’Error’ or STATUS=’Failed’)
   AND STATUS = ‘Error’ or STATUS=’Failed’)
   LOOP
         EM_JOB_OPS.DELETE_JOB_RUN(C.JOB_ID,C.SCHEDULED_TIME);
   END LOOP;
COMMIT;
END;

 

Now let’s get there and the jobs are clean

 

 

I hope I helped with this tip

 

André Ontalba

 

Disclaimer“The postings on this site are my own and don’t necessarily represent my actual employer positions, strategies or opinions. The information here was edited to be useful for general purpose, specific data and identifications were removed to allow reach the generic audience and to be useful for the community.”

 


Using the feature recover standby database from service Dataguard on 19c
Category: Database Author: Andre Luiz Dutra Ontalba (Board Member) Date: 5 years ago Comments: 0

Using the feature recover standby database from service Dataguard on 19c

The Oracle Dataguard, part from MAA (Max Availability Architecture), is a prouct vastly utilized all over the entire globe by several companies whom willing to keep their data safe, preventing lost of data in case of human erros, hardware failures and other kind of disasters. The main function of this product is provide a copy from your primary database, synchronized by archivelogs, usually maintained into a different geographical location, in most of cases. With the Active Dataguard introduction, on Oracle 11g, an option, licensed, leverage this product to another level, even better, in my humble opinion. This feature allows the users to run some reports on standby database with the state read only with apply, this can deviate a lot of heavy workloads from principal database and reducing a lot of resources on it.
With Oracle database 19c, Oracle introduced a feature that allows some DML done on standby database be redirected to the primary database and the shipped by archivelogs again to standby. Note, this is not recomended for usage with intense workloads, because of performance matters, use more, cpu, network and etc. Just mention this features for you follow up some improvements on the product on each version. Today we will talk about one more enhancement that make it easier DBA’s life time to time.
Sometimes, because of some hardware failures, human failures, bugs or even some reconfiguration, we need to recreate the standby database, and on Oracle 18c and onwards, Oracle has introduced a single RMAN command to performance the whole resynchronization from standby databases over network. I don’t need to tell you that is no suitable perform multi-terabyte database restoration over network, most of time (you can have a dedicated network to play with).
 
 
Benefits
 
  • Simplicity to create or recreate the standby database
  • Best control of the process
 
Scenario
 
  • Primary database: orclcdb
  • Standby database: orclstb
 
The primary database and also the standby are managed by Dataguard broker (DGMGRL), I like to use this command line utility to manage the Dataguard environments. It helps to perform all dataguard administration like switchover, configure and a lot more of tasks in a Dataguard environment, if you want to have more information about this incredible tool, please refer the official documentation on the link https://docs.oracle.com/en/database/oracle/oracle-database/19/dgbkr/index.html
 
 
Verification
 
As I mentioned before, using the command line interface from Dataguard Broker, we can use the command show configuration to display the configuration made by us, previously, in our case, on this Dataguard configuration we have the primary database orclcdb and also the standby database orclstb, we can have multiple standby databases and also ZDLRA registered on broker. We will cause some damage on standby database just to show how to solve it on this article, by removing a datafile, let’s say system01.dbf, just for fun.
              We can see on the imagem below, there are no problems there, like a gap or any other kind of issues, in this case, if we lose the primary database, the standby will be able to become the primary database with just a manual switchover. It is also possible to automate this task, by configuring Fast-Start Failover.

Causing some damage on standby

 

              On the follwoing image, we can verify all belonging datafiles from our standby database, where we will cause some damage and recover it just using recover standby database from service. The list below, shows all datafiles from our standby (orclstb)
Now, we will remove the main datafile on the standby, /u01/app/oracle/oradata/ORCLSTB/system01.dbf
As we expected, after remove, one of the datafiles on purpose, our environment crashed, look:

Disabling the apply on standby database

 

            Before to initiate with the recover process, from this standby database, we will neneed  stop the archivelog synchronization, to do that, we can use the commands below, to edit the state of the database within broker. If you don’t do that, we will face this error:

 

starting media recovery

media recovery failed

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of recover command at 01/19/2020 11:16:26

RMAN-03015: error occurred in stored script Memory Script

RMAN-11003: failure during parse/execution of SQL statement: alter database recover

 if needed standby start

ORA-01153: an incompatible media recovery is active


        As we can see, the command to stop apply on DGMGRL was issued, and now, no more error will happen.
            After stopping the recover, we just need to login on RMAN and issue the command recover standby database from service, as we can follow up on upcomming lines of this article:

 

[oracle@ora19c ~]$ rman target=sys/oracle@orclstb




Recovery Manager: Release 19.0.0.0.0 - Production on Sun Jan 19 11:27:59 2020

Version 19.3.0.0.0




Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.




connected to target database: ORCLCDB (DBID=2780785463, not open)




RMAN> recover standby database from service orclcdb;




Starting recover at 19-JAN-20

using target database control file instead of recovery catalog

Oracle instance started




Total System Global Area    1895823376 bytes




Fixed Size                     9136144 bytes

Variable Size                436207616 bytes

Database Buffers            1442840576 bytes

Redo Buffers                   7639040 bytes




contents of Memory Script:

{

   restore standby controlfile from service  'orclcdb';

   alter database mount standby database;

}

executing Memory Script




Starting restore at 19-JAN-20

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=39 device type=DISK




channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: using network backup set from service orclcdb

channel ORA_DISK_1: restoring control file

channel ORA_DISK_1: restore complete, elapsed time: 00:00:02

output file name=/u01/app/oracle/oradata/ORCLSTB/control01.ctl

output file name=/u01/app/oracle/fast_recovery_area/ORCLSTB/control02.ctl

Finished restore at 19-JAN-20




released channel: ORA_DISK_1

Statement processed




contents of Memory Script:

{

set newname for datafile  1 to

 "/u01/app/oracle/oradata/ORCLSTB/system01.dbf";

   restore from service  'orclcdb' datafile

    1;

   catalog datafilecopy  "/u01/app/oracle/oradata/ORCLSTB/system01.dbf";

   switch datafile all;

}

executing Memory Script




executing command: SET NEWNAME




Starting restore at 19-JAN-20

Starting implicit crosscheck backup at 19-JAN-20

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=49 device type=DISK

Crosschecked 3 objects

Finished implicit crosscheck backup at 19-JAN-20




Starting implicit crosscheck copy at 19-JAN-20

using channel ORA_DISK_1

Crosschecked 2 objects

Finished implicit crosscheck copy at 19-JAN-20




searching for all files in the recovery area

cataloging files...

cataloging done




List of Cataloged Files

=======================

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_25_gyq4g4hz_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_26_gyq5km3v_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_27_gyq64bom_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_28_gyq64n7f_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_29_gyq64zy8_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_30_gyq6vxg5_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_32_gyq6vzrv_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_31_gyq6vzs6_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_33_gyq84b59_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_34_gyq88dll_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_35_gyq9rvx9_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_36_gyqcf807_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_37_gyqcfsk1_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_38_gyqcg4l3_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_39_gyqckh4o_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_41_gyqckkfk_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_40_gyqckkg6_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_42_gyqcpsko_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_43_gyqdchj7_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_08/o1_mf_1_44_gyso1jwz_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_08/o1_mf_1_45_gytopnjo_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_08/o1_mf_1_46_gytowb7h_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2020_01_09/o1_mf_1_47_h1gstntb_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2020_01_09/o1_mf_1_48_h1gtcgd0_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2020_01_09/o1_mf_1_49_h1gv3wqn_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2020_01_09/o1_mf_1_50_h1gv8rbs_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2020_01_09/o1_mf_1_51_h1gvo2x8_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2020_01_16/o1_mf_1_52_h21lqfd2_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2020_01_16/o1_mf_1_53_h21m7fwt_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2020_01_19/o1_mf_1_54_h28w8y78_.arc

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/autobackup/2019_12_07/o1_mf_s_1026372241_gyq6h263_.bkp

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/autobackup/2019_12_07/o1_mf_s_1026373077_gyq7r09k_.bkp

File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/autobackup/2019_12_07/o1_mf_s_1026378166_gyqd9fxy_.bkp




using channel ORA_DISK_1




channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: using network backup set from service orclcdb

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00001 to /u01/app/oracle/oradata/ORCLSTB/system01.dbf

channel ORA_DISK_1: restore complete, elapsed time: 00:00:07

Finished restore at 19-JAN-20




cataloged datafile copy

datafile copy file name=/u01/app/oracle/oradata/ORCLSTB/system01.dbf RECID=5 STAMP=1030102136




datafile 1 switched to datafile copy

input datafile copy RECID=5 STAMP=1030102136 file name=/u01/app/oracle/oradata/ORCLSTB/system01.dbf




contents of Memory Script:

{

  recover database from service  'orclcdb';

}

executing Memory Script




Starting recover at 19-JAN-20

using channel ORA_DISK_1

skipping datafile 1; already restored to SCN 4595092

skipping datafile 3; already restored to SCN 4594570

skipping datafile 5; already restored to SCN 2163739

skipping datafile 6; already restored to SCN 2163739

skipping datafile 7; already restored to SCN 4594577

skipping datafile 8; already restored to SCN 2163739

skipping datafile 9; already restored to SCN 4594580

skipping datafile 10; already restored to SCN 4594582

skipping datafile 12; already restored to SCN 4594588

skipping datafile 13; already restored to SCN 4594593

skipping datafile 14; already restored to SCN 4594596

skipping datafile 15; already restored to SCN 4594598

skipping datafile 19; already restored to SCN 4594600

skipping datafile 20; already restored to SCN 4594604

skipping datafile 21; already restored to SCN 4594611




starting media recovery




media recovery complete, elapsed time: 00:00:00

Finished recover at 19-JAN-20

Finished recover at 19-JAN-20




RMAN>


 

      Thus, we are able to see,  with just one simple commad line on RMAN, how can be easy recover/rebuild my entire dataguard database and stay ready for the next disaster recover, we hope not face that, but problems happens. The final result, our standby database was restored and can be fully syncrhonized again with the production database.
 
So, via DGMGRL interface, we can enable the synchronization again as we can see on the image:
 
 
For validation purposes, we will issue a switchover to change the roles of our databases, making the primary database becoming the standby and standby becoming the primary:
 
Now, our database orclstb, originally standby database is the primary, and the database orclcdb was changed to physical standby role:
Alls are opened and ready to use, the instainswith db_unique_name = orclstb now is with PRIMARY ROLE.
Conclusion: Oracle is always inovating and make our lives easier. With every launched version, new features are added. We can agree on this, this funcionality saves a lot of work, but, be concerned that you restore is fully using network, if your database is huge, you may kill the performance of your entire network.

 

 

André Ontalba / Rodrigo Mufalani / Y V RaviKumar 

 

Disclaimer“The postings on this site are my own and don’t necessarily represent my actual employer positions, strategies or opinions. The information here was edited to be useful for general purpose, specific data and identifications were removed to allow reach the generic audience and to be useful for the community.”

 


Clone Autonomous Database
Category: Cloud Author: Andre Luiz Dutra Ontalba (Board Member) Date: 5 years ago Comments: 0

Clone Autonomous Database

This article describes how to clone an existing Autonomous Database using the Oracle Cloud Infrastructure Console.  You may wish to use the cloning feature to create a point-in-time copy of your Autonomous Database for purposes such as testing, development or analytics. If you need to clone only the database schema of your source database, the “metadata clone” option is a quick and easy way to accomplish this task.
 
 Log into Oracle Cloud and click the “Create an ATP database” link.
Fill in the information and select the options to create the ATP instance.
 
Choose a compartment: dbadutra(root)
Display name: DBCLONE
Database name: DBCLONE
Choose a workload type: Transaction Processing
Choose a deployment type: Shared Infrastructure
Configure the database:  In this case, as we use Always Free we can’t change the CPU and Storage size.
Create administrator credentials: OracleATP2020        
Choose a license type: In this case select License Included
 
After you have filled everything in, click  “Create Autonomous Database”
Wait a few minutes for ATP creation

 

 

Now select in menu “Autonomous Transaction Processing”

 

Click in “DBCLONE”
In the “Actions” menu click on “Create Clone”
Now let’s create a clone of our ATP, filling in the information below.
 
Clone Type:  In this option, we can choose a complete clone or just the structure without data. In this case we will select Full Clone.
Configure clone source: In this option we can choose a clone from the Database Instance or using a Backup to perform this clone and can perform a point in time recovery.
In this case, we will use the clone from the Database Instance.
Create In Compartment: dbadutra (root)
Display name: Clone of DBCLONE
Database name: DBCLONE2
Configure the database: In this case, as I use Always Free, we can’t change the CPU and Storage size.
Create administrator credentials: OracleATP2020        
Choose a license type: In this case select License Included
Now click on “Create Autonomous Database Clone”
 
 
Wait a few minutes for Clone ATP creation
Ready your clone is created and available for use.
To learn more on the Autonomous Database Clone Check here:

 

https://docs.cloud.oracle.com/en-us/iaas/Content/Database/Tasks/adbcloning.htm
 
We hope we helped you with this great new feature.

 

André Ontalba / Rodrigo Mufalani

 

Disclaimer: “The postings on this site are my own and don’t necessarily represent my actual employer positions, strategies or opinions. The information here was edited to be useful for general purpose, specific data and identifications were removed to allow reach the generic audience and to be useful for the community.”

 

 


LUXOUG – 2020
Category: Cloud Author: Andre Luiz Dutra Ontalba (Board Member) Date: 5 years ago Comments: 0

LUXOUG - 2020 - Update - COVID-19 !!​

We would like to express our sincerest apologies to you.
Face to the last events and news about the pandemic status of COVID-19, we were suggested by attendees and also by the sponsors to postpone our LuxOUG 2020 event.
The Luxembourg Oracle User Group is very sad with the current situation, but your health and welfare is important to us.
 
We will keep everyone informed when we have a new date for the event.
 
Sincerely
The LuxOUG – Board
 
 
 
 
 
First LUXOUG event for the Oracle community.
 
We will hold our first event in Luxembourg, covering various technologies such as DevOps, Engineered System, Middleware, Cloud and others.
 
Location: Luxembourg
Date: 28/3/2020
Event Schedule: 9:00 AM – 17:00 PM (CEST)
Address: 13 Rue de l’Industrie, 8399 Windhof – 4 floor.
 
See you at the event
 
Event Schedule:
 


Our Speakers

Erik van Roon – In 1995 Erik van Roon switched careers for medical reasons from Microbiology/Biochemistry to being an Oracle Developer. Since then he has worked for several consulting companies in the Netherlands. Since 2009 he is self-employed. His company is called EvROCS, short for Erik van Roon Oracle Consulting Services. He has worked on major projects for several clients in industries like entertainment, banking and energy, working with the ‘classic’ Oracle tools Designer, Forms, Reports, and of course SQL and PLSQL. He has been the technical lead of multiple successful high impact data-migration projects moving and transforming large amounts of data. In 2012 he started speaking at international conferences. He was nominated and selected to be a finalist in the SQL category of OTN Developers Choice Awards in 2015.
site: https://www.evrocs.nl/?lang=en
twitter: https://twitter.com/evrocs_nl
linkein: https://www.linkedin.com/in/erikvanroon/
 
Kamran Agayev – Kamran Agayev Agamehdi is an Oracle Certified Professional DBA (9i, 10g) with over 7 years experience with UNIX Systems and with Oracle Databases. During his 7 years working in the IT industry, Kamran has been exposed to a wide range of technologies and developed a broad set of technical skills. He have developed a very strong background in Oracle Databases, UNIX and Windows systems. Kamran has worked in Production environments as an Oracle DBA and in Development environments as Oracle DBA/Developer, and adapt well to both. His background, communication and documentation skills help in bridging the gap between business people, database administrators and UNIX system administrators. He’s an author of the book – “Oracle Backup & Recovery: Expert secrets for using RMAN and Data Pump”. He’s also pursuing a PhD in Azerbaijan Oil Academy in Computer Science, teaching “Oracle Database Administration” and presents seminars in a Qafqaz University. At the same time, he’s an active member of OTN Forums and has published a lot of “Step by Step” articles and Oracle Video tutorials on his blog http://kamranagayev.wordpress.com covering main Oracle features. Currently he’s working as a DBA Expert at “Azercell Telecom”
site: http://kamranagayev.wordpress.com/
twitter: https://www.twitter.com/KamranAgayev
linkein: https://www.linkedin.com/in/KamranAgayev
 
Toon Koppelars – Toon has been part of the Oracle ecosystem since 1987, he is part of Oracle Real World Performance team. He is currently a member of Oracle’s Real-World Performance team. The RWP team troubleshoots application performance issues in and around the DBMS. The way applications currently use (or rather, abuse) the DBMS, is often at the root of these performance issues. Prior to joining the RWP team, Toon has been mainly involved in database application development. Real-World Performance @oracle – database designer – SQL+PL/SQL – OakTable – author Applied Math for DB Pro’s – SQL Assertions – #SmartDB – Opinions my own
site: www.oracle.com
twitter: https://twitter.com/toonkoppelaars
linkein: N/A
Bruno Reis – Bruno Reis da Silva is an Oracle Senior Cloud Database Administrator Consultant and professionally Certified Oracle Database Administrator who has worked on the South American continent and is now working on the European continent. His interests are in RDBMS, mainly Oracle, operating systems (Linux, AIX, HPUX and Solaris) and High Availability Solutions implementations. In his free time he enjoys playing sports , going to the gym and traveling. His blog is dedicated to his sister Laura Vitoria and the main reason for blogging is because he believes in the quote “giving back to get back” . He also enjoys continuous learning and the interaction with others who share his interest.
site: http://www.techdatabasket.com/
twitter: https://twitter.com/brunorsdba
linkein: https://br.linkedin.com/in/bruno-reis-81498191
 
Piet de Visser – Piet is an experienced Database Consultant and DBA. He has been in IT since 1987, and specializes in Oracle and Database-related technology since 1994. Piet combines technical database knowledge with extensive experience in global organizations. His energetic personality and language-skills makes him ideal for pioneering and ground-breaking projects in a multi-national environment. Piet also invests a lot of effort in maintaining a network of Like-Minded Oracle specialists worldwide and is a regular speaker at international usergroup events and symposia. Piet likes to travel, speaks various languages more or less fluently, and is alway interested in learning how to say “Hello” and “Thank You” in a few more languages, provided he can learn it in-situ. Piet specializes in Oracle databases and High-Availability, deployment and performance. His philosophy is that Simple systems are easier to maintain and to run and therefore offer better Availability.
site: http://pdvfirstblog.blogspot.com/
twitter: https://twitter.com/pdevisser
linkein: https://nl.linkedin.com/in/pietdevisser
 
Robert Marz – Robert Marz is a member of its-people GmbH, a Germany based professional services company. At customer sites, he works as a Senior Technical Architect with a database-centric view of the world. Robert is Portfolio Manager Database Technologies at its-people. At DOAG (the German Oracle user group), he is in charge of the Cloud topics inside the database community. Robert is a member of ODTUG, IOUG and RMOUG. More than twenty years of experience in custom development and data warehouse projects makes him a specialist in Oracle database development and administration. Additionally, he is skilled in the fields of scripting languages, operating systems, virtualization and cloud technologies. Robert Marz publishes articles and papers in various publications, maintains the its-people portfolio blog and speaks frequently at mostly German conferences.
Personal Interests
Robert is a passionate amateur photographer. His main models are his wife and his little daughter. He loves to travel with his family. Vacations always include extended hiking. Robert has a well-equipped home cinema and owns more than two thousand movies on BluRay and DVD. Prior to his daughter’s birth, he went to the cinema with his wife more than sixty times a year. He is famous for identifying movies walking by a TV after watching only a couple of seconds.
site: https://robbie.databee.org/
twitter: https://twitter.com/RobbieDatabee
linkein: https://www.linkedin.com/in/robbieddatabee
 
Nikitas Xenakis – Nikitas is a Platform Specialist-Architect with over 17 years of experience in architecture, design and implementation of enterprise-scale, business-critical solutions, underpinned by Oracle Database and Middleware technologies in a 24x7x365 real-time, multi-platform, multi-site/cloud landscape. Active member in Global Leaders for TP and CAB programs, frequent speaker, presenter at OOW, UKOUG, DOAG.
site: http://nikitasxenakis.wordpress.com/
twitter: https://www.twitter.com/Nikitas_Xenakis
linkein: https://www.linkedin.com/in/nikitasxenakis
 
 

Sponsor


Converting Dictionary Managed Tablespaces (DMT) to Local Managed Tablespaces (LMT)
Category: Database Author: Andre Luiz Dutra Ontalba (Board Member) Date: 5 years ago Comments: 0

Converting Dictionary Managed Tablespaces (DMT) to Local Managed Tablespaces (LMT)

 
Today we found some really old database using really old fashion tablespaces allocation. In another life, when I began with Oracle database and we use to call MOSC as Metalink (@ludodba) there was a way to manage the extents on database called DICTIONARY MANAGED TABLESPACES (DMT), most because of performance issues, Oracle has decided to change this management of the extents instead to resides on data dictionary (SYSTEM tbs), to be stored on bitmaps on local tablespace, that’s why they called it LOCAL MANAGED TABLESPACE (LMT). This feature was introduced on Oracle 9i in 2001, almost 20 years ago and we still see old stuff running around.
The steps that we will perform are very fast and simple, but as we are changing some core things on the database, please, make sure to have full and confiable backup before.
Here is an important note, a little bit confusing, please read it before to proceed. Resuming, after convert SYSTEM, you cannot put DMT in read write mode anymore.
********* IMPORTANT NOTE **********
Note:After the SYSTEM tablespace is migrated to locally managed, any dictionary-managed tablespaces in the database cannot be made read/write.
If you want to use the dictionary-managed tablespaces in read/write mode, then Oracle recommends
that you first migrate these tablespaces to locally managed before migrating the SYSTEM tablespace.
***********************************
1) Put DATABASE in restricted session
SQL> ALTER SYSTEM ENABLE RESTRICTED SESSION;

System altered.

SELECT logins FROM v$instance;

LOGINS
---------
RESTRICTED
2) Define a default temporary tablespace on the database
SQL> col PROPERTY_NAME form a30
SQL> col PROPERTY_VALUE form a30
SQL> col DESCRIPTION form a50
SQL> select * from database_properties where PROPERTY_NAME = 'DEFAULT_TEMP_TABLESPACE';

PROPERTY_NAME PROPERTY_VALUE DESCRIPTION
------------------------------ ------------------------------ --------------------------------------------------
DEFAULT_TEMP_TABLESPACE SYSTEM ID of default temporary tablespace
 
Obs.: Really bad, using system tablespace to store temporary segments, some DBA here didn’t made his homework… In fact his work.
SQL> ALTER DATABASE DEFAULT TEMPORARY TABLESPACE TEMPTBS01;

Database altered.
Obs.: Check if temp is dictionary managed, if so, recreate it before to proceed with the others.
SQL> select * from database_properties where PROPERTY_NAME = 'DEFAULT_TEMP_TABLESPACE';

PROPERTY_NAME PROPERTY_VALUE DESCRIPTION
------------------------------ ------------------------------ --------------------------------------------------
DEFAULT_TEMP_TABLESPACE TEMPTBS01 ID of default temporary tablespace

 

3) Migrate all other DICTIONARY MANAGED TBS before MIGRATE system
select tablespace_name, status, extent_management 
from dba_tablespaces
where extent_management = 'DICTIONARY';
4) Execute the migration
select 'execute DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('''||tablespace_name||''');' cmd 
from dba_tablespaces where extent_management = 'DICTIONARY'
and tablespace_name <> 'SYSTEM';

CMD
----------------------------------------------------------------------------------------
execute DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('INDX');
execute DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('TOOLS');
execute DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('TESTTBS1');
execute DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('TESTTBS2');
execute DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('USERS');

SQL> execute DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('INDX');

PL/SQL procedure successfully completed.

SQL> execute DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('TOOLS');

PL/SQL procedure successfully completed.

SQL> execute DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('TESTTBS1');

PL/SQL procedure successfully completed.

SQL> execute DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('TESTTBS2');

PL/SQL procedure successfully completed.

SQL> execute DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('USERS');

PL/SQL procedure successfully completed.
5) Make sure that all tablespaces, other than SYSTEM were migrated to LMT, after execute the migration of SYSTEM to LMT, if you left any dictionary managed tablespaces (DMT), you cannot put them read write anymore.
select tablespace_name, status, extent_management 
from dba_tablespaces
where extent_management = 'DICTIONARY'
and tablespace_name <> 'SYSTEM';

no rows selected
6) Put all tablespaces other than UNDO, TEMP AND SYSAUX in readonly mode.
select 'ALTER TABLESPACE '||tablespace_name||' READ ONLY;' CMD
from dba_tablespaces
where tablespace_name NOT in ('SYSTEM','SYSAUX')
and contents not in ('UNDO','TEMPORARY');

CMD
----------------------------------------------------------
ALTER TABLESPACE INDX READ ONLY;
ALTER TABLESPACE TOOLS READ ONLY;
ALTER TABLESPACE TESTTBS1 READ ONLY;
ALTER TABLESPACE TESTTBS2 READ ONLY;
ALTER TABLESPACE USERS READ ONLY;
7) Check the status of the tablespaces
SQL> select tablespace_name, status from dba_tablespaces;

TABLESPACE_NAME STATUS
------------------------------ ---------
SYSTEM ONLINE
INDX READ ONLY
TOOLS READ ONLY
TESTTBS1 READ ONLY
TESTTBS2 READ ONLY
USERS READ ONLY
UNDOTBS01 ONLINE
TEMPTBS01 ONLINE
SYSAUX ONLINE
8) Put SYSAUX tablespace offline
SQL> alter tablespace SYSAUX offline;

Tablespace altered.
9) Check the status of tablespaces again, just UNDO, TEMP and SYSTEM must be online.
SQL> select tablespace_name, status from dba_tablespaces;

TABLESPACE_NAME STATUS
------------------------------ ---------
SYSTEM ONLINE
INDX READ ONLY
TOOLS READ ONLY
TESTTBS1 READ ONLY
TESTTBS2 READ ONLY
USERS READ ONLY
UNDOTBS01 ONLINE
TEMPTBS01 ONLINE
SYSAUX OFFLINE
10) Now we can migrate SYSTEM tablespaces
SQL> execute DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('SYSTEM');

PL/SQL procedure successfully completed.
11) Put the tablespaces again read write and online
select 'ALTER TABLESPACE '||tablespace_name||' READ WRITE;' CMD
from dba_tablespaces
where tablespace_name NOT in ('SYSTEM','SYSAUX')
and contents not in ('UNDO','TEMPORARY');

CMD
-----------------------------------------------------------
ALTER TABLESPACE INDX READ WRITE;
ALTER TABLESPACE TOOLS READ WRITE;
ALTER TABLESPACE USR READ WRITE;
ALTER TABLESPACE TESTTBS2 READ WRITE;
ALTER TABLESPACE USERS READ WRITE;

SQL> ALTER TABLESPACE INDX READ WRITE;

Tablespace altered.

SQL> ALTER TABLESPACE TOOLS READ WRITE;

Tablespace altered.

SQL> ALTER TABLESPACE USR READ WRITE;

Tablespace altered.

SQL> ALTER TABLESPACE TESTTBS2 READ WRITE;

Tablespace altered.

SQL> ALTER TABLESPACE USERS READ WRITE;

Tablespace altered.

12) Put SYSAUX online again
SQL> ALTER TABLESPACE SYSAUX ONLINE;

Tablespace altered.
13) Check the status of the tablespaces one more time
SQL> select tablespace_name, status, extent_management from dba_tablespaces;

TABLESPACE_NAME STATUS EXTENT_MAN
------------------------------ --------- ----------
SYSTEM ONLINE LOCAL
INDX ONLINE LOCAL
TOOLS ONLINE LOCAL
TESTTBS1 ONLINE LOCAL
TESTTBS2 ONLINE LOCAL
USERS ONLINE LOCAL
UNDOTBS01 ONLINE LOCAL
TEMPTBS01 ONLINE LOCAL
SYSAUX ONLINE LOCAL
14) Disable restricted session on the database
SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION;

System altered.

SELECT logins FROM v$instance;

LOGINS
---------
ALLOWED
If you don’t follow all steps carefully you can reach some issues like these below
 
SQL> execute DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('SYSTEM');

ERROR at line 1:
ORA-10644: SYSTEM tablespace cannot be default temporary tablespace
ORA-06512: at "SYS.DBMS_SPACE_ADMIN", line 227
ORA-06512: at line 1

SQL> execute DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('SYSTEM');

ERROR at line 1:
ORA-10647: Tablespace other than SYSTEM, UNDO, TEMP not
found in read only mode
ORA-06512: at "SYS.DBMS_SPACE_ADMIN", line 227
ORA-06512: at line 1

SQL> select tablespace_name from dba_tablespaces;

TABLESPACE_NAME
------------------------------
SYSTEM
TEMP
USERS
IDX
SYSAUX
UNDO

SQL> alter tablespace USERS read only;
SQL> alter tablespace IDX read only;

SQL> execute DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('SYSTEM');

ERROR at line 1:
ORA-10648: Tablespace SYSAUX is not offline
ORA-06512: at "SYS.DBMS_SPACE_ADMIN", line 227
ORA-06512: at line 1
 
I hope this helps you!!!
Rodrigo Mufalani and Andre Luiz Dutra Ontalba

Disclaimer: “The postings on this site are my own and don’t necessarily represent may actual employer positions, strategies or opinions. The information here was edited  to be useful for general purpose, specific data and identifications was removed to allow reach generic audience and to be useful.”


1 2 3 4 5 6 8