Oracle DBA Interview Questions

Do you think those are being needed to clear job interview? Off course yes because you have knowledge of Oracle database administration but you don’t have experience about how to face technical questions. Sometimes, interviewer is very keen in recruitment and he or she is having good technical knowledge in database administration then interview will be toughest. Sometimes, interviewer is facing any database related issue or faced any problem then obviously he or she can be expect proper solution from candidate then he or she will be asking Oracle DBA interview questions related with same issues.

• What is SGA?
• What are background processes?
• What is ASM?
• What is RAC?
• If I will be kill SMON then what would be happening?
• My Oracle doesn’t bring up with error out of memory how can I resolve it?  
• What is relation between schema and Oracle user?
• I am altering datatype of table column does synonym will be invalidated?
• How can I recover database when datafile got corrupted?
• Which command should need to execute for unmounting ASM disk where 3 instances are running?
• What is command of checking last backup of RMAN?
• How to check defragmentation in database?
• What is the solution to remove defragmentation of tables?
• What is the command to remove connected user from database?
• Log file sync wait event is constantly appearing in top 5 wait event with high resource consumption in AWR report then what is the issue and how can I solve it?

You can see above Oracle DBA interview questions are very easy but some of those should need more concentration. Some of are tricky and those require more attention because you might be trapped. If any tricky question will be asked first during interview starting time and you will give wrong answer then what will be happening? First impression is last impression. You might be loose impression and chance of job too. Sometime your answer will be correct from your side but it won’t be expected by interviewer and interviewer is expecting something else answer then also you would be rejected.

Use smart technique for replying those tricky and real time scenario based Oracle DBA interview questions. If you will be act smart then you can be create good impression during technical interview or discussion. Chances of getting job become easier. 

You can find out so many technical interview related dba questions from web but all were outdated and some of having wrong answers. You should need to prepare yourself what interviewer expecting. Real time scenario based Oracle DBA interview Questions are available very rare with explanation on web. Off course, grabbing Oracle DBA job is dream of every DBAs but without proper preparation they get failure for getting job.

Real Application Testing

Oracle Database Management System 11g introduced a new extension to the world which quickly became indispensable for many of the leading companies of world because of its high applicability and practicality. What does it do? In short and simple terms, Real Application Testing provides a real-time analysis of the effects of a system upgrade or movement of data from one database from another and then suggests ways and means to prevent any potential problems that may arise from such movement of data. This helps make the movement to the new system smooth and glitch free which used to be a huge problem earlier and not only saves a lot of unnecessary trial runs but also reduces the downtime significantly, thus increasing the performance of the companies.

There are two main components of Oracle Real Application Testing. The first is Database Replay which allows a completely test the changes which would be brought about on your system because of the upgrade/system change by running it at full capacity unlike other simulation programs which only use small samples and therefore, may miss a lot of glitches which would then haunt the real run.

The second is the SQL Performance Analyser which shows the actual impact of the system upgrade/change on the SQL running mechanisms and any effect due to their performance change. SQL statements and programs usually run into thousands of lines of codes and system upgrades or patches tend to mess around with their functionality a lot. SQL Performance Analyser not only points out potential problems with the SQL execution, it also suggests possible remediation techniques on the SQL statements. With Real Application Testing, it is possible to run full scale simulation tests for all system upgrades, patches and even configuration changes, raise potential problems which might occur and also suggest remedial measures to sort out all the kinks before the upgrade is applied.

These all analyzers are machine specific and those are not aware of real server statistics especially there would be more load or more than one database running. Human handled statistics are more important for finding out accurate results of performance testing. High experienced and Oracle specialists can find these all in remote dba work or remote dba services. If you are not knowledge about database administration then you should need to hire either good experienced DBA or hire remote services.

Calculating Response Time and Statistics

Calculating Response Time and Statistics for Oracle Performance Tuning

According to so many books, the response time R correspond to a SQL trace file is identified as the sum of the elapsed time exhausted in database calls (e values) at recursive call depth 0 (dep=0) plus the sum of all elapsed values from inter and recursive database call wait events. The wait time (elapsed values) collected while routing a database call is rolled up into the parameter e of the database call that stimulated the wait. The classification of wait events is pertained in the calculation of R. Time used up waiting for intra database call wait events (all calls including recursive) must not be added to R, since this would outcome in double calculating. The e values of a database call already include the wait time of all intra database call wait events. Database calls are produced to trace files upon conclusion. This is why WAIT entries for intra database call wait events become visible before the PARSE, EXEC, and FETCH entries that engendered them. Runtime statistics, such as consistent reads, physical writes, and db block gets at recursive call depths other than zero are rolled up into PARSE, EXEC, and FETCH calls at recursive call depth 0. Just like ela values of intra database call wait events, these must not be double calculated. To promote a thorough understanding of how an extended SQL trace profiler calculates a resource, we should need to understand properly its mechanism. Then and only we are able to calculate total response time matrix as well as root cause of SQL statement for performing poor.

Database call statistics at recursive call (internal calls implicit cursors) deepness other than zero are revolved up into the statistics at recursive call depth 0. To determine the total number of db block gets in the trace file, we must think only cu parameter values of PARSE, EXEC, and FETCH entries with dep=0. The database call parameter cu (for current read) keep in touches to the statistic db block gets. The fact that the total number of db block gets as determined by querying V$SESSTAT was nine confirms that database call statistics at lower levels are rolled up into statistics at recursive call depth 0. This is methodology of calculation of response time from v$sesstat and if you get trace file then you can get whole idea about response time matrix of problematic SQL.