Oracle 10g Impact

[Indira Aramandla]

Sorry here it is.

[Yogeeraj_1]

hi steven,

you should consider raising the value of swap to at least a one to one ratio since your physical memory is at 4 GB.

With less memory you may have to raise it to a 3 to 1 ratio of swap to physical memory.

hope this helps!
regards
Yogeeraj

[Yogeeraj_1]

hi again,

also consider running the Pre-install checks as recommended by metalink note: 283731.1

In fact, Oracle Support has a flexible and reliable method of performing health checks on Oracle products and host environment.

Amongst the several tests, there are the following:
* OS certified?
* /tmp adequate?
* Swap (in Mb)
* RAM (in Mb)
* SwapToRAM OK?
* Disk Space OK?
* Kernel params OK?
* Links and libs OK?
* ulimits OK?
* User in /etc/passwd?
* Got OS packages?
* Got OS patches?
* Other OUI up?
* Group in /etc/group?
* Umask set to 022?
* LDLIBRARYPATH unset?
* SHLIB_PATH unset?

hope this helps!
regards
Yogeeraj

[Eric Antunes]

Hi Steven,

I'm realy impressed with your SGA! What are this huge 1.6Gb amount for? What values do you have for the following init.ora parameters?

db_block_buffers = ?
shared_pool_size = ?

Best Regards,

Eric

[Eric Antunes]

If you want to see what SGA you are efectively using, run the following query:

select name, bytes/1024/1024 "Free Size in MB"
from v$sgastat
where name='free memory';

Large unused space in the Shared Pool increase the probability of latch contention...

Eric

[Yogeeraj_1]

hi,

i think Eric's query missed the pool column ;)

it should rather be:
e.g.
yogeeraj@MYDB.MU> r
1 select pool, name, bytes/1024/1024 "Free Size in MB"
2 from v$sgastat
3* where name='free memory'

POOL NAME Free Size in MB
___________ __________________________ _______________
shared pool free memory 25.8043671
large pool free memory .5859375
java pool free memory 19.6132813

Elapsed: 00:00:00.01
yogeeraj@MYDB.MU>


regards
yogeeraj

[Hein van den Heuvel]

I would be less worried about problems, memory overload then most replies to so far suggest.
This upgrade is first and foremost an opportunity for increased performance.
Oracle has learned a lot over those years and has implemented lots of tools to help you, not to hurt you.
The system tuning will be minor concern compared to the other potential impacts.

As Inidira and others suggest, please make a serious attempt to collect a performance baseline while you are still using 8.1.7.
This would consist of
- a statspack output, and sar collection for a critical procution window in the day (perhaps 9am - 11am, or 2am - 4am, whatever your business dictates, and for an entire 'typical' day.
- Acknowledge that there is not typical, and that loads will change, and thus you should alss make an attempt to capture a repeatable benhcmark job, typically a heavy report that can be run over and over, but hopefully also a tasks the updates and inserts. Normalize the output with 'business elements processed' (customers? orders? phonecalls?...)

Typcially the 8.1.7. setup is still sort of locked into the past.
Explore and exploit the new opportunities:
o Rule based optimized ---> Cost based (but you need stats to make that work, and be sure to check execution plans for hot queries.
o Dictionary managed tablespaces --> locally managed (pre-define before import)
o Rollback segment --> Automatic undo
o Consider multiple pages sizes / sga pools?
o Static sort area --> pga aggregate target
o dynamic sql --> check out cursor_sharing = similar
o and on and on...


OS tuning will be a minor tweak in the end!

Embrace, Enjoy!
Hope this helps some,

Hein.