Doyensys Allappsdba Blog..

Maintenance Mode was introduced in Release 11.5.10, in which users are not allowing to login any responsibility.

In Maintenance mode the Oracle Applications system is made accessible only for patching activities.

Why we need to enable Maintenance Mode and their Advantages:

As we know that there are several practical points relating to the use of Maintenance Mode:

We can toggle Maintenance Mode between Enabled and Disabled using the new Change Maintenance Mode menu in AD Administration (Adadmin), or the equivalent function in Oracle Applications Manager.

Although we can run AutoPatch (Adpatch) without enabling Maintenance Mode but noted there will be a significant degradation in performance.

As we know that while the application is in Maintenance Mode there is a separate login page for Restricted Mode access.

Here, restricted Mode allows administrators access to specific privileged functionality in OAM, for example to view the timing report that shows the progress of a patching session.

In Restricted Mode, only valid database users are allowed to login into OAM via a special URL and are allowed to access a limited set of features.

The database role AD_MONITOR_ROLE has access to all the required database objects for Restricted Mode features.

Or the OAM Online Help (OAM->Patches and Utilities -> Managing Downtime Schedules -> Restricted Mode)

Conclusion:

1. To ensure optimal performance and reduce downtime during patching sessions.

2. Maintenance Mode shutdown the Workflow Business Events System (oracle application services).

3. Setup a function security so that Oracle Applications functions are unavailable to users.

4. Provide a clear visibility/information to user that System/Application is down for patching purpose.

Easy/short-cut steps to Enabling and Disabling Maintenance Mode:

This is also same as ADADMIN because when we Enable or Disable 'Maintenance Mode', adadmin will also execute the below script:

$AD_TOP/patch/115/sql/adsetmmd.sql ####sending the parameter 'ENABLE' or 'DISABLE' as shown below as example:

SQL>@$AD_TOP/patch/115/sql/adsetmmd.sql ENABLE ##### For ENABLE

SQL>@$AD_TOP/patch/115/sql/adsetmmd.sql DISABLE ##### For DISABLE

Real-time scenario:

SQL> show user

USER is "APPS"

SQL>

SQL> select fnd_profile.value('APPS_MAINTENANCE_MODE') from dual;

FND_PROFILE.VALUE('APPS_MAINTENANCE_MODE')

--------------------------------------------------------------------------------

MAINT

SQL>

SQL> @$AD_TOP/patch/115/sql/adsetmmd.sql DISABLE

PL/SQL procedure successfully completed.

Commit complete.

Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

With the Partitioning, Automatic Storage Management, OLAP, Data Mining

and Real Application Testing options

SQL> select fnd_profile.value('APPS_MAINTENANCE_MODE') from dual;

FND_PROFILE.VALUE('APPS_MAINTENANCE_MODE')

--------------------------------------------------------------------------------

NORMAL

SQL>

If MAINT ==> Maintenance Mode is Enabled.

If NORMAL ==> Maintenance Mode is Disabled.

Fix a block crorruption issue for LOB indexes in a tablespace which we want to drop.

Here are some views to find LOB objects and LOB indexes:

-- To find LOB objects from a tablespace:
e.g.,
SELECT SEGMENT_NAME, SEGMENT_TYPE, OWNER, TABLESPACE_NAME
FROM DBA_SEGMENTS
WHERE TABLESPACE_NAME = 'PAYROLL'
   AND SEGMENT_TYPE LIKE 'LOB%'
ORDER BY 1;

Sample out:

SEGMENT_NAME SEGMENT_TYPE       OWNER TABLESPACE_NAME
------------------------------ ------------------ ---------- -------
SYS_IL0000077613C00006$$       LOBINDEX           PAYROLL    PAYROLL
SYS_IL0000077671C00006$$       LOBINDEX           PAYROLL    PAYROLL
SYS_IL0000078212C00001$$       LOBINDEX           PAYROLL    PAYROLL
SYS_IL0000078458C00006$$       LOBINDEX           PAYROLL    PAYROLL
SYS_LOB0000077613C00006$$      LOBSEGMENT         PAYROLL    PAYROLL
SYS_LOB0000077671C00006$$      LOBSEGMENT         PAYROLL    PAYROLL
SYS_LOB0000078212C00001$$      LOBSEGMENT         PAYROLL    PAYROLL
SYS_LOB0000078458C00006$$      LOBSEGMENT         PAYROLL    PAYROLL

8 rows selected

Note: Segments prefixed with 'SYS_IL....' is log index and segements prefixed with 'SYS_LOB.....' is table.

-- To find Table Name for Log segment
e.g.,
SQL> select owner,table_name,column_name,tablespace_name
2 from dba_lobs
3 where segment_name='SYS_LOB0000077613C00006$$';

OWNER      TABLE_NAME                     COLUMN_NAME        TABLESPACE_NAME
---------- ------------------------------ ----------------------------------
PAYROLL    PAY_LOAN                       INSTALLMENT        PAYROLL
SQL>

-- To find Table name for LB Index:
e.g.,
SQL> select owner, table_name, column_name, segment_name, index_name
from dba_lobs
where index_name = 'SYS_IL0000077613C00006$$';

OWNER      TABLE_NAME COLUMN_NAME     SEGMENT_NAME INDEX_NAME
---------- ---------- --------------- -------------------------
PAYROLL    PAY_LOAN   INSTALLMENT     SYS_LOB0000077613C00006$$      SYS_IL0000077613C00006$$
SQL>

A LOB is made up of a LOB data segment storing LOB data and a LOB index segment used to access LOB data. SYS_LOBxxx is the LOB data segment and SYS_ILxxx is the LOB index segment. As a consequence it is meaningless to try to drop only the LOB index segment (and I don't think it is possible to do so): you can only drop the LOB column to drop data and index segment or maybe try to move the column to be stored in row only if LOB size allows.

How to move lobsegment and lobindex to a different Tablespace?

when I am executing the following statement in order to move the LOBINDEX, I am getting the errors listed below:

SQL> ALTER INDEX SYS_IL0000265968C00002$$ REBUILD TABLESPACE TEST;
ALTER INDEX SYS_IL0000265968C00002$$ REBUILD TABLESPACE TEST
*
ERROR at line 1:
ORA-02327: cannot create index on expression with datatype LOB

Workaround:

-- create a table in USERS tablespace

CREATE TABLE TEST_TBL
(
TEST_ID NUMBER NOT NULL,
TEST_NAME CLOB,
CONSTRAINT PK_TEST PRIMARY KEY(TEST_ID)
) tablespace USERS;

-- see the tables's tablespace name

SQL> col owner format a5;
SQL> column segment_name format a10;
SQL> col segment_type format a10;
SQL> col tablespace_name format a10;
SQL> select owner,segment_name,segment_type,tablespace_name
2   from dba_segments where segment_name='TEST_TBL';

OWNER SEGMENT_NA SEGMENT_TY TABLESPACE
----- ---------- ---------- ----------
SYS   TEST_TBL   TABLE      USERS

SQL>

-- See the LOB index

SQL> SELECT index_name, tablespace_name
2 FROM user_indexes WHERE table_name = 'TEST_TBL';

INDEX_NAME                     TABLESPACE
------------------------------ ----------
SYS_IL0000265968C00002$$       USERS
PK_TEST                        USERS

SQL>

-- Move table to different tablespace;

SQL> ALTER TABLE TEST_TBL MOVE TABLESPACE TEST;

Table altered.

SQL> select owner,segment_name,segment_type,tablespace_name
2 from dba_segments where segment_name='TEST_TBL';

OWNER SEGMENT_NA SEGMENT_TY TABLESPACE
----- ---------- ---------- ----------
SYS   TEST_TBL   TABLE      TEST

SQL>

SELECT index_name, tablespace_name FROM user_indexes WHERE table_name = 'TEST_TBL';

INDEX_NAME                     TABLESPACE
------------------------------ ----------
SYS_IL0000265968C00002$$       USERS
PK_TEST                        USERS

SQL>

See the above results, table is moved from 'USERS' tablespace to 'TEST' tablespace but index remain in same USERS tablespace. This is because LOB data is stored outside of the table.

The below example, TEST_NAME is the CLOB column which we want to move to new tablespace and EXAMPLE is target tablespace. Above command will successfully move LOB segments to the new tablespace. We can verify it by issuing same sql again.

SQL> ALTER TABLE TEST_TBL MOVE LOB(TEST_NAME) STORE AS (TABLESPACE TEST);

Table altered.

SQL> SELECT index_name, tablespace_name FROM user_indexes WHERE table_name = 'TEST_TBL';

INDEX_NAME                     TABLESPACE
------------------------------ ----------
PK_TEST                        USERS
SYS_IL0000265968C00002$$       TEST

Note : "small" LOBs stored inline (ie in the row itself) are not in a seperate LOBSEGMENT at all. That is called STORAGE IN ROW and is the default for LOBs of 4000bytes or less.

Fusion Middleware - BSU patch manually apply & rollback steps

HTTP Status 500 - Internal Server Error in glassfish

Seed Data Table has not been prepared for patching at "APPS.WF_EVENTS+"

Adop Prepare Fails With Error 'ORA-06512: at "APPS.FND_PRINTER_TL+", line 1'

Concurrent Managers : Overview & Concepts Oracle EBS R12

Oracle Apps R12.1 Vs R12.2

Maintenance Mode in R12.1.3

Maintenance Mode in R12.1.3

AD Utilities for Oracle Apps DBA

AD Utilities for Oracle Apps DBA

Article 2

Relink Of Module "Fndfmxit.So" Failed. The file is in use and cannot be overwritten

Article 1

ORA-00600 [ktte_recover_latch]

Article 0

ORA-15036 After Applying Patch 12382627

Query to Check Information about Database Structure

Query to Check Archivelog Generation by Daywise

Query to Monitor Redo Log Generation

Script to Display a table more than five MB in Particular Schema

ORA-01940: cannot drop a user that is currently connected

ORA-19815: WARNING: db_recovery_file_dest_size of xxxxxx bytes is 100.00% used

We can do that with RMAN using two commands, Crosscheck and Delete.

v$rman_configuration - no rows selected

Error: ORA-16810: multiple errors or warnings detected for the database - Fix

Move LOB objects and LOB indexes to different Tablespace