How to prepare for a telephone interview: a few tips and tricks

The telephone interview is a crucial stage of the selection process. Lots of companies consider it an effective form of pre-screening. If you applied for a specific role the recruit er will contact you to make an appointment to talk at a specific time and date, so you will have time to prepare. Here are some simple tips to help you perform during your telephone interviews. 

Preparation for a telephone interview is as important as preparation before any other form of interview or meeting. The impression you create in the opening moments, and the manner with which you present yourself will determine whether or not you will be successful.

Find out as much as you can about the company and the job description. The company websites are one of the best sources of information. Find out about the size and structure of the company, its products and its markets.

Make a note of any questions you would like to ask. Ask questions about items that are important to you, especially if your decision whether to proceed depends upon the answers (for example: will I have to relocate? (if that is something you do not wish to do!). Otherwise, ask broad questions such as: What training will be given? What opportunities are there for advancement? Have these questions written down.

Have a notepad and pen ready, along with your diary. Have your CV at hand. In all probability the hiring manager will have a copy of it too, so you probably won't be asked to describe your background in detail.

The main rules are:

• Sound interesting/interested, energetic and enthusiastic
• Be succinct (don't waffle)
• Ask open-ended questions (beginning with who, what, when, why, where, how: these all ask for information, and keep the ball in the other person's court). Be prepared that they will do exactly the same!
• Don't use jargon
• Be polite
• Use the other person's name regularly throughout the conversation (but not all the time). Also, use the company name a few times.

Prepare to answer these questions

You can't prepare for every possible question, but there are a few which frequently come up:

• Tell me about yourself!
• What do you know about our company?
• What are you looking for?
• What would you like to know about us? (A good opportunity to ask your prepared questions)
• What are your strengths?
• What are your weaknesses?
• What else would you like to know? (An ideal opportunity to 'close' - see below)

Closing the telephone interview

Part of the purpose of the telephone interview (from the recruiter or hiring manager's perspective) is to find out how keen you are, and (especially in the case of sales jobs) whether you have natural closing ability. As soon as it seems appropriate during the conversation, ask for a date to meet for a face-to-face interview. Say something like 'I'd really like to visit you to show you what I can do for you. When can you meet me?'

If you are invited for a face-to-face interview, thank the recruiter, and discuss the details:

• When?
• Where?
• With whom?
• What should you take to the interview?
• What will the procedure or next steps be?
• Will they be able to make a decision after the next interview? If not, what will happen after that?
• How many people are you up against?
• What is the most important thing the company is looking for?

Enable Archive Log Mode

The following are the steps required to enable archive log mode on an Oracle 10g or 11g database.

Verify the database log mode.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

[oracle@dba1 ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on Thu Nov 05 12:54:05 2016 Copyright (c) 1982, 2009, Oracle.  All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> archive log list Database log mode              No Archive Mode Automatic archival             Disabled Archive destination            USE_DB_RECOVERY_FILE_DEST Oldest online log sequence     25 Current log sequence           27 SQL>

The log mode is No Archive Mode. Note that Archive destination is USE_DB_RECOVERY_FILE_DEST. You can determine the path by looking at the parameter RECOVERY_FILE_DEST.

1 2 3 4 5 6 7 8

SQL> show parameter recovery_file_dest NAME                                 TYPE        VALUE ------------------------------------ ----------- ------------------------------ db_recovery_file_dest                string      /u01/app/oracle/flash_recovery                                                  _area db_recovery_file_dest_size           big integer 3852M SQL>

By default, archive logs will be written to the flash recovery area. If you do not want to write archive logs to the flash recovery area you can set the parameter LOG_ARCHIVE_DEST_n to the location in which you wish to write archive logs.

1 2 3 4 5 6 7 8 9 10 11

SQL> alter system set log_archive_dest_1='LOCATION=/u02/app/arch' scope = both; System altered. SQL> archive log list; Database log mode              No Archive Mode Automatic archival             Disabled Archive destination            /u02/app/oracle/arch Oldest online log sequence     25 Current log sequence           27 SQL>

Now we shutdown the database and bring it backup in mount mode.

1 2 3 4 5 6 7 8 9 10 11 12 13 14

SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount ORACLE instance started. Total System Global Area  849530880 bytes Fixed Size                  1339824 bytes Variable Size             511708752 bytes Database Buffers          331350016 bytes Redo Buffers                5132288 bytes Database mounted. SQL>

Lastly all that is needed it set archive log mode and open the database.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

SQL> alter database archivelog; Database altered. SQL> alter database open; Database altered. SQL> archive log list Database log mode              Archive Mode Automatic archival             Enabled Archive destination            /u02/app/oracle/arch Oldest online log sequence     25 Next log sequence to archive   27 Current log sequence           27 SQL>

We can now see that archive log mode is enabled. Notice that Automatic archive is enabled as well. In Oracle 9i an earlier another parameter needed to be set in order to enable automatic archiving. This in no longer the case in 10g and 11g as automatic archiving is enabled when the database is placed in archive log mode.

You can switch to the log file to see that an archive is written to archive log location.

1 2 3 4 5 6

SQL> alter system switch logfile; System altered.

Disable Archive Log Mode

The following are the steps required to disable archive log mode on an Oracle 10g or 11g database.

Verify the database log mode.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

[oracle@dba1 ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on Thu Nov 05 12:54:05 2016 Copyright (c) 1982, 2009, Oracle.  All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> archive log list; Database log mode              Archive Mode Automatic archival             Enabled Archive destination            /u02/app/oracle/arch Oldest online log sequence     26 Next log sequence to archive   28 Current log sequence           28 SQL>

The Database log mode is Archive mode. Next we shut down the database and bring up back up in mount mode.

1 2 3 4 5 6 7 8 9 10 11 12 13 14

SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount ORACLE instance started. Total System Global Area  849530880 bytes Fixed Size                  1339824 bytes Variable Size             511708752 bytes Database Buffers          331350016 bytes Redo Buffers                5132288 bytes Database mounted. SQL>

All that is left is to disable archive log mode and open the database.

1 2 3 4 5 6 7 8 9 10 11 12 13

SQL> alter database noarchivelog; Database altered. SQL> alter database open; Database altered. SQL> archive log list; Database log mode              No Archive Mode Automatic archival             Disabled Archive destination            /u02/app/oracle/arch Oldest online log sequence     26 Current log sequence           28

Data Guard Architecture Oracle 11g Part-3

The redo data transmitted from the primary database is written to the standby redo log on the standby database. Apply services automatically apply the redo data on the standby database to maintain consistency with the primary database. It also allows read-only access to the data.The main difference between physical and logical standby databases is the manner in which apply services apply the archived redo data.

There are two methods in which to apply redo  i.e,
1.)  Redo Apply (physical standby)     and
2.) SQL Apply   (logical standby).

They both have the same common features:

• Both synchronize the primary database
• Both can prevent modifications to the data
• Both provide a high degree of isolation between the primary and the standby database
• Both can quick transition the standby database into the primary database
• Both offer a productive use of the standby database which will have no impact on the primary database

1.) Redo Apply (Physical Standby) :  Redo apply is basically a block-by-block physical replica of the primary database, redo apply uses media recovery to read records from the SRL into memory and apply change vectors directly to the standby database. Media recovery does parallel recovery for very high performance, it comprises a media recovery coordinator (MRP0) and multiple parallel apply rocesses(PR0?). The coordinator manages the recovery session, merges the redo by SCN from multiple instances (if in a RAC environment) and parses redo into change mappings partitioned by the apply process. The apply processes read data blocks, assemble redo changes from mappings and then apply redo changes to the data blocks.

This method allows us to be able to use the standby database in a read-only fashion, Active Data Guard solves the read consistency problem in previous releases by the use of a "query" SCN. The media recovery process on the standby database advances the query SCN after all dependant changes in a transaction have been fully applied. The query SCN is exposed to the user via the current_scn column of the v$databaseview  Read-only use will only be able to see data up to the query SCN and thus the standby database can be open in read-only mode while the media recovery is active, which make this an ideal reporting database.

We can use SYNC or ASYNC and is isolated from I/O physical corruptions, corruption-detections checks occur at the following key interfaces:

On the primary during redo transport - LGWR, LNS, ARCH use the DB_UTRA_SAFE parameter

On the standby during redo apply       - RFS, ARCH, MRP, DBWR use the DB_BLOCK_CHECKSUM and DB_LOST_WRITE_PROTECT parameters .

If Data Guard detects any corruption it will automatically fetch new copies of the data from the primary using gap resolution process in the hope of that the original data is free of corruption.The key features of this solution are

• Complete application and data transparency - no data type or other restrictions
• Very high performance, least managed complexity and fewest moving parts
• End-to-end validation before applying, including corruptions due to lost writes
• Able to be utilized for up-to-date read-only queries and reporting while providing DR
• Able to execute rolling database upgrades beginning with Oracle Database 11g 

2.) SQL Apply (Logical Standby)  : SQL apply uses the logical standby process (LSP) to coordinate the apply of changes to the standby database. SQL apply requires more processing than redo apply, the processes that make up SQL apply, read the SRL and "mine" the redo by converting it to logical change records and then building SQL transactions and applying SQL to the standby database and because there are more moving parts it requires more CPU, memory and I/O then redo apply .

SQL apply does not support all data types, such as XML in object relational format and Oracle supplied types such as Oracle spatial, Oracle inter-media and Oracle text .

The benefits to SQL apply is that the database is open to read-write while apply is active, while we can not make any changes to the replica data we can insert, modify and delete data from local tables and schemas that have been added to the database, we can even create materialized views and local indexes. This makes it ideal for reporting tools, etc to be used.

The key features of this solution are :

• A standby database that is opened for read-write while SQL apply is active
• A guard setting that prevents the modification of data that is being maintained by the SQL apply
• Able to execute rolling database upgrades beginning with Oracle Database 11g using the KEEP IDENTITY clause

Data Guard Architecture Oracle 11g Part-2

LNS (log-write network-server) and ARCH (archiver) processes running on the primary database select archived redo logs and send them to the standby database, where the RFS (remote file server) background process within the Oracle instance performs the task of receiving archived redo-logs originating from the primary database .

The LNS process support two modes  as
1.) Synchronous    and
2.) Asynchronous.

1.) Synchronous Mode :  Synchronous transport (SYNC) is also referred to as "zero data loss" method because the LGWR is not allowed to acknowledge a commit has succeeded until the LNS can confirm that the redo needed to recover the transaction has been written at the standby site. In the below diagram, the phases of a transaction are : 

The user commits a transaction creating a redo record in the SGA, the LGWR reads the redo record from the log buffer and writes it to the online redo log file and waits for confirmation from the LNS. The LNS reads the same redo record from the buffer and transmits it to the standby database using Oracle Net Services, the RFS receives the redo at the standby database and writes it to the SRL. When the RFS receives a write complete from the disk, it transmits an acknowledgment back to the LNS process on the primary database which in turns notifies the LGWR that the transmission is complete, the LGWR then sends a commit acknowledgment to the user.

This setup really does depend on network performance and can have a dramatic impact on the primary databases, low latency on the network will have a big impact on response times. The impact can be seen in the wait event "LNS wait on SENDREQ" found in the v$system_event dynamic performance view.

2.) Asynchronous  Mode : Asynchronous transport (ASYNC) is different from SYNC in that it eliminates the requirement that the LGWR waits for a acknowledgment from the LNS, creating a "near zero" performance on the primary database regardless of distance between the primary and the standby locations. The LGWR will continue to acknowledge commit success even if the bandwidth prevents the redo of previous transaction from being sent to the standby database immediately. If the LNS is unable to keep pace and the log buffer is recycled before the redo is sent to the standby, the LNS automatically transitions to reading and sending from the log file instead of the log buffer in the SGA. Once the LNS has caught up it then switches back to reading directly from the buffer in the SGA .

The log buffer ratio is tracked via the view X$LOGBUF_READHIST a low hit ratio indicates that the LNS is reading from the log file http://learnoracledbaforfree.blogspot.in/2016/11/data-guard-architecture-oracle-11g-part.htmlnstead of the log buffer, if this happens try increasing the log buffer size.

The drawback with ASYNC is the increased potential for data loss, if a failure destroys the primary database before the transport lag is reduced to zero, any committed transactions that are part of the transport lag are lost. So again make sure that the network bandwidth is adequate and that get the lowest latency possible.

A log file gap occurs whenever a primary database continues to commit transactions while the LNS process has ceased transmitting redo to the standby database (network issues). The primary database continues writing to the current log file, fills it, and then switches to a new log file, then archiving kicks in and archives the file, before we know it there are a number of archive and log files that need to be processed by the the LNS basically creating a large log file gap.

Data Guard uses an ARCH process on the primary database to continuously ping the standby database during the outage, when the standby database eventually comes back, the ARCH process queries the standby control file (via the RFS process) to determine the last complete log file that the standby received from the primary. The ARCH process will then transmit the missing files to the standby database using additional ARCH processes, at the very next log switch the LNS will attempt and succeed in making a connection to the standby database and will begin transmitting the current redo while the ACH processes resolve the gap in the background. Once the standby apply process is able to catch up to the current redo logs the apply process automatically transitions out of reading the archive redo logs and into reading the current SRL. The whole process can be seen in the diagram below  :

Data Guard Architecture Oracle 11g Part-I

Data Guard Architecture Oracle 11g Part-2

I have decided to post the Architecture of the Standby Database, although there are lots of  stuff on the Internet but most of them are lengthy and are not so juicy . I have read a good notes on Standby Database  Architecture and further decided to post it . Though, I have modified few topics to make it more clear , juicy and interesting .Hope you all find helpful  and enjoy this after reading. 

Oracle Data Guard is the most effective and comprehensive data availability, data protection and disaster recovery solution for enterprise databases. It provides a method for customers to actively utilize their disaster recovery configuration for read-only queries and reports while it is in standby role. Additionally, a standby database can be used to offload backups from production databases or for Quality Assurance and other test activities that require read-write access to an exact replica of production. These capabilities are unique to Oracle .

Oracle   Data  Guard is  the  management,  monitoring,  and  automation  software  infrastructure that creates,maintains, and monitors one or more standby databases  to  protect  enterprise  data  from  failures, disasters, errors, and corruptions.Data Guard is basically a ship redo and then apply redo, as we know redo is the information needed to recover a database transaction. A production database referred to as a primary database transmits redo to one or more independent replicas referred to as standby databases. Standby databases are in a continuous state of recovery, validating and applying redo to maintain synchronization with the primary database. A  standby database will also automatically re-synchronize if it becomes temporary disconnected to the primary due to power outages, network problems, etc.

The diagram below shows the overview of Data Guard, firstly the redo transport services transmits redo data from the primary to the standby as it is generated, secondly services apply the redo data and update the standby database files, thirdly independently of Data Guard the database writer process updates the primary database files and lastly Data Guard will automatically re-synchronize the standby database following power or network outages using redo data that has been archived at the primary.

Redo records contain all the information needed to reconstruct changes made to a database. During  recovery the database will read the  change vectors in the redo  records and apply  the changes  to  the relevant blocks.Redo  records are  buffered  in a circular fashion in  the redo log  buffer  of the SGA, the  log  writer  process (LGWR) is  the  background process  that handles redo log buffer  management. The LGWR at specific times writes redo log entries into a sequential file (online redo log file) to free space in the buffer, the LGWR writes the following.

1.) A commit record :   When ever a transaction is committed the LGWR writes the transaction redo records from the buffer to the log file and assigns a system change number (SCN), only when this process is complete is  the transaction said to be committed.

2.) Redo log buffers :  If the redo log becomes a third full or if 3 seconds have passed sine the last time the LGWR wrote to the log file, all redo entries in the buffer will be written to the log file. This means  that redo records can be written to the log file before the transaction has been committed and if  necessary media recovery will rollback these changes using undo that is also part of the redo entry.

Remember that the LGWR can write to the log file using "group" commits, basically entire list of redo entries of waiting transactions (not yet committed) can be written to disk in one operation, thus reducing I/O. Even through the data buffer cache has not been written to disk, Oracle guarantees that no transaction will be lost due to the redo log having successfully saved any changes.

Data Guard Redo Transport Services  coordinate the  transmission of redo from  the primary  database to the standby database, at the same time the LGWR  is  processing redo, a separate Data Guard process called the Log Network Server (LNS) is reading from the redo buffer in the SGA and passes redo to Oracle Net Services from transmission to a standby database, it is possible to direct the redo data to nine standby databases, we can also use Oracle RAC and they don't all need to be a RAC setup. The process Remote File Server  (RFS) receives the redo from LNS and writes it to a sequential file called a standby redo log file (SRL).