1748204 Members
3563 Online
108759 Solutions
New Discussion юеВ

mount option using JFS

 
SOLVED
Go to solution
Deepak Seth_1
Regular Advisor

mount option using JFS

We have on-line JFS product in our database server . Iam planning to use the following options to mount my file systems containing datafiles , indexes , redo log , archive logs etc.

mount -F vxfs -o delaylog,mincache=direct,convosync=direct,nodatainlog

While reading the archives , somebody was suggesting to mount only datafiles . I am confused now and needs your opinion.



10 REPLIES 10
harry d brown jr
Honored Contributor

Re: mount option using JFS

I think they meant don't place all of these on the same mount point or even the same disk or scsi chain:

datafiles ,indexes , redo log , archive logs etc...

Most importantly, seperate your these: Datafiles, indexes from the archive and redo logs.

live free or die

harry
Live Free or Die
A. Clay Stephenson
Acclaimed Contributor

Re: mount option using JFS

Hi:

I would use those option on data files and indices. I would fallback to the more conventional options delaylog, nodatainlog and thus use buffer cache for archive and redo logs.

If all your Oracle data is going to an array, I tend to put both data and indices in the same filesystem and put the archive and redo logs in a another and that's it. I know the DBA's have a heart attack when I do that but send it to the array and let it sort the plater stuff out. That's why I bought it. Now I do stripe each logical volume across multilple I/O channels. If I have three channels, each VG will consist of 3 equally sized LUN's and each LVOL within that VG will be stripped across all three LUN's. The idea is to get data in and out of the array as fast as possible. Doing it this way eliminates the guesswork involved in trying to figure out how busy any particular data file is and where I should put it.

My 3 cents, Clay
If it ain't broke, I can fix that.
Deepak Seth_1
Regular Advisor

Re: mount option using JFS

I agree with u suggestion but that is in our "to do task" . What about this option.

rw,nosuid,mincache=direct,convosync=direct,nodatainlog

and how it is differ from my previous mount option. Is it going to work for both datafiles and indexes as well.

Eugen Cocalea
Respected Contributor

Re: mount option using JFS

Hi,

I believe 'rw' is default. 'nosuid' won't let programs get other ids even if suid-ed.

Yes :)

E.
To Live Is To Learn
A. Clay Stephenson
Acclaimed Contributor
Solution

Re: mount option using JFS

Here is my suggestion:

Data files and indices:
rw,suid,delaylog,nodatainlog,convosync=direct,mincahce=direct

Archives and redo logs:
rw,suid,delaylog,nodatainlog

If you run the =direct options, you should probably greatly reduce your buffer cache and use the space for SGA buffers.
If it ain't broke, I can fix that.
Deshpande Prashant
Honored Contributor

Re: mount option using JFS

Hi Deepak
I would certainly use "datainlog, convosync=direct, mincahce=direct " for all oracle data/index files.

As far I know "datainlog" is default option and is faster in performance than "nodatainlog".

Take a look at following link for details on different options to mount related to VxFS

http://docs.hp.com/hpux/onlinedocs/B3929-90011/B3929-90011.html

Thanks.
Prashant.
Take it as it comes.
Deepak Seth_1
Regular Advisor

Re: mount option using JFS

Hi clay .
Here is qoute from JFS document.

"A nodatainlog mode file system should be approximately 50 percent slower than a standard mode VxFS file system for synchronous writes"

Any final thoughts of using nodatainlog v/s datainlog.

Deepak Seth_1
Regular Advisor

Re: mount option using JFS

thanx prashant for your reply. U now made me little nervous in using "nodatainlog" option. The JFS document did tell taht it is 50 % slower fo synv writes.
A. Clay Stephenson
Acclaimed Contributor

Re: mount option using JFS

Hi:

The nodatainlog is certainly true for most cases. The idea is that the filesystem changes AND the data is written to a log within the filesystem then then data is written into the filesystem blocks at a later time. This is great for integrity when filesystem internal values are changing - like new files being created or files removed or new blocks added to an existing files and the last written data in also in the log. In most cases, this is a good thing, we have to write to the log and while the head is correctly positioned we can write data to the log and return. The transfer to the actual file takes place a bit later. However, database file are pre-allocated; the filesystem doesn't need to be updated. Now ask yourself, how many times does the data get wriiten with nodatainlog - once. With datainlog - twice.

However, the real test is to simply change the mount options and measure; always ask the box about the best method.

If it ain't broke, I can fix that.