• Article Type: General
• Product: Aleph
• Product Version: 16.02

Description:
The p_manage_32_c.log has:

FAILURE Wed Aug 23 13:02:08 CDT 2006 ==================
step 2
Cycle: 87

Index failure after load: Z0102_ID1=UNUSABLE\nOracle error: 01652, 00000, "unable to extend temp segment by %
s in tablespace %s" // *Cause: Failed to allocate an extent for temp segment in tablespace. // *Action: Use
ALTER TABLESPACE ADD DATAFILE statement to add one or more // files to the tablespace indicated.\n

Job Suspended !!!

Two questions:

1. Is there a way to restart the p_manage_32_c? If so how? Or do I have to restart the job again?

2. How much space do you think will be needed?

Resolution:
1. From the cycles file we see that none of the bases from UNE-on were loaded. Some UNE z0102's were created.

The p_manage_32.cycles file could be edited, changing both the first and second columns for the UNE cycle and each cycle after it to "+".

Then the $aleph_proc/p_manage_32 would need to be changed to not delete/rebuild the cycles file (so it would use the one that's there).

Then the z0102_id1 -- which is currently UNUSABLE -- would need to be generated so that we could do the following SQL:

SQL> delete from z10102 where z0102_rec_key_1 like 'UNE%';

Then p_manage_32 could be resubmitted with: ODN01,1,ALL,9,

As you can see, this is rather complicated. I am also a leary of this in the odn01_p_manage_32.log:

SQL-ALEPH_ADMIN> DROP TABLE ODN01.Z0102
*
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified


Elapsed: 00:00:00.11
CREATE TABLE ODN01.Z0102 (
*
ERROR at line 1:
ORA-00955: name is already used by an existing object

I think you are better off re-submitting the job from scratch -- and make sure that you don't get these errors on the Drop/Create.

2. The z0102 is currently occupying 14 gig. The remaining 13 bases are 10% of the total of 125 bases. So I estimate that the remaining bases will take 1.4 gig -- but you should add at least 2 gig, to be safe.

• Article last edited: 10/8/2013