Sybase dumps taking longer

[Dave Jadischke]

Sybase dumps are taking 10 - 20 minutes longer. This started in July. The dump was exporting 7.7G to disk. Now in Oct the size is 8G.

Our normal processing has Sybase writing over the existing files. (This is now taking 20 minutes).

I changed the process slightly where I removed the files ahead of time and then let Sybase dump the file. I finished 12-15 minutes faster.

Why would removing a file then writing to it be faster than writing over the file?

Thanks in advance.

[harry d brown jr]

When you "write" over a file, it first has to release that space back to the system, before it can start writing.


live free or die

harry

[A. Clay Stephenson]

Hi Dave:

This is not quite a fair comparison. How long does the rm phase take?

When you overwrite an existing file the creat system call is invoked which in turn invokes the truncate system call. Truncate sets the file length to 0 and returns the space to the OS. It's more complicated if other processes have this file open.

[Dave Jadischke]

Let me add some additional info.

There are 7 files ranging from 800M to 1.3G in size. My test removed all 7 files earlier in the day then had Sybase recreate these files.

"Giving the space back to the OS" - So what is happening in the background.

Would I lose my 12-15 minute gain if the script removed the files first then started the dump?