Message-Id: <22541.293624@fatcity.com> From: Jared Still Date: Wed, 11 Sep 2002 14:24:26 -0700 Subject: Re: Misinformation Ranting Steve, SAPDBA has it's uses, but I usually avoid it. It's good for allowing an operator to do stuff like added tablespaces, or stopping/starting the database, etc. It assumes that your going to do your work locally. Like you, I have many scripts that are much more effecient, thank you, and allow me to connect from another server and work remotely. Performance problems: Can't speak to BW, but it can be a can of worms on SAP. ABAP generates the SQL, generally querying tables one at a time, storing the data in its own cache, and satisfying queries from there. You can only optimize for what's in the SGA. Another problem on SAP is cluster tables. These are NOT Oracle cluster tables, but SAP's own brand. Where several tables share a primary key ( sounds like a modeling problem doesn't it? ) they will store the primary key columns as normal, but the data is stuffed into a LONG in binary format. There's nothing you can do from the database side to report on this data. This is unfortunate, for as you can imagine, the performance of ABAP queries against this is abysmal. I have a project right now to get the data out of the BSEG table the RFBLG cluster, so that we can automate some reports we need. Can't do it with the data in the cluster. Don Burleson has a book on SAP for Oracle DBA's. It's out of print, but I got a copy from buy.com last year. You may be able to find it somewhere like alibris.com. Jared On Tuesday 10 September 2002 18:48, Steve Perry wrote: > Jared, > > I recently started a job that uses SAP on Oracle 8.1.7 and the only word > that describes my day is "frustration". Are there any SAP do's and don'ts > you can recommend? > From my brief experience, I should use SAPDBA to add tablespaces or check > stats. Other than that I use sqlplus/scripts for everything else. > When the system does have performance problems, it's really tough to > isolate the problem because there's 400 users sharing 100+ connections and > they're all SAPR3. > the other irritating problem is on the BW system, tables get dropped and > recreated in the wrong tablespace. I know there has to be screen (or table) > that maps objects to tablespaces, but haven't found it. > Any tips you have would be appreciated. > > Thanks, > Steve > > > ----- Original Message ----- > To: "Multiple recipients of list ORACLE-L" > Sent: Tuesday, September 10, 2002 3:28 PM > > > > > > > I've just spent 30 minutes with our SAP administrator trying to > > convince her that we really don't need to reorganize the tables > > in our production SAP database. > > > > Due to some misinformation in an Oracle Press book, 'Oracle Unleashed' > > I think, she is equating number of extents with fragmentation. > > > > The text she referred me to is in fact discussing 'migrated rows' though > > that term is never used. She has become convinced that if the > > extents allocated for tables are not all in contigous space, some > > very nasty fragmentation will occur. > > > > I tried taking it down to disk and explaining that an OLTP system with > > hundreds of users won't really see much benefit from this, but she > > wasn't really ready for that. :) > > > > Her concern is that there are 29000 extents in an index tablespace. > > This might have something to do with there being 3400 indexes in > > said tablespace. > > > > Total 'wasted' ( honeycomb ) space in this 250 gig DB is < 20 meg. Not > > much to gain there. > > > > The text of the book states that you should expect a '10 to 20 percent > > performance increase' by reorganizing the tables/indexes. No data to > > back it up of course. > > > > This is on a database that performs very well most of the time, outside > > of a couple of custom reports that run too long. No complaints from > > users about slowness. > > > > Arrghhh! > > > > I just had to vent to the list, cuz there's no one here that understands. > > > > <\RANT> > > > > Jared > > > > -- > > Please see the official ORACLE-L FAQ: http://www.orafaq.com > > -- > > Author: > > INET: Jared.Still@radisys.com > > > > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 > > San Diego, California -- Public Internet access / Mailing Lists > > -------------------------------------------------------------------- > > To REMOVE yourself from this mailing list, send an E-Mail message > > to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in > > the message BODY, include a line containing: UNSUB ORACLE-L > > (or the name of mailing list you want to be removed from). You may