Path: dp-news.maxwell.syr.edu!spool.maxwell.syr.edu!drn.maxwell.syr.edu!news.maxwell.syr.edu!postnews.google.com!g49g2000cwa.googlegroups.com!not-for-mail From: "Joel Garry" Newsgroups: comp.databases.oracle.server Subject: Re: Separating data, index objects Date: 7 Jul 2005 15:17:45 -0700 Organization: http://groups.google.com Lines: 41 Message-ID: <1120774665.349641.62930@g49g2000cwa.googlegroups.com> References: <1119523067.163453.156090@g44g2000cwa.googlegroups.com> <1120490229.230731.282800@f14g2000cwb.googlegroups.com> <1120514204.987114@yasure> <1120692408.099052.209860@g49g2000cwa.googlegroups.com> <1120695169.667440@yasure> NNTP-Posting-Host: 67.116.125.178 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1120774670 8420 127.0.0.1 (7 Jul 2005 22:17:50 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 7 Jul 2005 22:17:50 +0000 (UTC) In-Reply-To: <1120695169.667440@yasure> User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: g49g2000cwa.googlegroups.com; posting-host=67.116.125.178; posting-account=YRNZ5wwAAAAg-yYjMFwy3FyWUbPiwNdq Xref: dp-news.maxwell.syr.edu comp.databases.oracle.server:246814 >Actually there is no such thing as "all blocks contiguous." As amazing >as it may be many operating systems won't lay down a single file on a >clean drive that way. I think this is a red herring, as whatever it is, it appears to Oracle as contiguous, and if Oracle has to read more stuff, it makes no difference. >We could talk about RAW but that is quite a different matter. And even >on your single user database ... there will be a substantial amount of >recursive SQL. In Oracle you are never alone. And heck, why not talk about raw? And why is there recursive SQL on a single table scan? Sure I'm alone sometimes on Oracle. Got about 3 seconds a shot. I try to avoid putting redos and arcs on my data devices. And I've seen what Oracle does when it is bored on my multiprocessor systems, doesn't bother me in the least, as it is nothing compared to a full table scan. Or even the filesystem doing whatever it does when it is bored (just now I'm looking at a 99% idle 4 processor system, vxfsd is using .5% cpu, 5 app users not doing much, dbw from 2 instances not even showing up on [unix] top 25 processes). Other times the system is definitely not bored, properly sized, even. But I'm sure I'll eventually see another system like this was before, when "throw more hardware at it" actually was the right thing to say. After I had fixed the worst of the reports that weren't finishing in 60 hours... each. Eventually I got it to where they run the month-end during production hours, rather than waiting overnight. Things kinda slow down one day a month (because there are a lot more month-end reports now, they tend to multiply and evolve once people see they work), but not so bad OLTP is impacted much. And just from cdos, I can tell there are still a lot of "before" systems out there... jg -- @home.com is bogus. http://www.signonsandiego.com/uniontrib/20050702/news_1n2mexstamp.html