Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

mincache=direct in Solaris 10 for VxFS

70 views
Skip to first unread message

underh20

unread,
Apr 20, 2010, 2:49:43 PM4/20/10
to
Hello,

Does anyone out there has experience in using "mincache=direct" in
Veritas File System on a Solaris 10 server running Oracle 11G ? Please
share the pros and cons of setting this parameter for all Oracle
database VxFS mount points at the system.

We've been advised that setting this parameter may help with the
performance issue. Our in-house scripts run fine and complete in
under 1 hour with Oracle 10G. However, they continue to run for hours
and not terminating. We had to manually kill the jobs.

Your help is greatly appreciated.

Bill

Richard B. Gilbert

unread,
Apr 20, 2010, 5:10:24 PM4/20/10
to

Your message is a little less than totally clear!

Please explain how your scripts "run fine and complete" and *also*

underh20

unread,
Apr 22, 2010, 1:02:16 PM4/22/10
to
On Apr 20, 2:10 pm, "Richard B. Gilbert" <rgilber...@comcast.net>
wrote:
> continue to run for hours and not terminating.- Hide quoted text -
>
> - Show quoted text -

These are in-house developed PL-SQL scripts. There are 12 of them. We
have number of processing centers
across the US. The scripts gather inputs from users and mainframe jobs
in each center and query
various tables in this 11G database. The data are then gathered as
processed output reports.
When it was 10G, all the scripts completed under 1 hour. However, when
it's running under 11G, they
are running for hours and not stopping. We have to manually killed
all 12 processes. There's no change
in the underlying tables and database schemes in 11G.

Any idea how we can improve the run time of the jobs ? We wonder if
using "mincache=direct" in Solaris 10 for VxFS Options would help.

Thanks,

Bill

Richard B. Gilbert

unread,
Apr 22, 2010, 4:01:57 PM4/22/10
to

How about killing the scripts sooner? ;-)

More seriously, I think you need a good Oracle DBA. There are good ways
and not so good ways to design your database. And then there are good
and not so good ways to update and/or query your database.

A good DBA should be able to troubleshoot your performance problems and
then to design and implement a solution.


Message has been deleted

Richard B. Gilbert

unread,
Apr 22, 2010, 6:04:08 PM4/22/10
to
Michael Vilain wrote:
> In article <KNmdnTNx5PqqNk3W...@giganews.com>,
> Just to add another voice here. The wrong person is trying to fix this
> problem by throwing a OS solution at an application problem. Fix the
> application FIRST. Hire an Oracle contractor to fix the database and
> scripts and get them running again. Tweaking Solaris won't get you much
> ROI. The oft-quoted number for system tuning and capacity planning is
> OS and hardware tweaks on an already properly configured system will
> gain you 10% improvement at best. If your hardware is underpowered for
> 11G (e.g. you need more memory or spindles), that's different. Look at
> the queries and table layout first.
>
> Hire someone to fix this. Seriously. You're in over your head and
> don't know it.
>

Right on!

To every system comes the time to put it out to pasture. If your system
is well tuned and is using 90% or more of the available CPU, put the
poor thing out of its misery!

I've been through this process a few times in my career. Most recently
I replaced a pair of aging Alpha 4100s with a pair of ES40s. The
feeling of relief was fantastic! Instead of 90+ percent, CPU
utilization dropped to something like 40%. Response was, once again,
snappy!

The 4100's were retained to handle testing and training, the old testing
and training machine was given to the developers . . . .

przemol

unread,
Apr 23, 2010, 12:20:32 PM4/23/10
to

Hi Bill,

we use mincache=dicrect,conosync=direct and indeed this is much faster
then
other options (in OLTP environment). But recently we are switching to
vxfs mounted without this options
(so it seems that they are mounted with cache - and they are) but turn
on direct access on Oracle
side using filesystemio_options=setall setting. It means that Oracle
decides which files should be used
with direct options and which shouldn't.

Regards
Przemyslaw Bak (przemol)
http://przemol.blogspot.com

0 new messages