This content has been marked as final. Show 63 replies
You and I both know that you are a poser, admit it.
Senior Oracle DBA
Even your idol, Jonathan Lewis has called you wrong with your nonsense about blocksizes.
"It will NOT benefit performance. There will be less I/O, but blocks
will be bigger: the number of bytes being read will be identical.
This has been recently concluded from a post by Don Burleson on OTN,
promoting bigger blocksizes, which was exposed by Jonathan Lewis and
Richard Foote as an incorrect assertion.
Senior Oracle DBA
Sybrand, your observation is incorrect."
Why did you repeat incorrect myths, after being noted as wrong by Lewis? Are you now pretending to know more about it than he does? (Hey, maybe you do, who knows? Neither of you want anybody to know your training and verifiable experience . . . )
Some "Senior Oracle DBA" you are, spreading myths and insulting people's race.
Just where do you get-off calling Indian people "monkey's"?
Sybrand published: "There will be a day when they simply dump the Dutch support group and have everything answered by cover your (profane word removed) trained monkeys from India."
Message was edited by:
Anyone who can read English knows that a TPC benchmark is a fully reproduceable test of database performance.
Do you actually know what the TPC benchmarks are?
Let me guess, you are against evidence, right?
Why do you hide behind a veil of total anonymity? What are you afraid that people will learn about your experience and training in Oracle?
Why don't you stop spreading your misinformation?
Would you PLEASE look in the mirror and notice how often you published scripts which simply don't WORK.
Your book ' HIGH PERFORMANCE TUNING WITH STATSPACK' is LOADED with them.
You and I both know you are a FRAUD, admit it.
Also do I really need to republish here links to your FLAMEWARS with Tom Kyte, Jonathan Lewis etc, which YOU always started when YOU stood CORRECTED.
Why don't you retire? You have RIPPED OFF more than enough people with incorrect and unprofessional advice. Oh, I forgot, it is this VERY ADVICE (which never CURES anything) which keeps you going!
Senior Oracle DBA
Another myth. Got any evidence?
You may get some advantages by changing your blocksize or including multiple blocksizes but it will be pretty minimal
Sorry that should read, your top wait is db file sequential read, and 6 of your top ten waits appear to be cluster/interconnect releated you have bigger problems than your block size, on a guess i would say the application select from and updates a set of small tables frequently but without seeing it in action its hard to tell. It would be nice to know if this application was previously running on a single instance but the OP has probably left the building as the bun fight commenced.
TPC performance bench marks use all kind of wierd and wackey settings, as they are a well understood workload and only have to run for a short period of time pretty much anything goes I wouldn't base my configuration on whats done in TPC anymore than strap a jetengine to my car to make it go faster but all the recent land spped records use jet engines maybee we should phone Ford..
also I think you linked to the wrong document as the parameter file at http://www.dba-oracle.com/t_tpc_h_data_warehouse_benchmark.htm doesn't contain anything relating to multiple blocksizes.
You are so keen to publish everything related to sybrand that is outside oracle forum. let us also review yours, what ya say hand in hand? right
Just wanted to let you know that I appreciate your website and the services you provide to the Oracle community. It seems that there has been a lot of Tom bashing from Don and company for no good reasons.
I think thats the important bit. I am sure there are lots of time when Don goes to rescue a project when its in complete mess. He uses some tricks to solve the problem quickly , tricks that he has learnt by experience by fixing similar problems in the past. I dont see anything wrong with that. That should buy him some time to analyse a few things like
Has it actually fixed the problem?( You have to isolate the actual problem to determine this) Has it created some other problems?( You need to know what could go wrong with the approach) Is it a temporary fix?
BTW, (and no offense meant) don't you think $250 worth of Tuning books (probably authored by yourself) is kinda little low a price? How about a copy of "Expert one-on-one"?
Messages to Donald and Mike: Don, stick to tiny horses; Mike, stick to scuba diving. You are both literally poisoning the Oracle job market. Your book is a hazard, not a help.
What do we have here? I think someone has been hiding secrets
Yikes, I missed that it was RAC, thanks!
your top ten waits appear to be cluster/interconnect releated
I have evidence that RAC likes smaller blocks:
Yes! Good point. There are millions of dollars of sales at stake in these benchmarks and the vendors spend a small forture testing and re-testing to get the fastest performance. Personally, I use the TPC benchmarks to find "hidden" kernel parms and other performance tricks. Why re-invent the wheel?
TPC performance bench marks use all kind of wierd and wackey settings
Oops, my bad. That was a link on the benefits of a large blocksize, sorry. Here are my notes on multiple blocksizes:
I think you linked to the wrong document
It is tempting to configure RAC with large data buffers. However, we must remember that multi-instance Oracle is very different from a single-instance system:
Blade clusters have small buffer caches – Most blade servers have only 2-gig or 4-gig of RAM. Hence, each RAC node is limited in the available db_cache_size.
RAC likes small blocksizes – Because of the inter-instances block transfer via Cache Fusion, smaller block sizes minimize pinging of blocks between instances. Most RAC DBA’s will define the default db_block_buffers to 2k and then add a 4k buffer ton isolate data objects.
RAC scales by the sum of RAM caches – Unlike a single Oracle database with a 32 gigabyte RAM data cache, RAC system achieve high caching by the sum of the individual RAM caches. Hence, a 64 node RAC cluster with a 2 gigabyte RAM cache on each node would effectively have a total cache of 128 gigabytes.
'Most RAC DBA's' "
Please quantify 'Most'. Did you conduct a poll?
Or do you simply mean 'I'
Please stop generalizing, Burleson. You don't have a clue how many DBA's do that.
Please stand up for your own recommendations!!!
Also : a 64 node RAC cluster. What is that? 10g allows 32 nodes!!!
Senior Oracle DBA
Only 7 posts, you must have created this ID just for me, I'm flattered!
Yes, but it's not about the money.
BTW, (and no offense meant) don't you think $250 worth of Tuning books (probably authored by yourself) is kinda little low a price?
Rampant sells some books below-cost, just to get the information out
Also, Rampant books are re-printed overseas for sale to developing countries for just a few rupees. Other Oracle publishers don't do that. They are all-about the money . . . .
Yes, in the hands of the inept, unqualified and reckless, I agree, they can be very hazardous.
Your book is a hazard, not a help.
I try to put disclaimers that they are only for experienced experts, but I cannot prevent dolts from buying them . . . .
"WARNING - This poster is not suitable for beginners. It is designed for senior Oracle DBAs and required knowledge of Oracle data dictionary internal structures."
Any ideas on ways to keep advanced books out of the hands of the inexperienced DBA?
You aren't serious, are you?
In the Rampant book on disk I/O the author manages to mention SAME not even ONCE.
It's all about Solid State Disks!
In your own 'High Performance Tuning with Statspack' not 1 (ONE) of the scripts you published work, when you don't have consecutive snapshot ids (which is always true in RAC)
Your books may serve as an expensive monitorstand. Nothing more, nothing less.
Senior Oracle DBA
Don: I have only ever "played" with using multiple blocksizes - i.e. not done a lot of in-depth testing. However, I found that some tables and indexes (usually related) DID show improved response times; then again, others did not (a few were actually worse). So, this approach does seem to warrant site-specific investigation.
I'm fairly certain that other vendors have their own versions of multiple blocksizes. Any idea (or does anyone else have any idea) why Oracle haven't taken steps to make fuller use of multiple blocksizes, other than for transportable tablespaces?