Hi rajesh I can recall one pro for having multiple extent, is that at times, it = can give u good performance with high degree of chances for parallelism Regards Irfan Khan -----Original Message----- From: Rajesh Puneyani [mailto:rajpuneyani@xxxxxxxxx] Sent: Saturday, November 06, 2004 5:02 AM To: askdba@xxxxxxxxxxxxx Subject: [askdba] Re: Need help with Interview Questions Thank you very much Ganesh and Todd. Your responses gave me a very clear understanding of those questions. I might shoot more questions as and when I appear in more interviews. Regards Rajesh On Fri, 5 Nov 2004 08:11:02 -0500, Pepling, Todd C. <tpepling@xxxxxxx> = wrote: > See inline. >=20 >=20 >=20 > > -----Original Message----- > > From: Rajesh Puneyani [mailto:rajpuneyani@xxxxxxxxx] > > Sent: Thursday, November 04, 2004 5:52 PM > > To: askdba@xxxxxxxxxxxxx > > Subject: [askdba] Need help with Interview Questions > > > > > > Hi Guys, > > > > Recently I appeared in an interview for a position (after a long > > time), Here are a few questions that got me confused. > > > > Pls. give me your feedback regarding the same. > > > > 1. What are various ways to create a table in one database from > > another database ? > > I would say - Create table as select (over the database link) and > > Export/Import in Table mode. > >=20 > > Any other ? >=20 > I'm guessing they were looking for "copy", as in >=20 > COPY FROM scott/password@DB01 > CREATE STUDENT (STUDENT_ID, STUDENT_NAME) > USING SELECT ROLL_NO, NAME FROM STUDENTS > WHERE CLASS_ID =3D 12; >=20 > > > > 2. If a table has 30 Uniform Extents (no size specified) then under > > what circumstances it is good or bad ? Basically - What is the > > advantage of 30 extents over 1 big large extents and what are the > > minuses ? >=20 > Pros for 30 uniform extents: > 1) reduce wasted space and fragmentation at datafile/tablespace > level > 2) compatible with locally managed tablespaces > 3) if even multiple of OS page size, can improve IO performance >=20 > Pros for single large extent: > 1) A single large extent can reduce time to execute > ceratin DDL operations (i.e. truncate table), but > highly unlikely you'd notice any difference compared > to a 30 extent segment. > 2) can reduce time needed to extend segment if initial extent > is sufficient to hold entire segment throughout its life > (as often is the case in "fact" or "reference" tables) > 3) can reduce chaining >=20 > > > > 3. What are various scenarios which make RMAN the best backup and > > recovery tool ? >=20 > 1) large DBs (i.e. 1 terabyte) with limited backup window/time > 2) DB refreshes/cloning > 3) validating backed-up files are usable in recovery without > actually trying a recovery > 4) RMAN is "self-managing", but I've seen it puke on recovery, > so it needs help > 5) automatically purges old archivelogs >=20 > I will point out that if your database is made of many 1G files > instead of fewer 8G files, a recovery with RMAN can actually be > slower that a traditional recovery. Also RMAN had enough bugs > in 8i that it sometimes would fail to recover, while other times > it would work. It seems to work fine in 9i. >=20 > > > > 4. what errors did u hit in your most recent DB Recovery procedure = ? >=20 > A refresh via cloning is a recovery. Personally I've come across > missing archivelogs, which RMAN would verify/validate during a > backup, thus elliminating the missing archivelog issue. This ties > into your question above. >=20 > -Todd > This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = system manager. This message contains confidential information and is = intended only for the individual named. If you are not the named = addressee you should not disseminate, distribute or copy this e-mail. >=20 >