Simpler Navigation for Servers and Operating Systems
Completed: a much simpler Servers and Operating Systems section of the Community. We combined many of the older boards, so you won't have to click through so many levels to get at the information you need. Check the consolidated boards here as many sub-forums are now single boards.
Showing results for 
Search instead for 
Did you mean: 

Sybase dumps taking longer

Dave Jadischke
Occasional Advisor

Sybase dumps taking longer

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
Honored Contributor

Re: Sybase dumps taking longer

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

Live Free or Die
A. Clay Stephenson
Acclaimed Contributor

Re: Sybase dumps taking longer

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.

If it ain't broke, I can fix that.
Dave Jadischke
Occasional Advisor

Re: Sybase dumps taking longer

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?