The Worst Interview of My Life
The hiring manager was interviewing me for the role of “DBA Architect” and I was prattling about my IT operations philosophy. “Answers to most questions can be found using Google,” I proclaimed grandly. “What’s more important is process.” The manager was not impressed. “I expect my DBAs to know the answers like that,” he said and snapped his fingers to illustrate the point. “Do you mind if I ask you some DBA 101 questions?” I came back to earth in a hurry and meekly agreed to be questioned.
“Let’s suppose I have two redo log groups,” said my interrogator. “The first log group has three members called log 1a, log 1b, and log 1c. The second log group has three members called log 2a, log 2b, and log 2c. Explain how Oracle would use these log groups.”
“That’s easy,” I replied. “You have two redo log groups each containing three members. The members of a redo log group are mirror copies of each other. In your case, you have chosen to triply mirror the redo logs. Oracle writes to one redo log group at a time. It writes the same information to all members of a log group. It will therefore write to log 1a, log 1b, and log 1c first. When they are full, it will switch to log 2a, log 2b, and log 2c. When they are full, it will go back to log 1a, log 1b, and log 1c.”
“Is that your final answer?” he said. “That’s my final answer,” I confidently replied.
“You’re wrong,” he barked. “Oracle will write to log 1a and log 2a first. When they are full, it will switch to log 1b and log 2b. When they are full, it will switch to log 1c and log 2c. When they are full, it will go back to log 1a and log 2a.”
“Perhaps you really have three redo log groups,” I protested. “I would have named them differently though. The first log group would have two members called log 1a and log 1b. The second log group would have two members called log 2a and log 2b. The third redo log group would have two members called log 3a and log 3b.”
“I have just two log groups,” he said sternly. “The first log group has three members called log 1a, log 1b, and log 1c. The second log group has three members called log 2a, log 2b, and log 2c.” “In that case, I stand by my answer,” I said. “Is that really your final answer?” he said. “That’s really my final answer,” I said.
“When you get home, why don’t you Google the answer and let me know if you change your mind,” said the man with the power as he ushered me toward the door.
When I got home, I sent him a link to the relevant sections of the Oracle documentation as well as my book.
From the Oracle glossary:
“Each online redo log member (which corresponds to an online redo log file) belongs to a redo log group. Redo log groups contain one or more members. A redo log group with more than one member is called a multiplexed redo log group. The contents of all members of a redo log group are identical.”
From my book:
“It is typical to mirror each redo log file; a mirrored set of redo log files is referred to as a redo log group. It is also typical to put each member of a redo log group on a different storage disk. All the members of a redo log group have the same size; the log writer process stores the same information in all members of a redo log group. Oracle can therefore continue to operate as long as at least one member of each redo log group is undamaged.”
Unsurprisingly, I never heard back from him. It was definitely the worst interview of my life. You’ve got to hate it when the interviewer doesn’t know the answers to his own questions.
I stick by my claim that process is more important than bookish knowledge. How to shut down a database you ask? I know how to shut down my database but I don’t know how to shut down your database. Is your database on a Unix, Windows, or VMS server? Is it a RAC database or a single-instance database? Are you using version 7.3 or 11.2? Are you using Veritas Cluster Server, Sun Cluster, HP Serviceguard, or Windows Cluster? Whose authorization is necessary for the shutdown and who needs to be informed? Should monitoring and alerting be disabled? Do the users need the database at this time? Will any jobs fail if the database is shut down? What should be done about transactions and jobs in progress? Haven’t you written this down somewhere? Why not? How would the next DBA know what to do?