Shell Programming and Scripting

After a few hours the sync command indeed causes the uvsh process (The system has 24gb of ram). It has 8 uvsh processes that run at 50 percent each, sometimes 100 percent but rarely.

Ive only this to go on: As part of the recommended way of preparing the database for backup the sync command is issued. This is where I'm still stuck. This never completes although I know this worked before.

Do I chance backing up without the sync command?

> Removing the sync command had no effect, the processes commenced anyway. Its almost like the mere fact that I'm taring and transferring data is springing these processes.

I'm just guessing, but it seems a lot more likely that you shut down the database in preparation for doing the backup. But someone else tries to access the database, and that causes it to be restarted without knowing or caring whether or not you are trying to perform a backup.

That was my second thought as well: third party activity on the DB while trying to close it.
The sync behaviour seems a bit strange to me - usually sync in executed periodically by the syncer (BSD) process, periods being somewhere around 30 s. So why should there be so many dirty buffers? If having to do with the syncing, those uvsh processes should be heavily IO bound?

I don't have any experience with Redhat. I know that at one time, Solaris systems with a terabyte of memory relied on the buffer pool to increase performance and didn't sync regularly; it just flushed buffers when they timed out or were needed to make room for other active pages. At that time, a user-initiated sync could take an hour to complete on a busy system (and by the time it was done, there was a large new set of dirty pages). I don't remember if that "feature" was ever released to the public.

Do you have an indicator who is spawning those uvsh processes, e.g. a common parent PID? Might be the time to take a closer look at the uvsh program?