Month: September 2022

Junior SQL DBA Interview Question Answers -Part2

Hello there! This article is about Junior SQL DBA Interview Q&A. Please go through the first article of this Interview question answers series Junior SQL DBA Interview Q&A

By the way though it is about Junior SQL DBA Interview, you may get these questions for mid to senior level DBAs as well.

Junior SQL DBA Interview Q&A:

1.What are the recovery models in SQL Server?

Ans: Simple, Full and Bulk Logged Recovery Model.

2. Explain the Recovery Models and the difference between them?

Ans: The database recovery model setting affects the retention of transaction log entries. The database logs every transaction into the transaction log file irrespective of the recovery model.

But the recovery model determines when SQL Server can truncate (remove/delete)these transactions  from the log file. Whether you can take transaction log backup and the kinds of restore operations.

Simple: 

SQL Server automatically truncates all the committed transactions from the log file when checkpoint occurs.

Each transaction is still written to the transaction log. (Most junior folks have this confusion). Simple recovery logs every transactions and not like because it is says “simple” it does not log all transactions.

It supports the following backup types:

  1. Full backup
  2. Differential backup
  3. Copy-Only backup
  4. File backup
  5. Partial backup

Now since checkpoint removes the log records, it does not supports transaction log backups. And hence point-in-time restores cannot be performed.

Full:

SQL Server truncates the log only after transaction log backup. Most importantly, just like the simple recovery model, it writes all transactions to the transaction log file.

But the main difference is the transactions stays in the log file until a transaction log backup is taken.

It supports all backup types:

  1. Full backup
  2. Differential backup
  3. Transaction log backup
  4. Copy-Only backup
  5. File and/or file-group backup
  6. Partial backup

Since Full recover model writes every transaction to the transaction log, it supports point-in-time restores.

Bulk Logged: 

Bulk-logged recovery model functions similar to the full recovery model with the exception that it minimally logs the transactions log records.

Hence it also truncates the log only after transaction log backup. It also supports all backup types.

The bulk-logged recovery model minimizes transaction log space usage during bulk-logged operations like BULK INSERTSELECT INTO, or CREATE INDEX .

Because it minimally logs the bulk-logged operations, it affects point-in-time recoveries. Read it Again. I didn’t mention that you can’t perform point-in-time recovery.

This is again a misconception. Always remember you can still do a point-in-time restore just like you can in the full recovery model only if no bulk-logged operations are performed at all when the database is using bulk logged recovery model.

3. How recovery model impacts database backups?

Ans: Since recovery model settings determines when the logged transactions are removed from log file it impacts the backup types.

As explained above because log records are removed when a checkpoint occurs, transaction log backups are not supported when using the simple recovery model.

On the other hand in Full recovery model log records are not auto removed when a checkpoint occurs, hence it supports transaction log backups along with Full and Differential.

Bulk logged recovery model behaves exactly like Full recovery model. Hence it supports all backup types.

4. How to check the recovery model of a database?

Ans: There are multiple ways to determine the recovery model of a database. One is to use SQL Server Management Studio tool (SSMS). Another is using T-SQL Code.

Using SSMS:

First right-click on a database, then select the “Properties” item from the drop-down.

SQL DBA Interview

Now from database properties, select the “Options” item from the left context menu. The window will display as shown below:

SQL DBA Interview

Using T-SQL Code:

SELECT name as DbName, recovery_model_desc as RecoveryModel 
FROM sys.databases  
WHERE name = 'Test' ; --Change the database name as applicable
Result:

SQL DBA Interview

 

5.  How to change the recovery model of a database?

Ans: In the same fashion as described above, there are two ways to change the recovery model. One is through SSMS and second is through T-SQL Code.

Using SSMS:

Go to database properties as shown in the answer for question no. 4 and use the dropdown menu to change the recovery model:

SQL DBA Interview

Using T-SQL Code:

USE [master] ; ALTER DATABASE [Test] SET RECOVERY SIMPLE

6. What are the Network Protocols Supported by SQL Server?
Ans:

  1. Shared Memory
  2. Named Pipes
  3. TCP/IP
  4. VIA

Shared Memory:

Clients can use Shared Memory protocol only to connect to  a SQL Server Instance installed on the same server. You can use this protocol for troubleshooting when you suspect other protocols are not working as per expectation.

Failover Clusters does not support this protocol.

Named Pipes:

Basically used by Clients to connect to a SQL Server Instance in the same LAN (Local Area Network). It facilitates Inter-process communication for the machines in the same LAN. That is output of one process is input for the other. Also you can configure the SQL Server instance to listen to one pipe only.

Below Example screen shots shows named pipe for Named and Default Instance :

Named Instance:

SQL DBA Interview

Default Instance:

SQL DBA Interview

 

TCP\IP:

This is the most popular and common protocol. It empowers client to connect to SQL Instance over the Internet (WAN/Any Server within interconnected Network). This protocol includes network traffic routing standards with advanced security protection, connects computers with different hardware and operating systems configurations.

VIA:

Virtual Interface Adapter protocol is used to support VIA devices such as VIA Storage Area Network devices. This protocol supported high performance, clustering, and load-balancing on dedicated network connections. Microsoft already deprecated this feature.

{ Add a Comment }

How to force manual failover AlwaysOn Group

This article describes how to force manual failover of AlwaysOn Group. A forced failover is a type of manual failover that is strictly for disaster recovery scenarios. Important to realize, in such scenario a planned manual failover is not possible.

Problem: 

For example you have a SQL Server Availability Group (AG) on a Windows Server Failover Cluster (WSFC) with two nodes. Imagine a situation when  one node is completely offline\unavailable or AG Group resource is offline in cluster.

This may cause the AG Group to go into a Resolving state and all the databases in the AG and the Listener will be inaccessible.

Now you must restore the service. In this scenario you have to do force failover and willing to risk losing data.

Solution:

First bring up the WSFC using the forced quorum method. Second Force Failover AG with allow data loss option.

For Example SQLP1 (Primary) is unavailable. WSFC is down and AG is inaccessible.

SQLP2 (Replica) is up and running, and you can connect to SQLP2 from SSMS. The Always On Dashboard lists SQLP2 in the Availability replica, showing AG Group in Resolving state.

ForceQuorum

Recover WSFC using Force Quorum

Important to realize that this is actually forcing a cluster to start without a quorum. Again there are two ways of achieving this. Using powershell and command prompt.

Fix Quorum Using PowerShell:

Start PowerShell using Run As Administrator. You can refer the article Powershell Script to Create Folders where I had shown this step.

Import-Module FailoverClusters
$node = "SQLP2" 
Stop-ClusterNode -Name $node  
Start-ClusterNode -Name $node -FixQuorum
(Get-ClusterNode $node).NodeWeight = 1
Force Quorum Using Command Prompt:

Open command prompt using Run As Administrator. In the first place bring down the cluster service on SQLP2.

C:\>Net stop clussvc

Force Quorum

Now bring up Cluster Service with Force Quorum

C:\>Net start clussvc /forcequorum

Force Quorum

At this moment if you launch WSFC manager, the quorum will show warning as shown in the below screen shot.

Force Quorum

Now the second part of the solution.

Force Always On Failover with Allow data loss:

Now since WSFC is up, the user databases in the AG will appear in the AG Dashboard, but they will be in the Not Synchronizing State.

Force Quorum

We will need to perform a forced AG failover to the SQL Server replica which is still up and running using with allow data loss option. In our example the replica to which we’ll do force failover is SQLP2.

The T-SQL Command to force failover is as follows:

ALTER AVAILABILITY GROUP AGTest FORCE_FAILOVER_ALLOW_DATA_LOSS; 

At this moment the AG should be up and running. Open the AlwaysON Dashboard again and it should now show SQLP2 as Primary and running. This will allow applications to connect to the AG listener and the service is restored.

Force Quorum

When the issue with the server SQLP1 is fixed, they will re-join the WSFC automatically. As long as AG is not removed from other SQL Server instances, they will be able to re-join into the AG as well.

After a forced failover, all secondary databases are suspended. This includes the former primary databases, after the former primary replica comes back online and discovers that it is now a secondary replica. You must manually resume each suspended database individually on each secondary replica.

Resuming of data movement using SSMS:

Force Quorum

T-SQL to resume data movement for the AG:
ALTER DATABASE [AGplaceHolder] SET HADR RESUME;
GO
Summary:

Here we have described a situation when only one node was up in a WSFC without quorum. We performed force quorum to bring up WSFC on a single node (available replica) and brought the SQL AlwaysOn Group back to functional. Once the problem node came up, we resumed data movement to sync the availability databases.

Hope this helps. Please feel free to comment in case of any questions.

You may also interested in the following articles:

How SQL Agent Job Schedule Got Changed Automatically

Interesting facts about SQL Server Startup Parameter -f

Script To List SQL Agent Jobs And Schedules

{ Add a Comment }

Junior SQL Server DBA Interview Questions and Answers

Hey there, this article is about Junior SQL Server DBA Interview Questions and Answers. This will help you learn and prepare for Interview. If you are an Interviewer then also it will help you to access a Junior DBA’s skill. You can ask these questions for 0 – 2 years of experience.

Please do not mug up the answers, always understand the concepts. That will help you to grow your technical skills. I have taken many interviews and it is easy to understand if the candidate has just read a blog without understanding the concepts. The below questions are from real Interviews hence learn well and all the best.

1. What is a Database?

Ans: A database is an collection of structured data. Electronically stored and organized in a computer system. The data can be easily accessed, managed, modified, updated and controlled.

Know more: https://en.wikipedia.org/wiki/Database

2.  What are the main differences between DBMS and RDBMS?

Ans: DBMS stands for Database Management System and RDBMS is the achroname for Relational Database Management System.

DBMS is basically a software to maintain/manage a database with ability to provide controlled access to the data. DBMS stores data as a file.

RDBMS is a an advanced version of DBMS where the data is organized in tables which are related to each other or linked together.

DBMS has low software and hardware requirements whereas RDBMS has higher hardware and software requirements

Any DBMS supports single users, while RDBMS supports multiple users.

DBMS does not support client-server architecture but RDBMS supports client-server architecture.

Examples of DBMS — MS Access, FoxPro, dBase etc.

Example of RDBMS – SQL Server, Oracle, MySQL etc.

3. What is a Transaction in SQL Server?

Ans: Transaction is a set of SQL statements/commands. i.e. Batch of SQL Statement(s) performing a single or multiple activities on a database. It can be a single SQL Statement as well.

Example:

SQL Transaction

4. What are ACID properties?

Ans: ACID stand for Atomicity, Consistency, Isolation, and Durability − commonly known as ACID properties of a transaction.

Atomicity:

Either all or none. Either the entire transaction takes place at once or doesn’t happen at all. There is nothing like partial completion of transactions.

e.g.  You are withdrawing money from ATM. The action (Transaction at the background) either has to complete or does not happen at all.

Consistency:

The database must be in consistent state before and after the transaction.

e.g. If you are transferring money from one account to another account. The total amount of both the accounts should be same before and after the transfer.

Example:
A transferring 100 dollars to B. A’s initial balance is 200 and B’s initial balance is 500.

Before the transaction:
Total of A+B = 200 + 500 = 700$

After the transaction:
Total of A+B = 100 + 6000 = 700$

Isolation: 

A transaction occurs independently. It shouldn’t interfere with the execution of another transaction. Isolation ensures the occurrence of multiple transactions concurrently without a database state leading to a state of inconsistency.

e.g. An account  A is having a balance of 500$ and two transactions started simultaneously to transfer 100$ each to account B and C.  Let’s say these transactions run concurrently and both the transactions read 500$ balance, in that case the final balance of A would be 400$ instead of 300$. So data will become inconsistent.

Isolation makes sure one of the transactions complete first followed by the second one. Hence second transaction would read the correct balance of A as 400$ then deduct 100$.

Durability:

Once a transaction completes successfully, the changes/updates it has made into the database is permanent even if there is a system failure.

e.g: Consider any of the above examples. Once the transaction completes even if the system fails/power down, the account balance will remain same.

5. What is DDL and DML statements?

Ans: DDL – Data Definition Language consists of the SQL commands that can be used to define the database schema. It simply deals with descriptions of the database schema. It is used to create and modify the structure of database objects in the database.

e.g. CREATE, DROP, ALTER, RENAME etc.

DML – Data Manipulation Language deals with the manipulation of data present in the database.

e.g. INSERT, UPDATE, DELETE etc.

6. What is the difference between Implicit, Explicit and Auto Commit transactions?

Ans: In the implicit transaction mode, SQL Server begins the transactions implicitly but it waits for the commit or rollback commands from the user.

e.g.
SET IMPLICIT_TRANSACTIONS ON
UPDATE T1
SET i=2 WHERE i=3
COMMIT;

Until you run the COMMIT statement the transaction will not complete.

In Explicit transaction mode, user must start the transaction with the BEGIN TRANSACTION statement and end with either COMMIT TRANSACTION or ROLLBACK TRANSACTION statements.

e.g.
BEGIN TRAN
UPDATE T1
SET i=2 WHERE i=3
COMMIT TRAN;

Auto Commit: This is the Default mode of SQL Server. When you run a query without specifying BEGIN TRAN/SET IMPLICIT_TRANSACTIONS, the transaction opens internally and closed automatically.

e.g.
UPDATE T1
SET i=2 WHERE i=3

7. What are system databases and User databases?

Ans: The databases which got installed during the Installation of SQL Server are called as system databases. These are basically Master, Model, Msdb, Tempdb and Resource db.

System databases are used to manage SQL Server and contain information about the SQL Server system like logins, databases, linked servers, jobs, schedules, reports, etc.

User databases are created by users/application. These databases contain the data of application.

8. Explain the use of system databases in SQL Server?

Ans:

Master Database:

Contains all the system-level information for an instance of SQL Server. The master database is the most important as it is necessary for starting the SQL Server.

This includes instance-wide metadata such as logon accounts, endpoints, linked servers, and system configuration settings.

Also, master is the database that records the existence of all other databases and the location of those database files and records the initialization information for SQL Server. Therefore, SQL Server cannot start if the master database is unavailable.

Model Database: 

The model database is used as a template for other databases created in SQL Server, especially when creating user-defined databases.

The entire configuration of the model database, including database options, are copied to the newly created database.

Every time SQL Server is started, it creates tempdb from model hence if model is corrupted, SQL will not come up normally.

Msdb Database: 

The msdb database is used mainly by the SQL Server Agent, and also by other features like SQL Server Management Studio, Service Broker, and Database Mail.

SQL Server automatically maintains a complete online backup-and-restore history within tables in msdb.

Tempdb Database:

TempDB is a global resource that is accessed by all the users in the SQL Server Instance

This stores temporary user objects that you create like temporary tables (Global and Local), temporary variables, temporary stored procedures that hold intermediate results during the sorting or query processing, and cursors.

Internal objects like Work Tables, Work files. Intermediate sort results for operations such as creating or rebuilding indexes.

Version stores, which are collections of data pages that hold the data rows that support features for row versioning.

Resource database:

The Resource database is a read-only database that contains all the system objects that are included with SQL Server.

SQL Server system objects, such as sys.objects, are physically persisted in the Resource database, but they logically appear in the sys schema of every database.

The Resource database does not contain user data or user metadata.

Continue reading Junior DBA Interview Q&A -Part2

 

{ Add a Comment }