1) Replacing Oracle Containers for Java (OC4J) 10g with WebLogic Server 11g
2) Online Patching support via 11gR2 Edition-Based Redefinition

1. Replacing OC4J with WebLogic Server

EBS 12.2 will use WebLogic Server from Fusion Middleware 11g in place of OC4J 10g as part of the release’s internal technology stack. Other additional new Fusion Middleware 11g components used will include WebLogic JSP and UIX 11g.

2. Online Patching support via 11gR2 Edition-Based Redefinition

EBS 12.2 will use the 11gR2 Database’s Edition-Based Redefinition features to provide support for Online Patching. Edition-Based Redefinition is really exciting new technology. From the 11gR2 Application Developer’s Guide:

“Edition-based redefinition enables you to upgrade the database component of an application while it is in use, thereby minimizing or eliminating down time.

“To upgrade an application while it is in use, you copy the database objects that comprise the application and redefine the copied objects in isolation. Your changes do not affect users of the application—they continue to run the unchanged application. When you are sure that your changes are correct, you make the upgraded application available to all users.”

Online Patching means that patches that change EBS database objects can be applied while the E-Business Suite production instance is fully operational. Only a short downtime will be required to complete the patching process. This will make your patching downtimes more predictable.

Read more on Steven Chan Blog

I have framed a sql query with help of my technical friends to get below details

1. Request id

2. Concurrent program full name

3. Concurrent program short name

4. Start time, and End time.

5. Runtime

6. Parameters passed to the request

7. Submitted by

8. Status code and Phase code

SELECT request_id,
user_concurrent_program_name Concurrent_Program_Full_Name,
program_short_name Concurrent_Program_Short_Name,
actual_start_date,
actual_completion_date,
FLOOR( ( (actual_completion_date – actual_start_date) * 24 * 60 * 60)
/ 3600)
|| ‘ HOURS ‘
|| FLOOR( ( ( (actual_completion_date – actual_start_date)
* 24
* 60
* 60)
– FLOOR( ( (actual_completion_date – actual_start_date)
* 24
* 60
* 60)
/ 3600)
* 3600)
/ 60)
|| ‘ MINUTES ‘
|| ROUND( ( ( (actual_completion_date – actual_start_date)
* 24
* 60
* 60)
– FLOOR( ( (actual_completion_date – actual_start_date)
* 24
* 60
* 60)
/ 3600)
* 3600
– (FLOOR( ( ( (actual_completion_date – actual_start_date)
* 24
* 60
* 60)
– FLOOR( ( (actual_completion_date
– actual_start_date)
* 24
* 60
* 60)
/ 3600)
* 3600)
/ 60)
* 60)))
|| ‘ SECS ‘
time_difference,
argument_text Parameter,
requestor submited_by,
status_code,
phase_code
FROM FND_CONC_REQ_SUMMARY_V

Recently after EBS upgrade to 12.1.3 CM were not functional and was showing status “System Hold, Fix Manager before resetting counters”.

Issue:
Concurrent Manager showing status “System Hold, Fix Manager before resetting counters”.

Solution:
To implement the solution, please execute the following steps:

1. Stop all middle tier services including the concurrent managers.
Please make sure that no FNDLIBR, FNDSM, or any dead process is
running.

2. Go to cd $FND_TOP/bin
$ adrelink.sh force=y link_debug=y “fnd FNDLIBR”
$ adrelink.sh force=y link_debug=y “fnd FNDFS”
$ adrelink.sh force=y link_debug=y “fnd FNDCRM”
$ adrelink.sh force=y link_debug=y “fnd FNDSM”

3. Run the CMCLEAN.SQL script from the referenced note below (don’t forget to commit).
Note 134007.1 CMCLEAN.SQL – Non Destructive Script to Clean Concurrent Manager Tables

4. Start the concurrent manager.

5. Retest the issue.

Reference :
SCHEDULE/PRERELEASER MANAGER STATUS : SYSTEM HOLD, FIX MANAGER BEFORE RESETTING [ID 985835.1]

I have found a interesting sql query which gives details of scheduled concurrent requests in EBS.

/*SQL 1*/

SELECT r.request_id
, CASE
WHEN pt.user_concurrent_program_name = ‘Report Set’
THEN DECODE(
r.description
, NULL, pt.user_concurrent_program_name
, r.description
|| ‘ (‘
|| pt.user_concurrent_program_name
|| ‘)’
)
ELSE pt.user_concurrent_program_name
END job_name
, u.user_name requestor
, u.description requestor_description
, u.email_address
, frt.responsibility_name requested_by_resp
, r.request_date
, r.requested_start_date
, DECODE(
r.hold_flag
, ‘Y’, ‘Yes’
, ‘N’, ‘No’
) on_hold
, CASE
WHEN r.hold_flag = ‘Y’
THEN SUBSTR(
u2.description
, 0
, 40
)
END last_update_by
, CASE
WHEN r.hold_flag = ‘Y’
THEN r.last_update_date
END last_update_date
, r.argument_text PARAMETERS
, NVL2(
r.resubmit_interval
, ‘Periodically’
, NVL2(
r.release_class_id
, ‘On specific days’
, ‘Once’
)
) AS schedule_type
, r.resubmit_interval resubmit_every
, r.resubmit_interval_unit_code resubmit_time_period
, DECODE(
r.resubmit_interval_type_code
, ‘START’, ‘From the start of the prior run’
, ‘END’, ‘From the Completion of the prior run’
) apply_the_update_option
, r.increment_dates
, TO_CHAR((r.requested_start_date), ‘HH24:MI:SS’) start_time
FROM applsys.fnd_concurrent_programs_tl pt
, applsys.fnd_concurrent_programs pb
, applsys.fnd_user u
, applsys.fnd_user u2
, applsys.fnd_printer_styles_tl s
, applsys.fnd_concurrent_requests r
, applsys.fnd_responsibility_tl frt
WHERE pb.application_id = r.program_application_id
AND pb.concurrent_program_id = r.concurrent_program_id
AND pb.application_id = pt.application_id
AND r.responsibility_id = frt.responsibility_id
AND pb.concurrent_program_id = pt.concurrent_program_id
AND u.user_id = r.requested_by
AND u2.user_id = r.last_updated_by
AND s.printer_style_name(+) = r.print_style
AND r.phase_code = ‘P’
AND 1 = 1;

/*SQL 2*/

select r.request_id,
p.user_concurrent_program_name || nvl2(r.description,’ (‘||r.description||’)',null) Conc_prog,
s.user_name REQUESTOR,
r.argument_text arguments,
r.requested_start_date next_run,
r.last_update_date LAST_RUN,
r.hold_flag on_hold,
r.increment_dates,
decode(c.class_type,
‘P’, ‘Periodic’,
‘S’, ‘On Specific Days’,
‘X’, ‘Advanced’,
c.class_type) schedule_type,
case
when c.class_type = ‘P’ then
‘Repeat every ‘ ||
substr(c.class_info, 1, instr(c.class_info, ‘:’) – 1) ||
decode(substr(c.class_info, instr(c.class_info, ‘:’, 1, 1) + 1, 1),
‘N’, ‘ minutes’,
‘M’, ‘ months’,
‘H’, ‘ hours’,
‘D’, ‘ days’) ||
decode(substr(c.class_info, instr(c.class_info, ‘:’, 1, 2) + 1, 1),
‘S’, ‘ from the start of the prior run’,
‘C’, ‘ from the completion of the prior run’)
when c.class_type = ‘S’ then
nvl2(dates.dates, ‘Dates: ‘ || dates.dates || ‘. ‘, null) ||
decode(substr(c.class_info, 32, 1), ’1′, ‘Last day of month ‘) ||
decode(sign(to_number(substr(c.class_info, 33))),
’1′, ‘Days of week: ‘ ||
decode(substr(c.class_info, 33, 1), ’1′, ‘Su ‘) ||
decode(substr(c.class_info, 34, 1), ’1′, ‘Mo ‘) ||
decode(substr(c.class_info, 35, 1), ’1′, ‘Tu ‘) ||
decode(substr(c.class_info, 36, 1), ’1′, ‘We ‘) ||
decode(substr(c.class_info, 37, 1), ’1′, ‘Th ‘) ||
decode(substr(c.class_info, 38, 1), ’1′, ‘Fr ‘) ||
decode(substr(c.class_info, 39, 1), ’1′, ‘Sa ‘))
end as schedule,
c.date1 start_date,
c.date2 end_date
from fnd_concurrent_requests r,
fnd_conc_release_classes c,
fnd_concurrent_programs_tl p,
fnd_user s,
(with date_schedules as (
select release_class_id,
rank() over(partition by release_class_id order by s) a, s
from (select c.class_info, l,
c.release_class_id,
decode(substr(c.class_info, l, 1), ’1′, to_char(l)) s
from (select level l from dual connect by level 0)
where s is not null)
SELECT release_class_id, substr(max(SYS_CONNECT_BY_PATH(s, ‘ ‘)), 2) dates
FROM date_schedules
START WITH a = 1
CONNECT BY nocycle PRIOR a = a – 1
group by release_class_id) dates
where r.phase_code = ‘P’
and c.application_id = r.release_class_app_id
and c.release_class_id = r.release_class_id
and nvl(c.date2, sysdate + 1) > sysdate
and c.class_type is not null
and p.concurrent_program_id = r.concurrent_program_id
and p.language = ‘US’
and dates.release_class_id(+) = r.release_class_id
and r.requested_by = s.user_id
order by conc_prog, on_hold, next_run;

SELECT fcr.request_id
, fcpt.user_concurrent_program_name|| NVL2(fcr.description, ‘ (‘ || fcr.description || ‘)’, NULL) conc_prog
, fu.user_name requestor
, fu.description requested_by
, fu.email_address
, frt.responsibility_name requested_by_resp
, trim(fl.meaning) status
, fcr.phase_code
, fcr.status_code
, fcr.argument_text “PARAMETERS”
, ‘——>’ dates
, TO_CHAR(fcr.request_date, ‘DD-MON-YYYY HH24:MI:SS’) requested
, TO_CHAR(fcr.requested_start_date, ‘DD-MON-YYYY HH24:MI:SS’) requested_start
, TO_CHAR((fcr.requested_start_date), ‘HH24:MI:SS’) start_time
, ‘——>’ holds
, DECODE(fcr.hold_flag, ‘Y’, ‘Yes’, ‘N’, ‘No’) on_hold
, CASE
WHEN fcr.hold_flag = ‘Y’
THEN SUBSTR(
u2.description
, 0
, 40
)
END last_update_by
, CASE
WHEN fcr.hold_flag = ‘Y’
THEN fcr.last_update_date
END last_update_date
, ‘——>’ prints
, fcr.number_of_copies print_count
, fcr.printer
, fcr.print_style
, ‘——>’ schedule
, fcr.increment_dates
, CASE WHEN fcrc.CLASS_INFO IS NULL THEN
‘Yes: ‘ || TO_CHAR(fcr.requested_start_date, ‘DD-MON-YYYY HH24:MI:SS’)
ELSE
‘n/a’
END run_once
, CASE WHEN fcrc.class_type = ‘P’ THEN
‘Repeat every ‘ ||
substr(fcrc.class_info, 1, instr(fcrc.class_info, ‘:’) – 1) ||
decode(substr(fcrc.class_info, instr(fcrc.class_info, ‘:’, 1, 1) + 1, 1),
‘N’, ‘ minutes’,
‘M’, ‘ months’,
‘H’, ‘ hours’,
‘D’, ‘ days’) ||
decode(substr(fcrc.class_info, instr(fcrc.class_info, ‘:’, 1, 2) + 1, 1),
‘S’, ‘ from the start of the prior run’,
‘C’, ‘ from the completion of the prior run’)
ELSE
‘n/a’
END set_days_of_week
, CASE WHEN fcrc.class_type = ‘S’ AND instr(substr(fcrc.class_info, 33),’1′,1) > 0 THEN
‘Days of week: ‘ ||
decode(substr(fcrc.class_info, 33, 1), ’1′, ‘Sun, ‘) ||
decode(substr(fcrc.class_info, 34, 1), ’1′, ‘Mon, ‘) ||
decode(substr(fcrc.class_info, 35, 1), ’1′, ‘Tue, ‘) ||
decode(substr(fcrc.class_info, 36, 1), ’1′, ‘Wed, ‘) ||
decode(substr(fcrc.class_info, 37, 1), ’1′, ‘Thu, ‘) ||
decode(substr(fcrc.class_info, 38, 1), ’1′, ‘Fri, ‘) ||
decode(substr(fcrc.class_info, 39, 1), ’1′, ‘Sat ‘)
ELSE
‘n/a’
end days_of_week
, CASE WHEN fcrc.class_type = ‘S’ AND instr(substr(fcrc.class_info, 1, 31),’1′,1) > 0 THEN
‘Set Days of Month: ‘ ||
decode(substr(fcrc.class_info, 1, 1), ’1′, ’1st, ‘) ||
decode(substr(fcrc.class_info, 2, 1), ’1′, ’2nd, ‘) ||
decode(substr(fcrc.class_info, 3, 1), ’1′, ’3rd, ‘) ||
decode(substr(fcrc.class_info, 4, 1), ’1′, ’4th, ‘) ||
decode(substr(fcrc.class_info, 5, 1), ’1′, ’5th, ‘) ||
decode(substr(fcrc.class_info, 6, 1), ’1′, ’6th, ‘) ||
decode(substr(fcrc.class_info, 7, 1), ’1′, ’7th, ‘) ||
decode(substr(fcrc.class_info, 8, 1), ’1′, ’8th, ‘) ||
decode(substr(fcrc.class_info, 9, 1), ’1′, ’9th, ‘) ||
decode(substr(fcrc.class_info, 10, 1), ’1′, ’10th, ‘) ||
decode(substr(fcrc.class_info, 11, 1), ’1′, ’11th, ‘) ||
decode(substr(fcrc.class_info, 12, 1), ’1′, ’12th, ‘) ||
decode(substr(fcrc.class_info, 13, 1), ’1′, ’13th, ‘) ||
decode(substr(fcrc.class_info, 14, 1), ’1′, ’14th, ‘) ||
decode(substr(fcrc.class_info, 15, 1), ’1′, ’15th, ‘) ||
decode(substr(fcrc.class_info, 16, 1), ’1′, ’16th, ‘) ||
decode(substr(fcrc.class_info, 17, 1), ’1′, ’17th, ‘) ||
decode(substr(fcrc.class_info, 18, 1), ’1′, ’18th, ‘) ||
decode(substr(fcrc.class_info, 19, 1), ’1′, ’19th, ‘) ||
decode(substr(fcrc.class_info, 20, 1), ’1′, ’20th, ‘) ||
decode(substr(fcrc.class_info, 21, 1), ’1′, ’21st, ‘) ||
decode(substr(fcrc.class_info, 22, 1), ’1′, ’22nd, ‘) ||
decode(substr(fcrc.class_info, 23, 1), ’1′, ’23rd,’ ) ||
decode(substr(fcrc.class_info, 24, 1), ’1′, ’24th, ‘) ||
decode(substr(fcrc.class_info, 25, 1), ’1′, ’25th, ‘) ||
decode(substr(fcrc.class_info, 26, 1), ’1′, ’26th, ‘) ||
decode(substr(fcrc.class_info, 27, 1), ’1′, ’27th, ‘) ||
decode(substr(fcrc.class_info, 28, 1), ’1′, ’28th, ‘) ||
decode(substr(fcrc.class_info, 29, 1), ’1′, ’29th, ‘) ||
decode(substr(fcrc.class_info, 30, 1), ’1′, ’30th, ‘) ||
decode(substr(fcrc.class_info, 31, 1), ’1′, ’31st. ‘)
ELSE
‘n/a’
END days_of_month
, CASE WHEN fcrc.class_type = ‘S’ AND substr(fcrc.class_info, 32, 1) = ’1′ THEN
‘Yes’
ELSE
‘n/a’
END last_day_of_month_ticked
, fcrc.CLASS_INFO
FROM applsys.fnd_concurrent_requests fcr
, applsys.fnd_user fu
, applsys.fnd_user u2
, applsys.fnd_concurrent_programs fcp
, applsys.fnd_concurrent_programs_tl fcpt
, applsys.fnd_printer_styles_tl fpst
, applsys.fnd_conc_release_classes fcrc
, applsys.fnd_responsibility_tl frt
, apps.fnd_lookups fl
WHERE fcp.application_id = fcpt.application_id
AND fcr.requested_by = fu.user_id
AND fcr.concurrent_program_id = fcp.concurrent_program_id
AND fcr.program_application_id = fcp.application_id
AND fcr.concurrent_program_id = fcpt.concurrent_program_id
AND fcr.responsibility_id = frt.responsibility_id
AND fcr.last_updated_by = u2.user_id
AND fcr.print_style = fpst.printer_style_name(+)
AND fcr.release_class_id = fcrc.release_class_id(+)
AND fcr.status_code = fl.lookup_code
AND fl.lookup_type = ‘CP_STATUS_CODE’
AND fcr.phase_code = ‘P’
AND 1=1
ORDER BY fu.description, fcr.requested_start_date asc;

Sysdamin: Profile> System > Query for “Concurrent: Show Requests Summary After Each Request”

If set to Yes, the View Requests form displayed.

If set to No, the Decision Window displayed.

Enjoy Reading ….

RC_BACKUP_CONTROLFILE backup control files in backup sets.

RC_BACKUP_CORRUPTION corrupt blocks in datafile backups and copies.

RC_BACKUP_DATAFILE datafile backups (in backup sets).

RC_BACKUP_PIECE backup pieces.

RC_BACKUP_REDOLOG redo log backups (in backup sets).

RC_BACKUP_SET backup sets.

RC_CHECKPOINT rc_checkpoint is replaced by rc_resync, but is still used by some tests.

RC_CONTROLFILE_COPY controlfile copies.

RC_COPY_CORRUPTION corrupt block ranges in datafile copies for all database incarnations.

RC_DATABASE information about databases and their current incarnations.

RC_DATABASE_INCARNATION information about all incarnations registered in recovery catalog.

RC_DATAFILE information about all datafiles registered in recovery catalog.

RC_DATAFILE_COPY datafile copies (on disk).

RC_LOG_HISTORY information about redo log history.

RC_OFFLINE_RANGE offline ranges for datafiles.

RC_REDO_LOG information about online redo logs.

RC_REDO_THREAD information about redo threads.

RC_RESYNC information about recovery catalog resyncs (checkpoints).

RC_STORED_SCRIPT stored scripts.

RC_STORED_SCRIPT_LINE each line of each stored script.

RC_TABLESPACE information about all tablespaces registered in recovery catalog.

After a database has been created, you can switch the database’s archiving mode on demand. However, you should generally not switch the database between archiving modes.

NOTE: If a database is automatically created during Oracle installation, the initial archiving mode of the database is operating system specific. See your operating system-specific Oracle documentation.

ARCHIVELOG mode is necessary for creating on-line backups and for certain types of database recovery. Configuring the database to operate in
ARCHIVELOG mode allows the user to perform complete and point-in-time recovery from media (disk) failures using off-line or on-line backups. If
ARCHIVELOG mode is disabled, the database can be restored from a backup in case of failure, but it cannot be rolled forward from that to a point when failure occurred.

Oracle recommends ARCHIVELOG mode for all production databases

Setting the Initial Database Archiving Mode
When you create the database, you set the initial archiving mode of the redo log in the CREATE DATABASE statement. If you do not specify either ARCHIVELOG or NOARCHIVELOG, NOARCHIVELOG is the default. To verify database mode, execute following statement:

SQL> Select NAME, CREATED, LOG_MODE, CHECKPOINT_CHANGE#, ARCHIVE_CHANGE# from V$DATABASENAME CREATED LOG_MODE CHECKPOINT_CHANGE# ARCHIVE_CHANGE#——— ——— ———— —————— —————O112 19-MAR-09 NOARCHIVELOG 1438426 135961

Changing the Database Archiving Mode
There are “init.ora” parameters you need to modify in order to properly handle your database being in archive log mode. They are:

LOG_ARCHIVE_DEST LOG_ARCHIVE_FORMAT LOG_ARCHIVE_DEST:
This parameter specifies the directory where your archive logs will be placed.

LOG_ARCHIVE_FORMAT:
This parameter names the archive logs in this format. For example, if your format is: arch%s.arc

Your log files will be called: arch1.arc, arch2.arc, arch3.arc where the ’1′, ’2′, ’3′, etc is the sequence number.

To Prepare to Switch Database Archiving Mode
1. Shut down the database instance.

SQL> shutdown immediateAn open database must be closed and dismounted and any associated instances shut down before the database’s archiving mode can be switched. Archiving cannot be disabled if any datafiles need media recovery.

2. Backup the database.

This backup can be used with the archive logs that you will generate.

3. Perform any operating system specific steps (optional).

4. Start up a new instance and mount, but do not open the database.

SQL> startup mountNOTE: If you are using the Oracle Parallel Server, you must mount the database exclusively using one instance to switch the database’s archiving mode.

5. Put the database into archivelog mode

SQL> alter database archivelog; NOTE: You can also use

alter database noarchivelog to take the database out of archivelog mode

6. Open the database.

SQL> alter database open; 7. Verify your database is now in archivelog mode.

SQL> archive log listDatabase log mode Archive ModeAutomatic archival EnabledArchive destination USE_DB_RECOVERY_FILE_DESTOldest online log sequence 22Next log sequence to archive 24Current log sequence 248. Archive all your redo logs at this point.

SQL> archive log all; 9. Ensure these newly created Archive log files are added to the backup process.

Ref: Metalink ID 69739.1

In 8i, 9i we have to put each tablespace individually in begin/end backup mode to perform the online backup. From 10g onwards the entire database can be put in begin/end backup mode.

Make sure that the database is in archivelog mode

Example :

Performing a single tablespace backup

+ sql>alter tablespace system begin backup;
+ Copy the corresponding datafiles using appropriate O/S commands.
+ sql>alter tablespace system end backup;

Performing a full database backup (starting from 10g)

+ sql> alter database begin backup;
+ Copy all the datafiles using appropriate O/S commands.
+ sql> alter database end backup;

One danger in making online backups is the possibility of inconsistent data within a block. For example, assume that you are backing up block 100 in datafile users.dbf. Also, assume that the copy utility reads the entire block while DBWR is in the middle of updating the block. In this case, the copy utility may read the old data in the top half of the block and the new data in the bottom top half of the block. The result is called a fractured block, meaning that the data contained in this block is not consistent. at a given SCN.

Therefore oracle internally manages the consistency as below :

1. The first time a block is changed in a datafile that is in hot backup mode, the entire block is written to the redo log files, not just the changed bytes. Normally only the changed bytes (a redo vector) is written. In hot backup mode, the entire block is logged the first time. This is because you can get into a situation where the process copying the datafile and DBWR are working on the same block simultaneously.

Lets say they are and the OS blocking read factor is 512bytes (the OS reads 512 bytes from disk at a time). The backup program goes to read an 8k Oracle block. The OS gives it 4k. Meanwhile — DBWR has asked to rewrite this block. the OS schedules the DBWR write to occur right now. The entire 8k block is rewritten. The backup program starts running again (multi-tasking OS here) and reads the last 4k of the block. The backup program has now gotten an fractured block — the head and tail are from two points in time.

We cannot deal with that during recovery. Hence, we log the entire block image so that during recovery, this block is totally rewritten from redo and is consistent with itself atleast. We can recover it from there.

2. The datafile headers which contain the SCN of the last completed checkpoint are not updated while a file is in hot backup mode. This lets the recovery process understand what archive redo log files might be needed to fully recover this file.

To limit the effect of this additional logging, you should ensure you only place one tablepspace at a time in backup mode and bring the tablespace out of backup mode as soon as you have backed it up. This will reduce the number of blocks that may have to be logged to the minimum possible.

Ref : Metalink ID 469950.1