- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: Tuning a Monster
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-28-2003 09:04 AM
тАО03-28-2003 09:04 AM
I have attached a kmtune output from a soon to be production RP7400 8X750Mhz 16GB Memory. The I/O is dual channeled through a McData 1GB switch running powerpath. The disk attached is right at 1TB, hardware striped, 1MB stripe depth. The RDBMS is 9ias. OS block size 8K, 16K Database block size.
Any input would be appreciated.
My concern is dbc_max_pct. Can you give me any other hints?
Thanks in advance.
RZ
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-28-2003 09:09 AM
тАО03-28-2003 09:09 AM
SolutionEnjoy, have FUN! H.Merijn
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-28-2003 09:12 AM
тАО03-28-2003 09:12 AM
Re: Tuning a Monster
Absolutely - you don't want dbc_max_pct at 50%. Don't think you'll EVER need 8GB of disk buffer. Depending on how the Oracle SGA is configured & what the mount options will be for the Oracle extents, you may be able to get away with
dbc_min_pct => 2
dbc_max_pct => 5
That still gives you between 320 & 800 MB for buffering.
Did they give you JUST one LUN for ALL of Oracle? I'd definitely not like that.
My $0.02,
Jeff
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-28-2003 09:14 AM
тАО03-28-2003 09:14 AM
Re: Tuning a Monster
With a 'dbc_max_pct' value of 50, and 16GB of memory, the Unix buffer cache could theoretically approach 8GB. I doubt you want that. The poor 'syncer' daemon is probably running like mad every 30-seconds! I'd suggest a much more conservative value like <2> for 'dbc_min_pct' and <5> for 'dbc_max_pct' assuming RDBMS is buffering and assuming VxFS mount options that bypass the Unix buffer cache.
Regards!
...JRF...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-28-2003 09:15 AM
тАО03-28-2003 09:15 AM
Re: Tuning a Monster
dbc_max_pct. No doubt about it. Since you have both nbuf and bufpages set to 0, dbc will play a role here.
Since you have 16GB, I would say start with dbc_max_pct=2 and dbc_min_pct=2.
-Sri
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-28-2003 09:18 AM
тАО03-28-2003 09:18 AM
Re: Tuning a Monster
SQL*Plus: Release 9.2.0.2.0 - Production on Fri Mar 28 11:15:20 2003
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
SQL> connect /as sysdba
Connected.
SQL> show sga
Total System Global Area 1009561320 bytes
Fixed Size 737000 bytes
Variable Size 167772160 bytes
Database Buffers 838860800 bytes
Redo Buffers 2191360 bytes
SQL>
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-28-2003 09:19 AM
тАО03-28-2003 09:19 AM
Re: Tuning a Monster
I would also reduce massiz_64bit; any code that needs that much stack space requires very serious programmer adjustment (with a ball-peen hammer - 128MB should be a gracious plenty).
I would also reduce ninode to no more than 1000 or so - this paramter only applies to hfs filesystems and you almost certainly have one one - /stand.
Your shared memory could bprobably be bumped up as Oracle likes very large SGA's.
Some of your msgxxx and semxxx
values look small; check for Oracle suggested values.
Let nobody persuade you that setting timeslice to a small value (e.g. 1) is a good idea. Leave it at 10.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-28-2003 09:49 AM
тАО03-28-2003 09:49 AM
Re: Tuning a Monster
There are 4 metas involved.
JRF,
Could you please expound a bit on mount options?
I have attached current fstab.
Regards,
RZ
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-28-2003 09:57 AM
тАО03-28-2003 09:57 AM
Re: Tuning a Monster
what about a statspack report?
let's see what a 15 minutes interval, during high load, gives for this monster.
regards
Yogeeraj
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-28-2003 10:00 AM
тАО03-28-2003 10:00 AM
Re: Tuning a Monster
Thanks