CSO Data Archiving

Introduction and Some History

Until about 1991 CSO data were archived on 9-track tapes. (Warning: these 9-track tapes may still exist). The 9-track tapes were copied to DAT in 1992 by Larry Strom. With the advent of the 3100, archiving was switched to 4mm DAT and 8mm Exabyte tapes, one of which lives at the summit in a rack in the lounge, the other one being in Hilo. Starting in 1995, spectral line data are also archived in a database in the Sparc2 lapakahi. Since early 1998, data archiving into the SYBASE database has been done on kilauea, a Sun Ultra 1 workstation.

The copy of the old archive

Most, but not all of the old 9-track tapes were legible, so some data taken before 1991 may actually be missing.

The copying of the old archive was done by Larry Strom. Larry made 2 copies, both of which are at the summit. There are backup logs available on disk, in subdirectories of DATA:[STROM] (this should really be in USER3:[STROM] but has never been copied there), in case somebody needs to find files on the (copies of the) old archive tapes.

Current VAX Data Archive Since 1992

Logs of archive backups since October 1991 (relating to DAT tapes since February 1992) can be found in USER3:[MAREN.ARCHIVE],
DATA:[MAREN.ARCHIVE] or
USER:[MAREN.ARCHIVE].

Generally, archiving since February 1992 has been done like this:

in USER:[MAREN.ARCHIVE], look up the number of the last saveset written (as of this writing, we are at DATA352, with 353 to be written today or tomorrow).
write the command file to be executed next by copying the previous one (change the number of the saveset as the very FIRST thing when you start editing)
if you want or need to start a new tape initialize it with the label NEW (all our archive tapes are labelled NEW, why I don't know, but this has been so for so long that I can't see a good reason to change it either)
write the backup
make a second file, usually with the suffix _2 and backup .LIST2
write the second tape (as one of the tapes lives in Hilo you will either have to take it up or send it up if you don't want to end up with one saveset per tape)
find out how much disk space you are going to need on DATA/USER2 to accommodate the copy of the files (take user:[maren.archive]x.com as an example)
create the directory structure on DATA that you are going to copy back from the tape (easiest to do by directing the output from x.com to a file, say y.com, and using this file by editing it to create the directories needed)
copy the files back from one of the tapes to the DATA disk, in the 3100, to the same (sub)directory where they have been archived from, using a command like
```
 
BACKUP/LOG/REWIND MKB300:DATA*.BCK/SAVE DATA:[000000...]*.*.*/OWNER=PARENT
```
after that, difference the copied files with the originals and delete data files, postscript plots, etc. that is directly related to that particular observing run from the user directories (I generally leave catalogs, DCL command files, UIP, CLASS and other command files and of course people's email in place) (there is a DCL procedure USER:[MAREN.COM]DIFFDEL.COM to do this, and a DCL procedure USER:[MAREN.COM]DIRCOL.COM to produce a skeleton file if there are many files that have some naming in common (or some such))
to clean up DATA some, execute USER:[MAREN]CLEAN3.COM (it is arranged in order of diminishing returns)

Database dumps and SYBASE backups

The UIP (unless instructed otherwise) writes spectral line data to a dump file in the directory USER:[DDF_FILES] in addition to the CLASS files talked about above. Generally twice a day, at 6 a.m. and 6 p.m. HST, the database upload process starts to run in lapakahi (unless somebody changes that in crontab). The first thing it does after checking that it isn't a duplicate process to one still running from before, is (try to - see below) copy the file out of the VAX into the sparc. It will then continue to upload the data into the database and send email to (currently) Darek Lis, Richard Chamberlin, Mac Cooper and myself.

The email contains a list of all scans uploaded and so can get quite long. However, the end of these is the most important part for the person who has to dump the database. (I use a short DCL procedure, USER:[MAREN.COM]SYB.COM to deal with these).

It is necessary to watch the filling up of the database because if it fills up (usually the channel segment first, and when it gets to about 95% it comes to a screeching halt) it will stop uploading which can cause all sorts or problems (like not transferring and deleting the dump file in the VAX which causes the VAX to run low on disk space, you get the idea), in addition to that it won't be possible to do the normal database dump.

The following is from an email message from Darek Lis:

****** DATABASE ACCOUNTS ******

I set up two Sybase accounts (these are Sybase, not workstation accounts):

(1) Guest account (guest, password csoguest) can be used to view any information stored in the database. However, no modifications are allowed. There is a corresponding workstation account with the same username and password.

(2) Root account (root, ask me for password) can be used to view and update information in the database. Use this account with caution.

Both Sybase accounts can be accessed from any account on the workstation.

****** DATABASE DUMPS ******

The database dump will have to be done roughly every 17,000 scans. Log on to any account on the workstation. Make sure /opt/bin is in your path.

(1) Check the free space on the log segment for both databases using the command

> check_logs password

where password is the password for the Sybase root account. The log usage is reported in the following format:

Checking syslogs
The total number of data pages in this table is 1457.
*** NOTICE: Space used on the log segment is 2.85 Mbytes, 14.23%.
*** NOTICE: Space free on the log segment is 17.15 Mbytes, 85.77%.
Table has 52070 data rows.
DBCC execution completed. If DBCC printed error messages, contact a user with
System Administrator (SA) role.
Checking syslogs
The total number of data pages in this table is 18217.
*** NOTICE: Space used on the log segment is 35.58 Mbytes, 29.65%.
*** NOTICE: Space free on the log segment is 84.42 Mbytes, 70.35%.
Table has 172031 data rows.
DBCC execution completed. If DBCC printed error messages, contact a user with
System Administrator (SA) role.

The report for the log segment is also sent automatically each day by upload.csh which runs from the cron.

(2) When there is little free space left on the log device (logs for the second database will fill up first), dump both databases:

(a) Insert the tape labelled "Sybase database dump - Headers" into the DAT drive.

REMEMBER TO CYCLE BETWEEN TWO SETS OF TAPES THE TAPE DRIVE OCCASIONALLY EATS TAPES!

AND WRITE THE DATE ON THE TAPE SO YOU KNOW WHICH ONES WERE USED LAST.

(b) Execute the following command to dump the headers:

> dump_head password

where password is again the password for the root database account. If you get an error message saying that the backup server is not running, type

> start_backup_server

You will be prompted for the password of the sybase account on the workstation.

(d) Execute the following command to dump the channel data:

> dump_chan password

(end of included email from Darek Lis)

If the database dump doesn't work:

If the log channels log segment gets too full (i.e. the upload process came to a screeching halt) dump_chan will not be able to access the database. The only way I know how to deal with this is the following:

reboot the machine (nicely, not with the reset button) to get rid of the process that has it locked (killing the process doesn't work)
truncate the logs with
isql -U root -P <password> < /opt/bin/trunc_chan_nolog.sql
make a backup of the whole thing with (as root)
cd ~sybase
tar cvf /dev/nrst4 .
restart the upload process (you will be behind, otherwise you wouldn't be doing this in the first place - Darek says not to do this from the root account)
/export/home/sybase/cso/upload.csh
write 'database backup' and the date on the tape and put it in a safe place

Below:

Sometimes the copy process doesn't work right. This can happen for at least two reasons:

lapakahi's /export/home doesn't have enough free space. In this case it is necessary to free up some space
/user didn't get mounted right (this happens when the Alpha is down for any length of time). The remedy is to mount it.

The only other reason I know of why the upload process won't run is when the previous upload didn't finish (see above).

----------------------------------------------------------------------

back to CSO documentation page
back to CSO reference page

Maren Purves, maren@poliahu.submm.caltech.edu

Nov. 7, 1996