Skip to Main Content

APEX

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Error installing application

John VaughanSep 5 2008 — edited Sep 5 2008
Dear all - our main application export file has now grown to over 15MB,
and we've started having problems installing it into other workspaces.
It's not actually the upload that fails (which some users have
experienced, and seems to be related to an HTTP server timeout), but
the next step; installing it. The browser timeout error happens after
you have loaded the application, but before the page loads that prompts
for the parsing schema and app ID. Clicking on Install from the Export
Repository leads to the same error.

Although we have not yet got
to the bottom of that problem, the received advice seems to be to
install the application using SQL*Plus. Although this seems to
introduce plenty of opportunities for getting it to go wrong, the basic
advice (taken from one of Scott Spadafore's posts on the subject) is:

+"This
is not a normal approach. You'd have to edit the primary application
export file for each new application you want to create. Look through
the file and change references to the "exported" application ID to the
desired application ID. They will be in lines like the following where
I show 9999 as the original ID:+

+wwv_flow.g_flow_id := 9999;+

+wwv_flow_api.remove_flow(9999);+

+wwv_flow_audit.remove_audit_trail(9999);+

+wwv_flow_api.create_flow(+

+ p_id =>9999,+

+ p_display_id=> 9999,+

+ p_alias => 'F9999',+

+ p_owner => 'FOO',+

+For
the "p_owner => 'F00' " case, change the parsing schema FOO to the
new parsing schema, making sure that the schema is actually mapped to
the target workspace.+

+Then you need to look for any text
containing "f?p=9999:..." and change the old application ID to the new
one. There may be none of these in your application but if you find
any, you should also change all of those occurrences in the original
application to use &APP_ID. instead of 9999.+

+Finally, locate
the line: "wwv_flow_api.g_id_offset := 0;" near the top of the file and
change 0 to 1 for the first "new" application, change it to 2 for the
second "new" application, etc. If during import you get any kind of
unique key constraint errors, go back and change the offset to a larger
integer and try again.+

+N.B., this approach cannot be used if your application has been translated."+

However, doing this lead (in our case) to the error:

Illegal security group id value for this schema

and, later in the SQL*Plus prompts:

ORA-20001: Package variable g_security_group_id must be set

Near the beginning of the installation script file, there is the statement:

wwv_flow_api.set_security_group_id(p_security_group_id=>NNNNNNNNNNNNNNNNN);

(where NNNNNNNNNNNNNNNNN
is a large number). Because we are installing from one workspace to
another, and because of the nature of the error message, I tried
replacing this number with the value for the target workspace, obtained
using:

select wwv_flow_api.get_security_group_id() from dual

Having done this, the script ran without error.

Thought I'd post this in case it helps anyone.

Regards,

John.

Comments

Dude!

Keep in mind that the default for the control_file_record_keep_time init parameter is 7 days. If you use a RMAN retention period of 1 month, you need to adjust the value accordingly, e.g. 35 days. Otherwise you risk loosing RMAN information and your retention policy cannot work.

When RMAN does a level 1 backup and no previous level 0 backup is found, then RMAN will automatically perform a level 0 backup instead of a level 1 backup.

top.gun
Answer

1) This command tells you everything you need to know:

restore database preview summary until time 'sysdate';

2) RMAN will source anythng missing from the latest backup, from the previous backup.

So RMAN will recognise the 3 latest L0 backupsets, and the 4th that is missing will be sourced from the previous Saturday.

The cumulative L1 backup will be a mixture of blocks since last Saturday, and the previous Saturday.

Marked as Answer by User_UAEUZ · Sep 27 2020
User_UAEUZ

Hi Dude,

Thanks for your reply.

If i am using a RMAN catalog,  do i still need to set the control_file_record_keep_time to more then 7 days ?

Regards,

Noob

User_UAEUZ

Hi TopGun,

Thanks for the wonderful command.

From the preview, i see that one of incremental backup is done really base on a previous Saturday L0 backup.

Thank you!

User_UAEUZ

Hi Dude,

Thanks for your reply and the doc link.  It mentioned ->

If you maintain a recovery catalog, then use the RMAN RESYNCCATALOG command often enough to ensure that control file records are propagated to the recovery catalog before they are reused.

Make sure that CONTROL_FILE_RECORD_KEEP_TIME is longer than the interval between backups or resynchronizations. Otherwise, control file records could be reused before they are propagated to the recovery catalog. An extra week is a safe margin in most circumstances.

I am doing backup daily, and i think when i connect to the rman catalog , it will auto sync the controlfile backup information to the catalog - right ?

If that's the case, why would i stlil need to extend the CONTROL_FILE_RECORD_KEEP_TIME ? (since everyday during backup, the backup information from contorlfile will be sync to the catalog)

Regards,

Noob

Dude!

You must ensure that you resynchronize the recovery catalog with the control file records before these records are erased. For example, if the rman retention is 1 month, control_file_record_keep_time default, then if backup the database only every 2 weeks, information will be incomplete, regardless of the retention setting and using a catalog database.

1 - 7
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Oct 3 2008
Added on Sep 5 2008
1 comment
424 views