Sync function call - man page prompts question!

[Eric Yruegas]

Hi all!

The manpage for sync states the following:
"In some HP-UX systems, sync() may be reduced to a no-op. This is
permissible on a system which does not cache buffers, or in a system
that in some way ensures that the disks are always in a consistent
state."

Does anyone know what setups might fulfill those scenarios? We want to run sync/sync/sync right before we split a business-copy of some database disks, in order to flush anything that may be pending since we are using "delaylog" on those filesystems.

How can we tell when the system reduces the sync() call to a no-op?

Thanks in advance for any guidance...

-Eric

[Hein van den Heuvel]

Just call it already!

No harm done if it is redundant.

>> a business-copy of some database disks

Sync can only flush through what was hand to the OS. Right? The database however might (will!) be holding on to 'dirty' data pages, so you can sync all you want, but if the db has not given the data to the os, it makes no difference.

Of course and self respecting DB will have made sure to flush out enough data to (redo/journal/log) files to make sure the commited data can be recovered, but that recovery may take longer than needed.

So first and foremost you need to checkpoint the database, and then optionally sync to the disk.

Which database?

Cheers,
Hein.

[Sandman!]

Imho by using the character interface aka raw device special file for storing the data instead of putting it on a filesystem. The raw interface bypasses the buffer cache so a sync operation would become a NOP.

[James R. Ferguson · Accepted solution]

Hi Eric:

Using OnlineJFS and 'mincache=direct' means that the filesystem so mounted bypasses the UNIX buffer cache.

Regards!

...JRF...

[Eric Yruegas]

Database is Oracle, of course. And yes, for datafiles, I understand that the DB files will likely always be dirty when splitting a hot DB.

I'm just trying to mitigate a risk we've encountered where we having a copy of the DB control file written to one of the database directories, and the split happened as that process was executing - ended up with an unreferenced inode.

[Sandman!]

You should look into buying a solid state disk (SSD). It is akin to keeping all the data memory resident. So there's no performance hit associated with writing to a slow device like an electromechanical disk drive. You can read its pros / cons in the whitepaper below:

http://docs.hp.com/en/145/diskwp2.pdf

...and also in these forum discussions:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=768101&admit=-682735245+1194553897225+28353475

http://forums1.itrc.hp.com/service/forums/questionanswer.do?admit=716493758+1103577549963+28353475&threadId=134174