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

Description:
This afternoon I discovered thousands of errors in the oracle alert log related to the TS4D tablespace being unable to extend since Mon Feb 20 at 17:16. At 5:42 pm today (2/23) I added a datafile and the log has been clean since....

I'm wondering what action I need to take to resolve any resulting inconsistencies in the database. There were failed inserts into ABC01.Z00R, ABC01.Z01, ABC01.Z95 and ABC10.Z98.

I also found the publish-06 job for our primo instance hasn't produced an outfile since 2/21, which I expect is another side effect. To catch up primo, it seems I can simply comment out the publish-06 job in the job_list, and run it from the gui for the last few days -- do you agree?

Resolution:
1. Run p_ret_01 in abc01 to locate records updated since Feb. 20. 17:16.
2. Run p_manage_40 with the file from step 1 as input. It will write a z07 indexing request for each of the bib records
3. Run p_ret_01 in abc10 to locate records updated since Feb. 20. 17:16.
4. Run p_manage_40 with the file from step 3 as input. It will write a z07 indexing request for each of the authority records

In regard to publishing, in the $aleph_root/tab/tab_publish_timestamp we have:
PRIMO-FULL 201202210130519

Assuming that the emu01 ue_21 is running, it should take the z07p's produced by ue_01 and generate z00p records which p_publish_06, when run with the normal p_publish_type "LAST-DATE", *should* process (-- all with dates later than 2012-02-20).

Note: The above worked.

• Article last edited: 10/8/2013