Sirsi Admin

Notify Web Services Librarian ASAP so that a note can be placed on the website about the catalog downtown during re-indexing.

Notify systems@shsu.edu and cc operations@shsu.edu the date and time re-indexing is occurring so services may be going up and down. 

Try to schedule the reports so they will complete before the nighty restart BUT if absolutely necessary, ask IT (Leif Kusch) to suspend the nightly restart

If a large number of items/titles have been added, suspend aduitem and adutext until after the rebuild headings and rebuild text database reports have run.  When they are run before the rebuilds they can get hung up because of the number of new items/titles to add.

Note: Typically suspend adutext report the day before re-indexing, it is option to suspend aduitem.

1. Rebuild Heading Database* Workstation server must be halted  (takes about 4.5 hrs on 2.18.18) no cataloging!
   1. Multiple processors should be 5
2. Rebuild Text Database (takes about 7 hours)  (can Circulate) no cataloging!
   1. Number of titles per load: 250000
   2. Check Rebuild DB concurrently

Note: recommend starting at 5:00 a.m. on a Sunday.  Should be done by around 2:00 p.m. opening. 

 

1. MARC Import
2. Bibliographic Database Overlay (Bibloadbatch)
3. Authority Database Overlay (Loadauthbatch)   Load Authority Records (loadauthimp)
4. Delete files here: Unicorn/Database/Authedit 
   • winscp: highlight all and delete
   • putty: rm -f /s/sirsi/Unicorn/Database/Authedit/*
5. Rebuildauth right after you close for the day.
6. Auth_maint right after that
7. Rebuild Heading Databases (rebuildheading)* Workstation server must be halted in order to run this report. after midnight**(Run time: 16 hours)
8. Rebuild Text Database Report (Rebuildtext) (Run time: 7.5 hours)
   • Number of titles per load: 250000
   • Check Rebuild DB concurrently

** Reports will not run if they spill over to the next day!!

 

UNI-23 - Authority Database Overlay fails on unicode instance

Go to putty and log in as sirsi users

sudo su - sirsi 

unicornadmin

HALT (enter)

number that corresponds to the server you would like to halt

Check report status:

•  pstree -pa 377 look for reportrun process. Under that process will be a series of other processes that can tell you which report is currently running.
• Go to Unicorn/Rptprint and type "tail printlist" - this displays the end of the finished reports list

Once there is no longer a reportrun process

sudo systemctl restart sirsi

 

 

Rebuild heading report

There are multiple ways to check the status of a rebuild heading report.  The quickest way to perform this check is to run the following API command.

The API that would be used to check on this is as follows.

• selcatalog -30 -40>/dev/null

This command will output all records with no heading offset value, that are not review records.  The output will look similar to the following.

•   1161530 $<catalog> $(1308)
     67584 $<catalog> $(1309)

In this case, there are 67584 records left to be processed by the report, out of 1161530.  This is not always going to be exact, as shadowed records will not be assigned a heading, but it should give you a decent idea of how many records have or have not been processed by rebuild heading.

Rebuild text report

There are some ways to check the progress of the rebuild text report.  Usually the easiest way to do this that works across all platforms is to run the following command to get a count of all catalog records that exist in the database.

• selcatalog>/dev/null
81328 $<catalog> $(1308)
81328 $<catalog> $(1309)

The output from the above command is simply the number of catalog records that exist in the database.  You then need to compare this total to the number that is currently in the BRS index.  You can do this by typing the following command to enter the brsearch utility.

• brsearch kuni

Once in the utility type 0, then hit enter.  This will tell you how many records have been indexed by the report.  The difference between this number and the number in the above command will tell you how many records still need to be processed.  Now type ..o to exit from this utility.

 

*** BRS/Search for UNIX ***

Initializing ...

            Copyright (c) 1995 by Dataware Technologies, Inc.
                          All rights reserved.
     Use by unauthorized persons is a violation of applicable laws.

Revision 6.2  (063-03208-SUN4SPARC-ABCEX)

Distributed by: SIRSI
   Licensed To: Sirsi Test Keys
                Huntsville,AL 35801

BRS/Search Full-Text Retrieval System

Wait ...

*Sign-On                        Wed Apr  8 09:44:13 2015

KUNI    KUN0, KUN1, KUN2 and KUN3 indexes
BRS Search Mode -- Enter Query

  1_: 0
  1_: 0 ...............................................     50000 docs

  2_: ..o
Connect Time for KUNI:  00:00:45
   Total Connect Time:  00:00:45

Session Complete

In the above examples, the site has 81328 catalog records, and 50000 have been processed.  This means it is working on the 2nd batch of 50000 records.  Once these two numbers are the same, the report will move on to indexing items.  You can check the progress of this using the same methods, except you will use the following command to get total items.

• selitem>/dev/null

Then run the following command to get into the brs utility to search for items.

• brsearch iuni

Once the numbers in the items database match, the report is finished, and should be in the final steps

**Always perform these checks prior to killing a rebuild text report.  The rebuild text report dumps the entire keyword index when it starts, so if it is killed, keyword searching will not work properly.  It will need to be run again to rebuild the index properly.  If progress is still being made, you will not want to kill the report.

 

****IMPORTANT NOTE:  This is strictly to check how far along the report is.  You need to go through the other checks within article number 127500 to perform normal checks to see if the report is hung or not.  The report can get hung up very early on and result in the report never actually processing any data.  Typically, if the number of records in the above brsearch command is not equal to an even multiple of 50000, the report should either be done, or it is hung up on the early steps and has not yet cleared out the indexes to start the rebuild.  Run the following series of commands to determine if in fact the report is hung on the first steps of the report.
 

1. ps -ef | grep reportrun

   This should give you info on the process id used for the report.  On Windows you will have to use process explorer to find the reportrun process.
    

2. UNIX: ptree PID
   LINUX: pstree -pa PID
   WINDOWS: view each of the processes through process explorer.

    

3. If the last running process in the process tree is running a command similar to the following, the report is hung up.  

   brsload kuni -create -force</dev/null
    

4. If that is the case, you likely need to clear out brslocks to allow a new index to be created, and the old one to be removed.

   brslock -clear