Migrate Dictionary managed Tablespaces to locally managed

Locally Managed Tablespaces

A tablespace that can manage extent allocation by itself is called locally managed tablespace. These tablespaces maintain a bitmap in each datafile to keep track of the freed or used status of blocks in that datafile. Each bit in the bitmap corresponds to a block or a group of blocks. When an extent is allocated or freed for reuse, Oracle changes the bitmap values to show the new status of the blocks. These changes do not generate rollback information because they do not update tables in the data dictionary (except for special cases such as tablespace quota information).
The storage parameters NEXT, PCTINCREASE, MINEXTENTS, MAXEXTENTS, and DEFAULT STORAGE are not valid for extents that are managed locally !
Extent Allocation
Locally managed tablespaces can have uniform extent sizes or variable extent sizes that are determined by the system. Any of the options, UNIFORM or AUTOALLOCATE can be mentioned while creating the tablespace. For UNIFORM extents you can specify an extent size. The default size is 1MB. For AUTOALLOCATE extents you can specify the size of the initial extent and Oracle determines the optimal size of the additional extents, with a minimum extent size of 64KB. That is why these are called system-managed extents.
How Extents are Allocated
Oracle looks for free space to allocate to a new extent by first determining a candidate datafile in the tablespace and then searching the datafile's bitmap for the required number of adjacent free blocks. If that datafile does not have enough adjacent free space, Oracle looks in another datafile. When extents are deallocated, Oracle modifies the bitmap in the datafile.
Create A Locally Managed Tablespace
CREATE TABLESPACE users
  DATAFILE 'users.dbf'
  EXTENT MANAGEMENT LOCAL
  UNIFORM SIZE 256K;
Advantages
  1. Local management of extents avoids recursive space management operations, which can occur in dictionary managed tablespaces.
     
  2. Local management of extents automatically tracks adjacent free space, eliminating the need to coalesce free extents.
     
  3. Reliance on data dictionary is reduced.
Notes
  1. Temporary tablespaces that manage their extents locally can only use UNIFORM extent allocation.
     
  2. For permanent tablespaces the default extent size for system managed extents is 64KB.
     
  3. The storage parameters NEXT, PCTINCREASE, MINEXTENTS, MAXEXTENTS, and DEFAULT STORAGE are not valid for locally managed tablespaces.

Change normal tablespaces to locally managed

Check extent management of the tablespaces with following command:
SQL> SELECT tablespace_name,extent_management
       FROM dba_tablespaces;
TABLESPACE_NAME                EXTENT_MAN
------------------------------ ----------
SYSTEM                         DICTIONARY
TEMP                           LOCAL
USERS                          DICTIONARY
TAB                            DICTIONARY
IDX                            DICTIONARY
SYSAUX                         LOCAL
UNDO                           LOCAL

First change first all dictionary managed tablespaces except tablespace SYSTEM to locally managed with the following procedure:

SQL> execute DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('USERS'); PL/SQL procedure successfully completed.

The tablespace must be kept online and read/write during migration. Note that temporary tablespaces cannot be migrated.

Change SYSTEM tablespaces to locally managed

Before the SYSTEM tablespace can be migrated to locally managed format, you should ensure the following:
  • The database has a default temporary tablespace which is not SYSTEM
  • There are not any rollback segments in dictionary managed tablespaces
  • There is at least one online rollback segment in a locally managed tablespace, or an undo tablespace (if using automatic undo management mode) should be online.
  • All tablespaces other than the tablespace containing the undo space (undo tablespace or the tablespace containing the rollback segment) and the default temporary tablespace are in read-only mode.
  • There is a complete backup of the system.
  • The system is in restricted mode.
Notr, that we already have an UNDO Tablespace. The following query determines whether the SYSTEM tablespace is locally managed:
SQL> SELECT ts# FROM ts$ WHERE ts# = 0 AND bitmapped <> 0;
If 0 rows are returned, then the SYSTEM tablespace is dictionary managed. Otherwise, the SYSTEM tablespace is locally managed.
Steps to change SYSTEM tablespaces to locally managed
SQL> shutdown immediate SQL> startup restrict
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> ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp;
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
TAB
IDX
SYSAUX
UNDO
SQL> alter tablespace USERS read only;
SQL> alter tablespace TAB 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
SQL> alter tablespace SYSAUX offline;
SQL> execute DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('SYSTEM');
PL/SQL procedure successfully completed.

Maintenance Mode

Maintenance Mode - A New Feature in 11.5.10


Maintenance Mode is a new mode of operation introduced with Release 11.5.10, in which the
Oracle Applications system is made accessible only for patching activities not allowing the users
to login to any responsibility. This provides optimal performance for AutoPatch sessions, and
minimizes downtime needed.

1. Scheduling System Downtime

Administrators can schedule 'System Downtime' using Oracle Applications Manager (OAM):
Site Map --> Maintenance --> Manage Downtime Schedules
When the System has been scheduled for 'Downtime', Apache should be re-started on Restricted Mode
by using the Script (adaprstctl.sh).  By doing this, users attempting to log on to Oracle Applications will
be automatically redirected to a System Downtime URL showing a message similar to the following one:

Scheduled Downtime Details

Start Time       : 17:30:00 12/11/2012
Expected Up Time : 09:00:00 12/12/2012
For Updates      : sonujha86@gmail.com

The system is currently undergoing a scheduled maintenance.
<Current Status>
This message can be customized with any text message.  If No Downtime has been specified, and the users
try to access the Applications, the following message might also appear:
! Warning
The system has not been taken off maintenance mode completely.
Please contact your System Administrator.

2. Advantages
There are several practical points relating to the use of Maintenance Mode:
  • You can toggle Maintenance Mode between Enabled and Disabled using the new Change Maintenance
           Mode menu in AD Administration, or the equivalent function in Oracle Applications Manager.
  • Although you can run AutoPatch with Maintenance Mode disabled, there will be a significant
          degradation in performance.
  • There is a separate logon page for Restricted Mode access while the system is in Maintenance Mode.
For more Information on Restricted Mode Access

3. Enabling and Disabling Maintenance Mode
Maintenance mode is Enabled or Disabled from adadmin.
When you Enable or Disable 'Maintenance Mode', adadmin will execute the script:
$AD_TOP/patch/115/sql/adsetmmd.sql sending the parameter 'ENABLE' or 'DISABLE' :
sqlplus <APPS_Schema name>/<APPS Password>@adsetmmd.sql ENABLE | DISABLE
    ENABLE  -   Enable Maintenance Mode .
    DISABLE -   Disable Maintenance Mode.
When adsetmmd.sql runs, it sets the Profile Option 'Applications Maintenance Mode'
(APPS_MAINTENANCE_MODE) to 'MAINT' to Enable 'Maintenance Mode' and to 'NORMAL' to Disable it.

4.  Determining if Maintenance Mode is Running

A quick way to verify if the Environment is on Maintenance Mode or not, is by checking the value of this Profile Option as follows:
sqlplus apps/apps

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

If the query returns 'MAINT', then Maintenance Mode has been Enabled and the Users will not be able to
Login.  If the query returns 'NORMAL' then Maintenance Mode has been De-Activated and the Users will be
able to use the application.
Note:  Maintenance Mode is only needed for AutoPatch Sessions. Other AD utilities do not require
Maintenance Mode to be enabled. Maintenance Mode must be 'Enabled' before running AutoPatch
and 'Disabled' after the patch application was completed.
When Maintenance Mode is disabled, you can still run Autopatch by using options=hotpatch on the
command line, if necessary.  However, doing so can cause a significant degradation of performance.

5. Error Messages
Always remember to Disable Maintenance Mode after any Patch application. If Maintenance Mode is not
Disabled, the Application will not allow the users to use the system.  Take note that Apache must be
re-started in
 normal mode after disabling 'Maintenance Mode' by using the Script adapcctl.sh (or adstrtal.sh)

As explained before, when 'Maintenance Mode' is enabled, a Downtime should be Scheduled from OAM and Apache should be started on Restricted Mode by using the Script (adaprstctl.sh).

If a 'DownTime' is not Scheduled from OAM and Apache has not been re-started on Restricted Mode,
the Application will allow the users to Login, but it might experience unusual behaviors afterwards
depending on the Patch Level.

Here are some examples of the possible error messages:
  • When clicking on a Responsibility from the PHP
There are no applications available for this responsibility.  Please click on a different responsibility
link to display the list of available applications.
or
You are not authorized to access the function Applications Home Page.  Please contact your System
Administrator.
  • When trying to access to the Application via CGI directly (not supported):
There are no valid navigations for this responsibility
Cause: The menu compilation has failed.
Cause: There is not valid menu defined for this responsibility.
Cause: There are no navigable forms associated with this responsibility.
Action: Contact your system administrator. Ensure that a valid menu,
containing navigable forms, is defined for the responsibility.
Ensure that the menu is correctly compiled.
Note:  In some cases, the behavior is slightly different.  Instead of showing the above messages, the
Application might not show any Responsibilities listed for the user at all.

6. Step by Step Process

1.  Schedule the 'System Downtime' from OAM
OAM: Site Map --> Maintenance --> Manage Downtime Schedules

At the moment of the downtime, do the following: 

2.  Shutdown Apache (on Normal Mode):
   adapcctl.sh stop
   or
   adstpall.sh <apps_user>/<apps_pwd>

3.  Enable 'Maintenance Mode' from adadmin
   adadmin: Options 5, 1

4. Start Apache (on Restricted Mode)
   adaprstctl.sh start

5. Apply the Patch with adpatch

6.  Stop Apache (on Restricted Mode)
  adaprstctl.sh stop

7.  Disable 'Maintenance Mode' from adadmin
   adadmin: Options 5, 2

8.  Start Apache (on Normal Mode):
  adapcctl.sh start
  or
  adstrtal.sh <apps_user>/<apps_pwd>

Why enable MAINTENANCE mode ??


To ensure optimal performance and reduce downtime during patching sessions, Auto-Patch requires that you enable Maintenance mode when you apply a patch. Enabling this feature shuts down the Workflow Business Events System and sets up function security so that Oracle Applications functions are unavailable to users. This provides a clear separation between normal run time operation and system downtime for patching.



               OR


Enabling Maintenance  mode will do these things briefly:-

1) As source code is modifying due to the patch, triggers,workflows events will be disabled.
2) No Users will be able to connect, as which will cause the problems.
 

ORA-01691

On Publishing Large Reports The Message ORA-01691: Unable To Extend LOB Segment

Applies to:

Oracle General Ledger - Version: 11.5.1 to 11.5.10.2 - Release: 11.5.1 to 11.5.10
Oracle Report Manager - Version: 11.5.0 to 11.5.10.2   [Release: 11.5 to 11.5]
Information in this document applies to any platform.
Oracle XML Publisher - Version: 11.5.10
Program: RGRARG - Financial Statement Generator (FSG)

Symptoms

A Performance issue may be experienced with large Financial Statement Generator Reports (FSG) when submitted through Report Manager and log file shows the below message:

Publish and Presentation Program shows in set - , NVT name = PUBLISH_SET_ID, val = END PARAM
Param size? 31 Is In set? falsein set - , NVT name = PUBLISH_SET_ID, val = END PARAM
Failed to insert into database: Application: FND, Message Name: FND_GENERIC_MESSAGE. Tokens:
MESSAGE = oracle.jbo.DMLException: JBO-26041: Failed to post data to database during "Insert": SQL
Statement "JBO-29000: Unexpected exception caught: java.sql.SQLException, msg=ORA-01691: unable to
extend lob segment FRM.SYS_LOB0000345351C00004$$ by 5 in tablespace FRMD
".;

Issue is specific after applying the Patch 7350414 (Superceded)

Cause

This is caused by issues with the custom template used and the size of the report.

The error is caused by the amount of temporary disk space required by the publishing when trying to generate the report. This amount grows depending on the amount of data required in the report.

Solution

To implement the solution, please execute the following steps:

1. Increase the size of tablespace FRMD until the problem is resolved.

2. Size should be increased by large amounts of up to a gigabyte.

This error should be handled no differently from other errors indicating the
inability to extend a database segment. Initial confusion may occur given the
unique nature of LOB storage.

Background Processes In 11g



Here are the new background processes in 11g :-


ACMS (atomic control file to memory service) per-instance process is an agent that contributes to ensuring a distributed SGA memory update is either globally committed on success or globally aborted in the event of a failure in an Oracle RAC environment.

DBRM (database resource manager) process is responsible for setting resource plans and other resource manager related tasks.

* DIA0 (diagnosability process 0) (only 0 is currently being used) is responsible for hang detection and deadlock resolution.

DIAG (diagnosability) process performs diagnostic dumps and executes global oradebug commands.

EMNC (event monitor coordinator) is the background server process used for database event management and notifications.

FBDA (flashback data archiver process) archives the historical rows of tracked tables into flashback data archives. Tracked tables are tables which are enabled for flashback archive. When a transaction containing DML on a tracked table commits, this process stores the pre-image of the rows into the flashback archive. It also keeps metadata on the current rows.

FBDA is also responsible for automatically managing the flashback data archive for space, organization, and retention and keeps track of how far the archiving of tracked transactions has occurred.

GTX0-j (global transaction) processes provide transparent support for XA global transactions in an Oracle RAC environment. The database autotunes the number of these processes based on the workload of XA global transactions. Global transaction processes are only seen in an Oracle RAC environment.

KATE performs proxy I/O to an ASM metafile when a disk goes offline.

MARK marks ASM allocation units as stale following a missed write to an offline disk.

SMCO (space management coordinator) process coordinates the execution of various space management related tasks, such as proactive space allocation and space reclamation. It dynamically spawns slave processes (Wnnn) to implement the task.

VKTM (virtual keeper of time) is responsible for providing a wall-clock time (updated every second) and reference-time counter (updated every 20 ms and available only when running at elevated priority).

Concurrent Requests Scripts in 11i Applications


 

As part of day to day work, we need to use lot of queries to check the information about concurrent requests. Here are few queries which can be frequently used for day to day works and troubleshooting concurrent request / manager issues.
Note: These queries needs to be run from APPS schema.

Scheduled concurrent requests


Lot of times we need to find out the concurrent programs scheduled. Users can schedule the concurrent requests in three ways (To run once at a specified time / To run periodically / To run on specific days of the month or week).

The below query will return all the concurrent requests which are scheduled using any of the above methods:

SELECT cr.request_id,
DECODE (cp.user_concurrent_program_name,
'Report Set', 'Report Set:' || cr.description,
cp.user_concurrent_program_name
) NAME,
argument_text, cr.resubmit_interval,
NVL2 (cr.resubmit_interval,
'PERIODICALLY',
NVL2 (cr.release_class_id, 'ON SPECIFIC DAYS', 'ONCE')
) schedule_type,
DECODE (NVL2 (cr.resubmit_interval,
'PERIODICALLY',
NVL2 (cr.release_class_id, 'ON SPECIFIC DAYS', 'ONCE')
),
'PERIODICALLY', 'EVERY '
|| cr.resubmit_interval
|| ' '
|| cr.resubmit_interval_unit_code
|| ' FROM '
|| cr.resubmit_interval_type_code
|| ' OF PREV RUN',
'ONCE', 'AT :'
|| TO_CHAR (cr.requested_start_date, 'DD-MON-RR HH24:MI'),
'EVERY: ' || fcr.class_info
) schedule,
fu.user_name, requested_start_date
FROM apps.fnd_concurrent_programs_tl cp,
apps.fnd_concurrent_requests cr,
apps.fnd_user fu,
apps.fnd_conc_release_classes fcr
WHERE cp.application_id = cr.program_application_id
AND cp.concurrent_program_id = cr.concurrent_program_id
AND cr.requested_by = fu.user_id
AND cr.phase_code = 'P'
AND cr.requested_start_date > SYSDATE
AND cp.LANGUAGE = 'US'
AND fcr.release_class_id(+) = cr.release_class_id
AND fcr.application_id(+) = cr.release_class_app_id;

Note: The "SCHEDULE" column in the above query returns a string of zeros and ones for the requests which are scheduled on specific days of the month or week.

Positions 1 through 31: Specific day of the month.
Position 32: Last day of the month
Positions 33 through 39: Sunday through Saturday

Checking the duplicated schedules of the same program with the same arguments


The below query can be used to check the duplicated schedule of the same program with the same arguments. This can be used to alert the users to cancel these duplicated schedules.

Note: This query will return even though the request was submitted using a different responsibility.

SELECT request_id, NAME, argument_text, user_name
FROM (SELECT cr.request_id,
DECODE (cp.user_concurrent_program_name,
'Report Set', 'Report Set:' || cr.description,
cp.user_concurrent_program_name
) NAME,
argument_text, fu.user_name
FROM apps.fnd_concurrent_programs_tl cp,
apps.fnd_concurrent_requests cr,
apps.fnd_user fu
WHERE cp.application_id = cr.program_application_id
AND cp.concurrent_program_id = cr.concurrent_program_id
AND cr.requested_by = fu.user_id
AND cr.phase_code = 'P'
AND cr.requested_start_date > SYSDATE
AND cp.LANGUAGE = 'US'
AND fu.user_name NOT LIKE 'PPG%') t1
WHERE EXISTS (
SELECT 1
FROM (SELECT cr.request_id,
DECODE (cp.user_concurrent_program_name,
'Report Set', 'Report Set:'
|| cr.description,
cp.user_concurrent_program_name
) NAME,
argument_text, fu.user_name
FROM apps.fnd_concurrent_programs_tl cp,
apps.fnd_concurrent_requests cr,
apps.fnd_user fu
WHERE cp.application_id = cr.program_application_id
AND cp.concurrent_program_id =
cr.concurrent_program_id
AND cr.requested_by = fu.user_id
AND cr.phase_code = 'P'
AND cr.requested_start_date > SYSDATE
AND cp.LANGUAGE = 'US'
AND fu.user_name NOT LIKE 'PPG%') t2
WHERE t1.NAME = t2.NAME
AND t1.argument_text = t2.argument_text
AND t1.user_name = t2.user_name
GROUP BY NAME, argument_text, user_name
HAVING COUNT (*) > 1)
ORDER BY user_name, NAME 

Average pending time per request


This is a very useful query to check the performance of the concurrent managers.

Average pending time for a request is calculated like below:
("Highest of Requested_start_date or Date_submitted" - Actual_start_date ) / Total requests

A Request can be in Pending state for variety of reasons like conflict with other requests, improperly tuned managers (sleep seconds / cache size / number of managers etc)

We can schedule this script to gather data regularly for historical analysis as we normally purge the concurrent requests regularly.
SELECT TO_CHAR (actual_start_date, 'DD-MON-YYYY') DAY,
concurrent_queue_name,
(SUM ( ( actual_start_date
- (CASE
WHEN requested_start_date > request_date
THEN requested_start_date
ELSE request_date
END
)
)
* 24
* 60
* 60
)
)
/ COUNT (*) "Wait_Time_per_Req_in_Secs"
FROM apps.fnd_concurrent_requests cr,
apps.fnd_concurrent_processes fcp,
apps.fnd_concurrent_queues fcq
WHERE cr.phase_code = 'C'
AND cr.actual_start_date IS NOT NULL
AND cr.requested_start_date IS NOT NULL
AND cr.controlling_manager = fcp.concurrent_process_id
AND fcp.queue_application_id = fcq.application_id
AND fcp.concurrent_queue_id = fcq.concurrent_queue_id
GROUP BY TO_CHAR (actual_start_date, 'DD-MON-YYYY'), concurrent_queue_name
ORDER BY 2
Note: Depending on the purging schedules some requests might miss if the corresponding data in fnd_concurrent_processes is purged.

Checking which manager is going to execute a program

The below query identifies the manager which will be executing a given program. This query is based on the specialization rules set for the managers.
SELECT user_concurrent_program_name, user_concurrent_queue_name
FROM apps.fnd_concurrent_programs_tl cp,
apps.fnd_concurrent_queue_content cqc,
apps.fnd_concurrent_queues_tl cq
WHERE cqc.type_application_id(+) = cp.application_id
AND cqc.type_id(+) = cp.concurrent_program_id
AND cqc.type_code(+) = 'P'
AND cqc.include_flag(+) = 'I'
AND cp.LANGUAGE = 'US'
AND cp.user_concurrent_program_name = '&USER_CONCURRENT_PROGRAM_NAME' AND NVL (cqc.concurrent_queue_id, 0) = cq.concurrent_queue_id
AND NVL (cqc.queue_application_id, 0) = cq.application_id
AND cq.LANGUAGE = 'US'

To see all the pending / Running requests per each manager wise

SELECT request_id, phase_code, status_code, user_name,
user_concurrent_queue_name
FROM apps.fnd_concurrent_worker_requests cwr,
apps.fnd_concurrent_queues_tl cq,
apps.fnd_user fu
WHERE (cwr.phase_code = 'P' OR cwr.phase_code = 'R')
AND cwr.hold_flag != 'Y'
AND cwr.requested_start_date <= SYSDATE
AND cwr.concurrent_queue_id = cq.concurrent_queue_id
AND cwr.queue_application_id = cq.application_id
AND cq.LANGUAGE = 'US'
AND cwr.requested_by = fu.user_id
ORDER BY 5
Note: The same information can be seen in Administer Concurrent Manager form for each manager.

Checking the incompatibilities between the programs


The below query can be used to find all incompatibilities in an application instance.
SELECT a2.application_name, a1.user_concurrent_program_name,
DECODE (running_type,
'P', 'Program',
'S', 'Request set',
'UNKNOWN'
) "Type",
b2.application_name "Incompatible App",
b1.user_concurrent_program_name "Incompatible_Prog",
DECODE (to_run_type,
'P', 'Program',
'S', 'Request set',
'UNKNOWN'
) incompatible_type
FROM apps.fnd_concurrent_program_serial cps,
apps.fnd_concurrent_programs_tl a1,
apps.fnd_concurrent_programs_tl b1,
apps.fnd_application_tl a2,
apps.fnd_application_tl b2
WHERE a1.application_id = cps.running_application_id
AND a1.concurrent_program_id = cps.running_concurrent_program_id
AND a2.application_id = cps.running_application_id
AND b1.application_id = cps.to_run_application_id
AND b1.concurrent_program_id = cps.to_run_concurrent_program_id
AND b2.application_id = cps.to_run_application_id
AND a1.language = 'US'
AND a2.language = 'US'
AND b1.language = 'US'
AND b2.language = 'US'
The table apps.fnd_concurrent_program_serial has the information about incompatibilities.

How do you manually regenerate a form in Oracle Apps R12.



1. Check the FORMS_PATH env variable. Assuming these are US forms the FORMS_PATH should include
$APPL_TOP/resource and $APPL_TOP/forms/US.

2. To compile a form manually from the command line try either of these two command line arguments (replace FNDFBMAS.fmb with the form of your choice.):
frmcmp.sh module=FNDFBMAS.fmb userid=apps/<apps password> module_type=form batch=yes compile_all=yes
frmcmp_batch module=FNDFBMAS.fmb userid=apps/<apps password> module_type=form batch=yes compile_all=yes

ERROR 1396 (HY000): Operation ALTER USER failed for 'Mysql'@'%'

 This MySQL error — ERROR 1396 (HY000): Operation ALTER USER failed for 'Mysql'@'%' — means that MySQL cannot find the user ...