Who, me? Perish the thought! You must have had someone else in mind. For instance I would never dream of reminding you about your typing error in pctincrease=0 ;)Quote:
Originally posted by slimdave
.... demolish and ridicule my answer.
Printable View
Who, me? Perish the thought! You must have had someone else in mind. For instance I would never dream of reminding you about your typing error in pctincrease=0 ;)Quote:
Originally posted by slimdave
.... demolish and ridicule my answer.
I have no idea what you are talking about -- you seem to be thinking that oracle is being run on a single-threaded operating system with one cpu. It appears to be an example of taking a single super-low-level feature of an operating system and driving your database design from that. Did you by any chance study Computer Science at college?Quote:
When CPU sees that a requesting process which needs only 30 Blocks(index) & other one requesting 1000 blocks from say DISK1,
then CPU will first complete smaller I/O request. And now Indexed data will always have much less amount of data then Table,
so when User1 requesting FULL data from tableX and other user requesting Index/Table(by rowid) data which ammounts much less
I/O then formeer, user1 process will have to wait for this request. And I beleive there will be much such smaller I/O requests
than higer I/O, so process requesting higher I/O(particularly Table data requests more than 20% for big tables) will suffer
waits if small indexes are being mixed up on disks where Big tables are present.
Regardless of that, what happens in your example when a batch job accesses the large tables on TS_T1? i/o is not even slightly spread out - the read/write operations choke at a very low threshold where other devices are sitting idle.
This idea of confining certain types of segments to certain devices for fear of getting a collision with another type of device ignores one very clear factor -- you can also get collisions for multiple sessions accessing the same table or the same index, and it is in this regard that your plan completely falls apart.
You are missing the point that i am making. I am saying that if you spread a table and it's indexes each over 6 devices, then if a user runs a query to retrieve a single value from an index, then which device will it access? The answer, of course, is any one of those six -- that is the randomness i refer to. Let's call it "pseudo-randomness"Quote:
Now as you said "disk that is accessed is virtually random", I really dont see any point here because I/O requests will
be handled by CPU which decides which process has to queue/wait, so out of 30 users requesting data from these devices have,
some have to wait for some other requesting less I/O.
Take two hundred users all doing the same thing, plus index range and table scans, and your i/o is balanced out just by statistical averaging. As the number of devices increases, and the number of users increases, and the size of segment extents decreases, the more statistically random the access pattern becomes and the less likely an i/o imbalance becomes.
Oh my god, what a thread! Another one of those attempts to bring one of the old Oracle myths to its misserable end! This time Slimdave being Don Quixote, fighting against windmills. :D
For those that still don't belive separating indexes and tables into sepparating tablespaces does absolutely no good to the performance of modern Oracle database, check this old and loooong thread that were going on on usenet discussion forums some time ago. Take particular note what real Oracle gurus, like Jonathan Lewis, Tom Kyte, Howard Rogers, Connor McDonald and others) have to say about that:
http://groups.google.com/groups?hl=u...1&prev=/groups
:) Yes I can agree with this to an extent only. For example, oracle itself at one point agreed, the use of Automatic UNDO space management at times lead you to wasting storage resource.Quote:
Originally posted by slimdave
... that they can just relax -- use LMT's with fixed sizes, automatic space management, mix tables/indexes and spread them over all the devices.
Convincing them that it is not only easier, but also performs better? Next thing to impossible.
So IMHO, its good to monitor things instead of choosing the easy route to relax, and then go nuts when things go out of control. :D
Sam
Big deal, disk is cheap.....much cheaper than paying DBAs to manage RBS!!!Quote:
Originally posted by sambavan
:) the use of Automatic UNDO space management at times lead you to wasting storage resource.
Let me ask you this: do you place your table and indexes into the same tablespace or use separate ones?Quote:
Originally posted by jmodic
Oh my god, what a thread! Another one of those attempts to bring one of the old Oracle myths to its misserable end! This time Slimdave being Don Quixote, fighting against windmills. :D
For those that still don't belive separating indexes and tables into sepparating tablespaces does absolutely no good to the performance of modern Oracle database, check this old and loooong thread that were going on on usenet discussion forums some time ago. Take particular note what real Oracle gurus, like Jonathan Lewis, Tom Kyte, Howard Rogers, Connor McDonald and others) have to say about that:
http://groups.google.com/groups?hl=u...1&prev=/groups
And by the way: it is a trend nowadays to argue against what-you-call-myths :-)
Is that a good thing, or a bad thing?Quote:
Originally posted by jmodic
...This time Slimdave being Don Quixote, fighting against windmills. ...
In the same (generaly), of course. Why do you ask?Quote:
Originally posted by julian
Let me ask you this: do you place your table and indexes into the same tablespace or use separate ones?
"What-I-call-myths"? No, they are not myths because I say so - there are many much more knowlegable people out there that have proven in praxis and published in literature that those are indeed myths.Quote:
And by the way: it is a trend nowadays to argue against what-you-call-myths :-)
"Nowadays"? No, I've been arguing against those nonsences for many years on this and simmilar forums. And I don't see this as a particular "trend". :confused:
No, mine was EC(Electronics & communication).Quote:
Originally posted by slimdave
Did you by any chance study Computer Science at college?
:rolleyes: :rolleyes: