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

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")

Also, only experienced interviewees even came close on #13. Book OCPs had no idea at all. So, for your enjoyment...

1. How would you go about obtaining the system date in a select statement?
2. What is the difference between SYS and INTERNAL?
3. A query is taking a long time to execute. Describe what you would look at to determine the causes.
4. What kinds of things need to be considered when calculating the sizes of the tablespaces for a new production system?
5. Describe an outer join, why it would be used, and how it would be implemented.
6. Describe a Cartesian product and what would cause this to happen.
7. How would you go about ensuring that certain rollback segments are on line at startup if the database instance needs to be shut down?
8. How would you ensure that very large update statements had enough rollback space?
9. Describe the SGA and what it is used for.
10. How many types of triggers are there? How many times can one type of trigger be used on any one table?
11. What are some of the inefficiencies of using views?
12. Tell me about a situation in which you had to deal with a difficult user, and how you resolved it.
13. Two new applications are being developed that use different databases (schemas). Some data sharing is needed, but mostly they are separate. A new database server is being ordered to handle the two new systems. It will have 5 hard drives. How would you configure the drives (mirror or not, etc). How would you configure the tablespaces? What recommendations would you make to improve the situation? What if you had 7 drives? What do you feel is the minimum number of drives needed in this situation and why?
14. What does a control file do in SQL-LOADER?
15. What does this report tell you (show disk I/O report)?
16. How would you go about issuing a truncate statement from a stored procedure?
17. What are some of the problems when migrating data from (dBase, FoxPro, Access, etc.) to Oracle via ODBC?
18. What is a mutating table?
19. Describe a difficult technical problem that you have solved, and the solution you came up with.
20. You try to do a select count on a table, but get an error that there is a bad data block, yet selecting data by specifying the field names returns all of the data fine. How would you go about fixing the problem? Archivelog is turned off.
21. A user initiates an update. It is taking a lot longer than expected. Is there a way to determine if the update is in process or if a rollback is occurring? What is involved?
22. How do you use a sequence in an update statement?
23. Considering that we are not a 7/24 shop, how would you implement a backup strategy?

"Keith Boulton" <kboulton_at_ntlworld.com> wrote in message news:zFX58.2140$zB.607331_at_news2-win.server.ntlworld.com...
> Tom Dyess <tdyess_at_dyessindustries.com> wrote in message
> news:pfW58.167682$_w.25696938_at_typhoon.tampabay.rr.com...
> > Keith,
> >
> > You didn't get much out of your first year of DBA work, did you? You
> > remind me of the poeple who claim to know 'everything' there is to know
> > about computers. I ususally run away when I hear that.
>
> I didn't claim that you would know everything after a year, but I do claim
> you should know everything you need to know. By the end of a year, you
will
> have encountered almost all the problematic situations that are likely to
> arise in that environment, you should have a good understanding of how the
> database works and you should be able to resolve new problems. This is why
I
> said "in a single job."
>
> This is different from the level of knowledge that might be preferred
> (although rarely found) in a troubleshooting consultant who might be
> expected to have both a broader and more detailed knowledge than is
required
> for most permanent DBA jobs.
>
> In my opinion, it is not knowledge that is important to be good at a job
in
> this industry, but rather the ability to adapt to new tools, software
> releases, development methods, hardware platforms and user requirements.
>
> To take an example, I've never used advanced queueing. I know advanced
> queuing exists and I've read the manuals about it. I'm confident (possibly
> incorrectly) that it would take me a very short time to get up to speed -
> I've used other message queueing software. The most important thing I've
> learnt from experience however is that you can never trust something to
work
> as expected. You have to devise usage and load scenarios and test them
> before committing to a production architecture - even if you've used the
> particular tool before it may have changed between releases or your
previous
> usage may have been been in a sufficiently different environment so as not
> to be comparable. If AQ didn't fit my particular needs, I'm quite happy to
> use another queueing mechanism or write my own. I believe this attitude to
> be more desirable than particular knowledge of AQ. I have often worked
with
> people who are knowledgeable but don't test their approaches before
> committing to a design. I've also often worked with people who force the
> requirement to fit their knowledge - ie if all you have is a hammer, every
> problem looks like a nail. What I'm saying is that attitude and aptitude
is
> mostly more important than detailed technical skill for recruitment to a
> permanent (or even long-term contract). Obviously for a 2 day consultation
> contract, the criteria must be different.
>
>
>
>
>
Received on Wed Jan 30 2002 - 14:06:09 CST