- Article Type: General
- Product: Aleph
- Product Version: 16.02
The p_manage_32_c.log has:
FAILURE Wed Aug 23 13:02:08 CDT 2006 ==================
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 !!!
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?
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
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