[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::dbms

Title:	VAX DBMS
Notice:	THIS NOTESFILE IS NOT A FORMAL SUPPORT CHANNEL
Moderator:	SCARY::CHARLAND

Created:	Thu Feb 20 1986
Last Modified:	Tue Jun 03 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	2642
Total number of notes:	11044

2615.0. "backup hangs if target dev full w/ /EXTEND" by M5::JAKUHN (jakuhn@us.oracle.com) Wed Apr 09 1997 17:41

Are you aware of any problems in DBMS v6.1A (not v6.1A-1) where the backup
process hangs if the target device is full?  The site is running VMS v5.5-2
and
DBMS v6.1A.  This problem was not occurring in DBMS v5.1-1, but we have changed
the backup procedures -- the only difference is the backup command is the
addition of the "/EXTEND=3D20000" qualifier.

If you repeatedly do a "show device", the device will sometimes show 0 blocks
free and other times show a few thousand blocks free.

The backup command that they are  using is:

$ DBO/BACKUP/MULTI /LOG/EXTEND=3D20000/ONLINE <root-file> <backup_filespec>.
They also issue a "$ SET RMS/BLOCKS=3D127/EXTEND=3D20000 *before* the backup 
starts.

I did not see any mention of this problem in the release notes for V6.1A-1 or
V7.0 -- so I wonder if it may be a problem in V6.1A-1 and v7.0 as well.

    jay kuhn

T.R	Title	User	Personal Name	Date	Lines
2615.1		DUCATI::LASTOVICA	Is it possible to be totally partial?	`Wed Apr 09 1997 17:58`	4
	/EXTEND=3D20000 would seem to be illegal. Perhaps it is /EXTEND=20000? In any case, I'm not sure what it should do, but it should not 'hang'. Can you reproduce the behaviour in-house?
2615.2		M5::JAKUHN	jakuhn@us.oracle.com	`Wed Apr 09 1997 20:43`	1
	sorry, it's /extend=20000
2615.3		ORAREP::AUSS::GARSON	DECcharity Program Office	`Wed Apr 09 1997 22:36`	6
	re .1 >/EXTEND=3D20000 would seem to be illegal. Perhaps it ^^^ Just the usual (tedious) quoted-printable mail encoding.
2615.4	I wanted him to think about it! :-)	hotrdb.us.oracle.com::LASTOVICA	Can you be a closet claustrophobic?	`Thu Apr 10 1997 04:20`	4
	> Just the usual (tedious) quoted-printable mail encoding. d'on worry - I knew that. It was just a minor prelude to asking Jay to reproduce the problem in-house.
2615.5	Very old problem	ukvms3.uk.oracle.com::PJACKSON	Oracle UK Rdb Support	`Thu Apr 10 1997 08:29`	12
	If you use a very large extent and there isn't enough space available on the disk, your process can appear to hang. What happens is that if RMS can not allocate the full extent, it drops back to allocating the space in very small units (disk cluster size IIRC). This can take 100 times longer than normal. The work that is being done is not charged against your process by VMS so it appears to hang, but if you wait long enough it will complete (possibly with an error if there is really not enough space). I tested this using DBMS V3.?, but I doubt that it has changed. Peter
2615.6	thanks && 1 more question...i hope	M5::JAKUHN	jakuhn@us.oracle.com	`Fri Apr 11 1997 19:04`	4
	thank you very much Peter. I really appreciate the explanation. This is not really a "bug" kinda thing, its just "how it works"? jay
2615.7		ukvms3.uk.oracle.com::PJACKSON	Oracle UK Rdb Support	`Mon Apr 14 1997 09:24`	6
	> This is not really a "bug" kinda thing, its just "how it works"? Well, I found it in the VMS (V4) documentation about how file extents are done. Peter