Re: Is Sr. DBAs afraid of not be able to pass cert exam ??

> #20: CREATE TABLE AS SELECT * did not work. I had to list out the columns.
> ALso, it is not necessary to export and imoprt. After the CREATE TABLE,
all
> you need to do is drop the old table or messa round with the data files.
Any
> bad blocks are marked as bad automatically.
>

I had this problem on an Oracle 7.2.3 on very sensitive data ! When you know which block it's can calculate the rowid's within the block. You just query around it by using 'where rowid < x and rowid > y' Also a possibility is setting event 10231 which will skip corrupted blocks and export/import in another schema -
in 8i you now have a package called dbms_repair (if i'm not mistaken) that can do the same thing
Then you need to know what data you're missing ... now normally you have a primary key, thus
you have an index - by only selecting the columns in the primary key and using a hint to use the index
on these columns you'll be able to extract that data out of the index - meaning, the actual column values are
stored in the index so Oracle won't go to the (corrupted) table blocks to get them...
Luckely in my case this was historical data and I was missing some records from a couple of years ago
so I just took one of the exports and import into another schema - the I just 'inserted into select where <<get missing data>>' Always fun having problems like these on very critical systems running 7.2.3 (still !) :-)

"Alan" <alanshein_at_erols.com> wrote in message news:a3etp0$17os7k$1_at_ID-114862.news.dfncis.de...
> The questions were designed to be able to be answered only by an
experienced
> person. WOuldn't even necessarily take a LOT of experience.
>
> #20: CREATE TABLE AS SELECT * did not work. I had to list out the columns.
> ALso, it is not necessary to export and imoprt. After the CREATE TABLE,
all
> you need to do is drop the old table or messa round with the data files.
Any
> bad blocks are marked as bad automatically.
>
>
> "Dusan Bolek" <pagesflames_at_usa.net> wrote in message
> news:1e8276d6.0202010742.782b07d6_at_posting.google.com...
> > "Alan" <alanshein_at_erols.com> wrote in message
> news:<a39jih$16hsai$1_at_ID-114862.news.dfncis.de>...
> > > Here is a list of questions we came up with to ask interviewees. They
go
> > > from easy to hard, mostly. Note that for some of the answers, we
> expected "I
> > > don't know", which was an acceptable answer, so long as they could
> describe
> > > where they would go to find the answer. Unacceptable answers to the
> tough
> > > ones were guesses based on thin air. And yes, some OCPs (with little
or
> no
> > > experience) could NOT ANSWER question #1!!! I put the question in
there
> as
> > > an easy one to start with to make the interviewees feel comfortable
> (same
> > > with #2). I was shocked when the first interviewee couldn't answer it
> (#1).
> > > On #3, these OCPs would always answer with, "I would MONITOR...",
> whereas
> > > experienced interviewees answered with "I would DO thus and such..."
> When
> > > quizzed further about how they would actually go about SOLVING the
> problem,
> > > the OCPs answered, "I would monitor..." again.
> > >
> > > Note that the questions are heavily based on skills and knowledge
> acquired
> > > during experience, rather than from a book. BTW, can anyone here
answer
> #20?
> > > (It actually happened to me, but we never expected a real answer, just
> an
> > > "I'm not sure, but I would..."). Yes, there may be one or more trick
> > > questions (with an answer like, "You can't do that")
> >
> > Hm, that looks easy. Only few of this questions seems a problem for me
> > and all of them I can solve with quick look in Oracle manuals.
> > Is strange that you can't get a people to score in these question
> > well. It seems to me mostly like basic questions that capable DBA
> > should know answers for. Maybe bigger problem with these question for
> > me can be a time frame. For example, a question about slow query can
> > take about half hour to answer, because so many tasks can be done to
> > solve this problem.
> > Question #20 looks interesting, I've never encounter this problem.
> > However, If you can select data from that table you can always do
> > "create table good_table as select * from bad_table;", so you wouldn't
> > lost any data. However, after that is a good idea to check all your
> > datafiles, evacuating data from this one and recreate this tablespace
> > again. Maybe export and recreating whole database can be also a good
> > option, because this is looking strange and dangerous.
> >
> > --
> > _________________________________________
> >
> > Dusan Bolek, Ing.
> > Oracle team leader
> >
> > Note: pagesflames_at_usa.net has been cancelled due to changes (maybe we
> > can call it an overture to bankruptcy) on that server. I'm still using
> > this email to prevent SPAM. Maybe one day I will change it and have a
> > proper mail even for news, but right now I can be reached by this
> > email.
>
>
Received on Fri Feb 01 2002 - 15:43:20 CST