ABS_CATLG_00001 process

[Trace Trembath]

Good afternoon,

Could someone please tell me where the above ABS process comes from? It's a detached process running on my system occasionally (usually Sundays) and I'm not sure what is starting it and if it can be turned off. It causes quite a lot of direct I/O usage on my system. I thought it might be the abs_clean_catlg batch job, but that batch job doesn't seem to take very long to complete.

I do all of my restores without using the ABS catalog and so I don't think I really need this process.

Any help with this is greatly appreciated.

Our ABS version is: 4.2 (617)

Thank you.

Regards,
Trace

[EdgarZamora_1]

It's been a while since I used ABS and I can't remember what that process is. I thought maybe it's the cleanup process, but you already mentioned it's not the cleanup job. Have you tried doing an MDMS SHOW SCHEDULE to try and find what is running at that time?

[Guenther Froehlin]

This is a process which loads the catalog entries from a staging catalog file into the ABS catalog.

Search your ABS save logs for that process name and you'll see where/when it was created.

You can setup a catalog so that it uses "staging". This supposedly speeds up the save operation in that the ABS coordinator writes catalog entries to a sequential staging file instead of the index-sequential ABS catalog files.

Once a save has completed a detached process is created to add the records from the staging file to the catalog. Depending on how many files have been saved this could take anywhere from a few minutes to an hour or so.

/Guenther

[Trace Trembath]

Thank you for your replies. However,

MDMS show/schedule just seems to show that last scheduled time of all of the backup streams. I don't see anything about an abs_catlg_0000n process. But thanks anyway.

I did a search in abs$log:*.log for abs_catlg, but it did not find anything.

As mentioned, I'm sure this has to do with ABS's staging processing. My catalog is set up to use staging as shown.

$ mdms show catalog/full sray_catalog

Catalog Name: SRAY_CATALOG
Catalog Node: SRAY7
Access Control: NONE
Directory: ABS$ROOT:[CATALOG]
Last Cleaned: 01-OCT-2007 12:30:02
Owner: ABS
Staging : YES
Type: DISKS

It would be good to know exactly what kicks off the abs_catlg_0000n process and why. I am thinking that I don't need it at all since I never do any restores using the abs catalog anyway.

Thanks for your help.

Regards,
Trace

[EdgarZamora_1]

>It would be good to know exactly what kicks
>off the abs_catlg_0000n process and why. I
>am thinking that I don't need it at all
>since I never do any restores using the abs
>catalog anyway.

When you have staging turned on a sequential file is created containing all the filenames backed up. This speeds up the backup job since while your backup job is running it doesn't update the catalog (indexed file). When your backup job ends the detached process is kicked off to read that sequential file and insert the entries into the catalog.

You can turn off the staging which will cause your backup jobs to run longer (because they will be updating the catalog directly) but you won't have the detached process afterwards. Either way, the catalog WILL get updated. Staging IS recommended by HP.

I think I got that right, Guenther can correct me if I'm wrong.

[Trace Trembath]

Is there no way to turn off this cataloging process, even if I never use it? This cataloging process spends hours at a time as the top direct I/O process and my Oracle DBA is insisting that it is slowing down some of his processing.

Is there even a way to change the scheduling of this process and/or lower its priority?

Thanks.

Regards,
Trace

[Robert_Boyd]

Trace,

You can modify the priority of these processes by at least a couple of mechanisms.

The easiest of these is to add something to the LOGIN.COM for the ABS user account to detect that the process is a catalog process. Then drop the priority of the process to 0 or 1.

Here's a line that I have in our local SYS$SYLOGIN on all of the ABS master/client nodes:

$! Define Symbols for ABS
$ if username.eqs."ABS" .and. F$TRNLNM("ABS_LOCAL").nes."" then $ @ABS_LOCAL:ABS_SYLOGIN

ABS_LOCAL gets defined at system startup in the ABS$SYSTARTUP.COM procedure. Here's an extract of the part of the procedure that does this:

$ DEFSYS ABS_LOCAL ABS$ROOT:[LOCAL]
$ call CREATE_DIR ABS_LOCAL
$!
$ IF VERIFY .EQ. 1 THEN SET VERIFY
$ EXIT !
$CREATE_DIR: subroutine
$ dir_name = p1
$ if f$parse(dir_name).eqs."" then -
$ create/directory 'dir_name'/owner=ABS
$ endsubroutine

Here's the contents of my ABS_SYLOGIN:

$!
$! TARGET_INCLUDE = BACKUP_CONTROL_TARGETS.COM
$!
$ set noon
$
$ if f$trnlnm("ABS_LOCAL").nes.""
$ then
$ @abs_local:daily_parameters
$ endif
$
$ if f$search("TOOLS$DIR:BATCH_LOG_FILE_CLEANUP.COM;").nes."" then -
$ @TOOLS$DIR:BATCH_LOG_FILE_CLEANUP 7 14 Today-32-0:
$!
$ SET RMS/BUFFER_COUNT=124/MAGTAPE
$


You can easily add some code to detect the process name and see if it starts with ABS_CATLG_ ... if so drop the priority.

Best wishes,

Robert

[EdgarZamora_1]

> Is there no way to turn off this cataloging process, even if I never use it?

I no longer have ABS so I can't test it. I'm not sure there's a way to turn off cataloging but if there were it would probably be in the ARCHIVE. Try something like MDMS SET ARCHIVE archive_name /CATALOG=NAME=""

You could even create a test archive and test catalog to try these out. I'm thinking that might work because DISASTER_RECOVERY has no catalog, but I've never tried running ABS without a catalog. Good luck.

[Trace Trembath]

Thank you for your replies.

Robert, I'm wondering what version of ABS you're running. It might be newer than mine because I can't find an ABS "LOCAL" directory and the procedure daily_parameters doesn't seem to exist.

Also, ABS doesn't allow me to blank out the catalog name; (Maybe I have the syntax wrong.)

$ mdms set archive arch_backups_sray5/catalog=name=""
%CLI-W-VALREQ, missing qualifier or keyword value - supply all required values
$mdms set archive arch_backups_sray5/catalog=(name="")
%CLI-W-VALREQ, missing qualifier or keyword value - supply all required values
$

I'm also not sure what the consequences would be of runnng with a blank catalog name.

Regards,
Trace

[EdgarZamora_1]

I don't have the ability to try out the commands so I apologize. Try

mdms set archive archive_name /catalog=(name="",nonodes)

[Guenther Froehlin · Accepted solution]

Hold on! This catalog is of type DISKS. There's only very minimal amount of data produced in the staging file. Not worth to even have staging enabled. Turn it off with:

$ MDMS SET CATALOG SRAY_CATALOG/NOSTAGING

It should not even allow staging for a DISK type catalog. That should be changed...but not by me anymore.

The ABS_CATLG_nnnn processes are created (with $CREPRC) at the end of the save operation by the ABS coordinator process and not through MDMS' scheduling feature.

One of the SAVE logfiles should contain the log for creating ABS_CATLG_00001. Maybe this is not for a SAVE using CATALOG SRAY_CATALOG?

Use SDA SHOW PROCESS/CHANNEL on this process and look for a .DAT and .LOG file it has open. It may give more information on what this process is doing.

You cannot have a SAVE/ARCHIVE without a CATALOG. In case of catalog type DISKS only the save set information is stored in the catalog...no individual infromation of files saved. This catalog type produces very small catalog files.

/Guenther

[Guenther Froehlin]

This is how the staging info looks in a SAVE log:

00:22:15 COORD: Staging process PID : 20403E01
00:22:15 COORD: Staging catalog : ABS$CATALOG:1MONTH_99_1.STG;1
00:22:15 COORD: Staging procedure : ABS$CATALOG:1MONTH_99_1_1.COM;1
00:22:15 COORD: Staging logfile : ABS$LOG:1MONTH_99_1.LOG
00:22:31 THREAD #1: Normal successful completion

You get the PID of the process and not the name. Sorry my memory has fainted a bit on ABS...

/Guenther

[Trace Trembath]

Thank you Guenther.

I've searched all of my ABS log files and I don't see any of them that have a reference to abs_catlg. I do see in the save request log files where the staging process is kicked off though.

What confuses me most is what this abs_catlg_0000n process is doing for hours at at time. If I'm using a catalog of type disks, then shouldn't any catlog processing take mere seconds/minutes to complete?

The abs_catlg process appears to be happening on Sunday mornings, so I will watch for it then and see what SDA can tell me if I can catch it running.

Thanks.

Regards,
Trace

[Trace Trembath]

I think I might have found something. I do have one save request that runs on Sunday mornings. It's call drp_backup and it uses the default ABS catalog. It only backs up the system/ABS and a secondary system disks.

$mdms show catalog/full abs_catalog

Catalog Name: ABS_CATALOG
Catalog Node: SRAY7
Access Control: NONE
Directory: ABS$ROOT:[CATALOG]
Last Cleaned: 02-OCT-2007 12:30:01
Owner: ABS
Staging : YES
Type: FILES

This must be kicking off the abs_catlg process. However, the log files for the staging process only take a few minutes to complete.

I'm sure I'm getting close now. Thanks Guenther!

Regards,
Trace

[Robert_Boyd]

Trace,

The ABS_LOCAL directory and all of its contents are things that I set up. It does not come standard with the ABS install.

I found that I wanted to put a number of ABS related command procedures such as login, environment prologue and epilogue procedures, monthly catalog tuning procedures, etc ... all in one place but NOT in the standard ABS directories. That way I can easily maintain my own procedures without worrying that an ABS software update will stomp on them.

If you want to know more about the procedures that I use to do maintenance on ABS, let me know.

Cheers,
Robert

[Robert_Boyd]

Trace,

I'm using ABS V4.4(901). The help text on catalog configuration claims that STAGING is not even used on DISK type catalogs since no information about individual files is stored in these catalogs.

You might want to go through all of your catalogs and look at the settings to make sure that they are all the types you think they are(or not).

Also, have you ever done any tuning of your catalogs? If not, you could be having excessive IO activity because they need to be tuned.

This is an area that I've never been impressed with the out of the box tools they give you with ABS. If you want assistance with attempting a tune-up of all your catalogs I can try to help out with some DCL that you could adapt to your environment.

Robert

[Trace Trembath]

Hi Robert,

I think my problem is that I have 1 save request that's still using the default catalog of abs_catalog, which is of type files. I think I can either tune the abs_catalog catalog, or switch that backup to use my sray_catalog catalogk, which is of type disk.

I'd be interested in your tuning procedures if you don't mind sending them to me at trace.trembath@shell.com

Thanks!

Regards,
Trace

[Guenther Froehlin]

If this ABS_CATLG_nnn process runs for 24 hours and still shows activity then I would expect a bug somewhere.

If you don't want to do specific file restores for these disks then it should use a DISKS type catalog. Otherwise I would assign the SAVE/ARCHIVE to a newly created FILES type catalog.

I've seen a couple of cases where the default ABS catalog files were 50GB+ in size without a CONVERT done for a long time. That has some performance impact on inserts but also on the ABS Catalog Cleanup job.

I always setup our devo cluster SAVEs with individual ARCHIVEs and catalogs - all starting with the same name for easy recognition.

That makes the catalogs (size) more manageable for regular CONVERTs and the catalog cleanup runs faster. I did no other tuning because catalog performance was acceptable with this setup.

/Guenther