We have an issue where a file is entering delta at night from the butil command (and exiting/merging the next morning) without any direct issue. However, several incidentl delta files have been created. Numerous are 0k... but several are the same date/time as the live file (.^01 - .^04) and are the same size as the live file. Butil has ended, and no .^^^ exists, but these files keep updating in size.

You can see a screenshot of the directory and files here:http://www.bsitpa.com/images/delta.jpg

I am unsure as to what to do, as restarting the server has not merged these files together. And I am unsure of the ramifications of moving these files or deleting them. Any information would prove helpful at this point.

Thanks!

Tori

Hi, Tori,The files "^01 - ^04" aren't delta files, but are actually "extended" files, i.e. segments created when the active file reaches approximately 2Gbs. The only consideration you must give these extended files, is to keep them in the same directory with the active file with which they correspond. If the active file and its extensions aren't kept together, a Btrieve Status 13 will result. Otherwise, treat the active file and all of its extensions exactly the same as you would treat a single active file. Regards, Steve

Yes. And we have some legitimate files that do just that. The issue here is that this file? Hasn't reached 2gigs yet. It's still 500mb away. And it doesn't explain the multiple versions of the same size with different enumeration.

Look at the screenshot and you will see what i mean.

.t

That does not look too promising.
As Steve indicated those are not "delta" files for continuous operations / backups but rather different physical parts of the one logical file.
As you indicate they are not on the order of ~2GB as is typical but are much smaller, some coming in at 0 bytes.

The short answer is that the database engine will split a file early if it gets a "file full" status code back from the OS. BTW the OS does not actually have a "file full" so this is actually a "disk full" status that is returned. This behavior is unfortunately not uncommon if you run out of disk space. I see you blocked out the disk space status in the screenshot...

Yeah. I blocked it out just on habit... however, the original image shows 20.9 gb of free space. so i don't think that's it.

So... for my edification, this has NOTHING to do with BUTIL then?

They should not have anything to do with butil.
As Steve and I indicated they are different physical parts of the one logical data file not backup / continuous operations related.

Unfortunately what I left out of my previous post is the file is in a strange state.
I would make a backup of it and rebuild it (and any others with 0 byte parts) as quickly as possible. That is unless you believe the reported file size is not the true file size and they are all 2GB - 1 page size except for the one last part which may not have grown to the normal 2GB split point yet.

While currently 20GB+ free is there any chance that at one time it did run out? Two extra copies of this directory alone on the volume would have run it out. Once the size is set all the following segments turn out the same size.
Alternate to actually running out of disk space would be anything else that would return a "disk full" to the database engine. I suspect that if quotas are enabled that it would be possible but I have never actually seen that since the database engine runs as the built in local SYSTEM account by default.
And while I have seen AV software change OS return codes it is usually permissions not a disk full status but I suppose it would be just as possible to prevent a disk write.

We've seen this behaviour as well at a customer site and have been thinking the same things. I believe that Disk Full and quota limits are not the source of this problem since both of them would also prohibit you to create the extension file.

The file should be okay if you rebuild it.

 Is there anything suspicious in pvsw.log?