Wednesday, 16 September 2015

How to Create an Audit Trigger In SQL Server

Overview

In my previous article, we have discussed about Temporal Tables in SQL Server 2016, and understand much more about it. Now in this article we will discuss about triggers and will know how to create an audit trigger in SQL Server.

In many applications’ database, it is a very difficult task to find who did something and at what time was the activity performed on that application. However, in SQL Server it is easy to find someone’s activity at any time by using some special type of SQL objects like triggers.

What Are Triggers in SQL Server?

In SQL Server, a trigger is a special kind of stored procedure or database object that automatically executes and captures events or actions that a user performs on a SQL Server database. SQL Server comprises of two types of triggers:

  1. DML Triggers (Data Manipulation Language)
  2. DDL Triggers (Data definition Language)

DML Triggers: DML triggers applies when a user performs operations like INSERT, UPDATE, or DELETE in a specified table or view.

DDL Triggers: DDL triggers applies when a user performs operations such as CREATE, ALTER, and DROP. This kind of trigger is used for administrative tasks like; auditing database operations.

Now, after a small description of triggers in SQL Server we will focus on our main topic that is how to create an audit trigger in SQL Server.

Why Do We Need To Create An Audit Trigger?

The basic need to create an audit trigger in SQL Server is for security purpose and these things become evidence at the time of tampering:

  • Client software that was used for accessing data
  • Date and time, at which the change was occurring
  • Data value, prior and after change

It means that all the above info works as evidence when a trigger is fired.

Now we will create an SQL Server Database audit trigger that will audit and store all the security related events of SQL Server.

USE [master]
GO
DROP TABLE [dbo].[SecurityLog]
GO
CREATE TABLE [dbo].[SecurityLog](
      [EventType][nvarchar](128) NULL, 
      [EventTime][datetime] NULL,
      [EventLog][xml] NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

Now we will create DDL trigger that will capture and store all connections and security-related events:

USE [master]
GO
IF EXISTS (SELECT * FROM sys.server_triggers 
             WHERE name = 'ddl_trig_capture_security_events')
DROP TRIGGER ddl_trig_capture_security_events
ON ALL SERVER;
GO
CREATE TRIGGER ddl_trig_capture_security_events
ON ALL SERVER;
FOR  LOGON, DDL_SERVER_SECURITY_EVENTS,        
       DDL_DATABASE_SECURITY_EVENTS
AS    
      INSERT INTO [master]..[SecurityLog] (EventType, EventTime, EventLog)      
     SELECT EVENTDATA().value('(/EVENT_INSTANCE/EventType)[1]','nvarchar(128)')              
     ,EVENTDATA().value('(/EVENT_INSTANCE/PostTime)[1]','datetime')             
,EVENTDATA()
GO

Once you create an audit trigger, you can test it using the following command:

USE [master]
GO
CREATE LOGIN [TestDDL] WITH PASSWORD=N'TestDDL'
GO
USE [AdventureWorks2012]
GO
CREATE USER [TestDDL] FOR LOGIN [TestDDL]
GO
ALTER ROLE [db_datareader] ADD MEMBER [TestDDL]
GO
GRANT EXECUTE ON [dbo].[uspGetBillOfMaterials] TO [TestDDL]
GO

SQL Server database audit trigger for event notification

USE [msdb]
GO
--Creating queue
CREATE QUEUE [SecurityEventsQueue]
GO
--Creating service for the queue
CREATE SERVICE [//AdventureWorks.com/SecurityEventsService]
AUTHORIZATION [dbo]
ON QUEUE [dbo].[SecurityEventsQueue]
GO

Creating route for the service

CREATE ROUTE SecurityEventsRoute
WITH SERVICE_NAME = '//AdventureWorks.com/SecurityEventsService',
ADDRESS = 'LOCAL';
GO

Creating Event Notification to capture connection and secrity-related events

USE [msdb]
GO
CREATE EVENT NOTIFICATION NotifySecurityEvents
ON SERVER
FOR AUDIT_LOGIN,       
       AUDIT_LOGOUT,       
      AUDIT_LOGIN_FAILED,       
      DDL_SERVER_SECURITY_EVENTS,       
      DDL_DATABASE_SECURITY_EVENTS
TO SERVICE '//AdventureWorks.com/SecurityEventsService' ,    
           '9D584F73-1796-4494-ADC2-04BDD729FBCE';
GO

We will create a service program that will process the event messages that are generated via Event Notification objects:

IF EXISTS (SELECT * FROM [sys].[objects] WHERE [name] = 'sProcessSecurityEvents')
DROP PROCEDURE [dbo].[sProcessSecurityEvents]
GO
CREATE PROC [dbo].[sProcessSecurityEvents]
AS BEGIN
SET NOCOUNT ON
SET CONCAT_NULL_YIELDS_NULL ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
BEGIN TRY
DECLARE  @message_body [xml]             
             ,@EventTime [datetime]             
            ,@EventType [varchar](128)             
           ,@message_type_name [nvarchar](256)                     ,@dialog [uniqueidentifier]

Endless loop

WHILE (1 = 1)
BEGIN
BEGIN TRANSACTION ;

Receive the next available message

WAITFOR (RECEIVE TOP(1)                    
              @message_type_name = [message_type_name],                    
                 @message_body = [message_body],                    
                 @dialog = [conversation_handle]
FROM [dbo].[SecurityEventsQueue]), TIMEOUT 2000

Rollback and exit if no messages were found

IF (@@ROWCOUNT = 0)
BEGIN       
        ROLLBACK TRANSACTION;       
        BREAK;
END;

End conversation of end dialog message

IF (@message_type_name = 'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog')
BEGIN       
       PRINT 'End Dialog received for dialog # ' + CAST(@dialog as [nvarchar](40));       
       END CONVERSATION @dialog;
       END;
ELSE
BEGIN       
       SET @EventTime = CAST(CAST(@message_body.query('/EVENT_INSTANCE/PostTime/text()') AS [nvarchar](max)) AS [datetime])       
       SET @EventType = CAST(@message_body.query('/EVENT_INSTANCE/EventType/text()') AS [nvarchar](128))       
       INSERT INTO [master]..[SecurityLog] ([EventType], [EventTime], [EventLog])       
      VALUES (@EventType, @EventTime, @message_body)
END
COMMIT TRANSACTION
END --End of loop
END TRY
BEGIN CATCH
SELECT ERROR_NUMBER()             
            ,ERROR_SEVERITY()             
            ,ERROR_STATE()             
            ,ERROR_PROCEDURE()             
            ,ERROR_LINE()             
            ,ERROR_MESSAGE()
END CATCH
END
GO

After successfully created service program, execute the following script to activate service broker queue:

ALTER QUEUE [dbo].[SecurityEventsQueue]        
        WITH STATUS = ON       
        ,ACTIVATION (PROCEDURE_NAME = [sProcessSecurityEvents]       
        ,STATUS = ON       
        ,MAX_QUEUE_READERS = 1       
         ,EXECUTE AS OWNER)
GO

Now test and examine the output of the SecurityLog table.

To track the security-related event we can also use SQL Server audit.

USE [master]
GO
CREATE SERVER AUDIT [Audit-SecurityEvents]
TO FILE
(      FILEPATH = N'D:\Demo_SQLAudit'       
      ,MAXSIZE = 200 MB       
      ,MAX_ROLLOVER_FILES = 2147483647       
       ,RESERVE_DISK_SPACE = OFF )
WITH
(      QUEUE_DELAY = 1000       
          ,ON_FAILURE = CONTINUE )
GO

After this now, we will create an audit specification to audit our SQL server and database security-related events like Login Password change, Database user or object permission change, failed login attempts and server principle change:

CREATE SERVER AUDIT SPECIFICATION [ServerAuditSpecification]
FOR SERVER AUDIT [Audit-SecurityEvents]
ADD (LOGIN_CHANGE_PASSWORD_GROUP),
ADD (DATABASE_PRINCIPAL_CHANGE_GROUP),
ADD (DATABASE_OBJECT_PERMISSION_CHANGE_GROUP),
ADD (FAILED_LOGIN_GROUP),
ADD (SERVER_PRINCIPAL_CHANGE_GROUP)
GO

Conclusion

In this section, we learnt about how SQL Server uses DML and DDL triggers for security purposes. These DML and DDL triggers capture user events that they performed on SQL Server. Although some SQL features such as SQL Audit are not yet fully developed, auditing of SQL server database using DDL triggers have several disadvantages. For example, a user can easily disable the triggers if he has sufficient permissions. Another disadvantage of using trigger in SQL Server is that triggers perform a schema change and then delete the captured information from auditing repository. In addition, the procedure to create an audit trigger in SQL Server is too long and time consuming. Therefore, it is better to use SQL log viewer tool, which saves a significant amount of valuable time and provides you a convenient result.

Wednesday, 2 September 2015

Know About Temporal Tables in SQL Server 2016

Temporal tables were included in SQL Server 2016 as a new feature. These temporal tables are also known as system-versioned tables allow SQL Server for keeping the history of data in table automatically. A temporal table can be defined as a table for which PERIOD definition exists comprising of system columns. These columns are available with data-type of datetme2 where the period of validity is recorded by system. It also has a history table associated with it where all the system records of previous versions are recorded. So the most significant function of Temporal Table is that it allows storing data in table at any point in time. Usually what happens when you execute any delete statement on table, the old data will be overwritten and you will view latest data (after deletion) but with temporal table you can view latest data and also the old data (without deletion). This is because temporal table value of all the entries or records is maintained and at any point can be determined.

Significance of Temporal Tables

ANSI SQL 2011 standard initially introduced the Temporal Tables, which later was released in SQL Server 2016. As mentioned above, this temporal tables or system-versioned tables let users to query updated or deleted data. On the other hand, a normal table would only return the current data from the table. This practical explanation may help: Suppose a column value is updated from 10 to 20, a normal table will retrieve the current value i.e. 20 only. However, temporal table will allow retrieving old value 10 also. This is done by keeping a history table with all the records, which were entered or updated.

Use Cases for Temporal Table:

  • Indulgence of changing business trends
  • Recording data changes done timely
  • Reviewing changes done to the table
  • Recover accidental data changes
  • Recovering application errors
  • Slowly changing dimensions
  • Repairing record-level corruption

Temporal tables or system-versioned tables is actually an assertion table, which means that it records the complete details and entries like update or deletion made to the databases based on physical dates. Versioning is not supported by temporal tables, which means the versioning of records because of logical dates. This conduces that the time must be taken into consideration if you want to maintain the logical change like time.

How To Create A Temporal (System-versioned) Table?

Pre-requisites & Limitations:

  • A Primary Key has to be defined.
  • Two columns for recording start and end date should be defined with data type of datetime2. These columns are referred as SYSTEM_TIME period columns.
  • AFTER triggers are allowed but INSTEAD OF triggers are not allowed.
  • In-memory OLTP cannot be used.
  • Temporal and history table cannot be FILETABLE.
  • Statements like INSERT and UPDATE cannot reference the SYSTEM_TIME period columns.
  • Data available in history table cannot be changed.

Below mentioned script can be used to create a simple system-versioned table:

When you run this command as query, it will create two tables. One parent Temporal/System-versioned Table, and History table. Here the table with the name dbo.TestTemporal will be created. History table is nested under the parent table and if the name of history table is not specified, SQL Server automatically generates it as dbo.MSSQL_TemporalHistoryFor_objectidoftable.

Closer look at result:

History table possesses an identical set of columns but the constraints are removed. It carries its own set of indexes and statistics. In order to improve the performance, your own indexes can be created.

Conclusion

Temporal tables are significant additional feature of SQL Server 2016. As it will track the history of the records entered in the temporal tables. As the history records are maintained well, it is easy to recover the data at any point instead of only current data recovery. Possible use cases for temporal table can be type 2 dimensions in data warehouses, protection for accidental deletes or updates, auditing, etc.

Sunday, 9 August 2015

Accomplishing a Strategized SQL Server Disaster Recovery

Introduction

The appropriate SQL Server disaster recovery plan means to be prepared for tackling with physical as well as logical cases of database loss to bring the server back into a running state, and not just the recovery of data once it is already been lost. Different types of disasters could range from accidental deletion of data, failure of hard drive, server misconfiguration resulting in failure of deployments, etc. However, when a disaster actually hits it happens to take place in the most instant and unfamiliar ways causing the administrators to take unskilled actions against it, resulting in the worsening of the situation.

Dealing With Master MDF File Corruption

On the installation of SQL Server, five different types of system database files are automatically created, namely; Resource (in 2005 and above versions of Server), master database, model, tempdb, and msdb. Corruption of master.mdf usually results in a catastrophic loss regaining which either requires restoration or rebuilding of the database entirely. Users highly rely upon reinstalling the entire server from the scratch in case of such disasters, as part of their recovery plan. Instead, the rebuilding of database followed by its restoration from the last best known backup is considered more reliable and solution generative. However, rebuilding is known to be a kind of sluggish procedure that may take up a lifetime causing a lot of time being consumed in trial and error method only, mostly when performed on a cluster.

Recovery of Backup Meant for Database Restoration

Backups are not the only escape from database related disasters and not even the ultimate way to attain continuity. Though, backups have proven to be the foremost choice of administrators to bring back lost database to its full-fledged state. Microsoft offers a variety of backup options, for SQL Server database, to choose from wherein the size of storage done by server determines the right plan for its backup. However, the mere existence of a backup on the machine doesn’t necessarily imply its usability. An existing backup if not tested for restoration process since creation could possibly be troublesome at the very time of disaster as things will take place haphazardly.

How to restore the database, which component to be restored or how to restore all components – and many such baffling queries tend to arise at the time of performing backup restoration. Thus, regular or at least alternate testing ensures whether the backup is in a state of restoration or not. As at the end if you find backups to be corrupted at the time of requirement, then they have failed the very purpose of existence itself. And you can

Restoration of Database through Transaction Log

Transaction logs maintain the history of tasks performed on a database, whether a query inserted, dropped, or so on. Being an integral part of each database on the SQL Server, it also holds a lot of importance in the scenario of disaster recovery, however; the only condition is that the log must not be in a corrupt state to come in use for the respective purposes. Every modification that takes place in the database is logged into the transaction in the form of a log record in a sequential manner. In case of a system failure, bringing a database back into a consistent state the transaction log file is required. Unless the complexities and consequences of deleting or moving a transaction log file for an essential database is known and understood, the action must not be taken.

Accessing SQL Database During Server Downtime

The term disaster recovery was coined on the basis of maintaining server and database continuity despite disasters causing physical damage to the server resulting in compromise with database. Like any high end servers, SQL Server administrators are usually prepared with backups and disaster management plans to deal with the consequences. However, backups play no role in bringing back business continuity when the server is in downtime leaving the database in an orphaned state. On studying the cases of SQL Server downtime, applying patches of service packs majorly resulted in the end of server operation. Moreover, cases like unknown technical glitches like; server crash, bug infection, administration error, and more have resulted in the necessity of maintenance. Therefore, the server database even in a healthy state remains to be of no use when the server itself is not in an up and running state to support its accessibility.

Solution: Server administrators employ many different workarounds in order to keep server operation and database integrity maintained. Therefore, making the tasks more cumbersome rather than streamlining it. Master database backup, log backup, server maintenance without compromising operations, and much more has to be done by the admins in order to achieve optimal disaster recovery. A variety of commercial solutions in the market offer rather more helpful ways to deal with SQL Server and its storage related disaster, compared to the standard methods employed.

Conclusion

SQL Server Recovery Manager serves a unified platform for performing most of the SQL Serve disaster recovery serving procedures, including; database recovery, backup recovery, and standalone access of database (without SQL Server), usage of transaction log entries for relatively quicker database restoration, decryption of database, and more. The application has distinguished modules to serve each of the defined purposes and is purchasable under respective user based licenses. However, a demonstration version of the same makes it possible for the application to be tested thoroughly for its potential.

Monday, 1 June 2015

Fix login issues in SQL server using SQL Server Authentication

Introduction

For the security of user’s database, SQL server provides some authentication modes by which an unauthorized person cannot access user’s database. In this section we will know about the types of authentication modes provided in SQL server and learn how to deal with login failure issues on SQL server.

At first we will discuss how to configure the authentication mode in SQL server.

Authentication Mode Configuration

The SQL server provides two types of Authentication modes during the setup. One is Windows Authentication Mode and second is SQL Server Authentication Mode. It is important to choose one of these modes for the database engine. The Windows Authentication Mode allows you to connect through Windows NT 4.0 or Windows 2000 user account and disable you for SQL Server Authentication while the mixed mode allows you for both Windows Authentication and SQL Server Authentication. The Windows Authentication is always accessible for the user.

Let us know what happens when we use Windows Authentication Mode.

Windows Authentication Mode

When you use Windows authentication mode, the SQL server confirms the user name and password through the windows principal token in the operating System, which means that the windows confirms the user identity. The SQL server doesn’t inquire for any identity validation. The Windows authentication mode is more secure than SQL Server Authentication mode because it is a default authentication mode.

Security Features of Windows Authentication:

  1. Uses Kerberos security protocol
  2. Provides validation complexity for a strong password
  3. Supports account lockout after attempting multiple invalid logins
  4. Manages password expiration

A Windows authentication connection is more secure than a SQL server authentication. Because the maintenance of users and groups are only managed by Windows 2000 or Windows NT 4.0

NOTE: Windows Authentication Mode is useful when SQL Server runs only on Windows 2000 or Windows NT 4.0.

SQL Server Authentication Mode

In SQL server authentication mode logins are created on the basis of SQL server. The user name and password are built in SQL server and stored in SQL server. When using SQL server authentication mode, you need to create strong passwords for all the SQL server accounts. The SQL server authentication mode permits SQL server to support applications, which is provided by third parties and expects SQL server authentication. It also permits the SQL server to use web based applications by which users create their own identities. But it cannot use Kerberos security protocol. We can use the SQL server authentication mode when we run SQL server on Windows 98 because Windows 98 doesn’t support Windows Authentication mode.

NOTE: In SQL server authentication mode the username and passwords are saved in a SQL server’s master database and when we use SQL server logins, the username and passwords are passed through a network, which makes them unprotected.

When you install SQL server, it installs with a login named SA (System administrator). You need to create a strong password for the SA.

To enable SA login on SQL server follow the simple steps given below:

  1. Click on Object Explorer>> click on Security>> click on Logins
  2. Right click on SA>> click on Properties
  3. You need to create and confirm a password for the login on the General page
  4. On the Status page>> in the Login section>> click Enabled>> then click Ok

What If I Can’t Access SQL Server & Keep Getting Error 18456?

There are a number of reasons, from which the login failed error 18456 can occur. Sometimes the error 18456 displayed that the server name is correct, but the connection is not established due to a number of reasons. The error is same for all other versions of SQL server. The error message 18456 does not show all the information regarding to the error, rather it hides all the information from unauthorized users in case someone tries to misuse the SQL server. But you can check the detail of this error 18456 if you are the administrator of SQL server.

Causes and Troubleshooting of Error 18456

1. Unrecognized User: The main reason of this error is that the mixed mode authentication is enabled and you are trying to login with Windows Authentication with the user who is not recognized by SQL server. This error may occur while you are using user account control on Windows 7 or Windows Vista. You should use “Run as Admin Option” if you are using Windows 7 or Windows Vista.

2. Incorrect Password: The second reason could be that you are using the SQL server authentication and the password may be incorrect or maybe expired.

3. Disabled Authentications: One other cause of this error is that the SQL server authentication or Windows Authentication is not enabled by SQL server itself.

Sometimes, it happens when the sysadmin had changed the password of username SA and now he is not able to recall the password. In such case you need to reset SA password.

How to Reset SA Password?

SQL server provides you some facilities to reset your SA password.

You can reset your SQL server password by using the other SQL server account who is the member of the sysadmin role

Follow the below steps to reset SA password:

  1. Go to Object Explorer >> open Security Folder >> open Login folder
  2. Then right click on SA Account >> go to Properties
  3. Change SA password >> then click OK
  4. NOTE: To check the new password, restart the SQL server and all its other services then test the new password.

    NOTE: It is important to turn off the single user mode in SQL Server before attempting above procedure.

    Conclusion:

    In this article we learned that how many authentication modes we are using in SQL server and how we use them. Also, did we learn about error 18456 and how do we reset the SA password because the SA password in SQL server provides much security. But unfortunately, if we forget the SA password or if we are facing any other issue related to SA password, because of reasons whatsoever, from which the login failed error 18456 can occur there is no way out. So in such case you need to have an SQL SA Password Recovery Tool with which you can regain access to your database and also secure it.

Monday, 25 May 2015

Read the Transaction Logs in SQL Server

INTRODUCTION

In this tutorial we will know about, how to read a transaction log in SQL server and also we will learn all the reading methods of a transaction log. From this tutorial you will know why MS SQL permits you to read the transaction logs. As we know very well about the transaction log, but for a consideration, I will give you a small introduction of transaction log, thereafter we will further discuss about it.

What is Transaction Log in SQL Server?

The Transaction log is a technique to keep your records secure in SQL server. The transaction log is a kind of backup for records through which, we can recover our database from a disaster. Also the transaction log is used to identify those records which are mistakenly deleted by the user. Without the transaction log a user cannot perform any task in SQL server.

From this small introduction, we learned how much a transaction log is important for us. So, now coming over to the topic, let us know more about transaction log.

What Events Captured In The Transaction Log?

Except some events, the transaction log captures all the important events like:

  • Begin or End the transaction.
  • All the insert, delete and update events.
  • Creation of indexes and tables
  • Drop events.
  • All the page allocation and De-allocations.
  • All the locks and truncation of tables.

These above events are captured in the transaction log but there are also some events such as select into, bulk insert bcp..etc. These logged minimally and depend on recovery model of the database.

Why Is It Important To Capture A Transaction?

As we know that the database is quite vulnerable to corruption. As the data is critically important for the user, it is equally important for the database. So keeping in mind that the database goes into a stable state where we cannot recover it, the SQL server captures the transaction to recover the data so, it can be used as a backup, if necessary.

The second reason is that, if a user accidentally deletes a database, the captured transaction can be used to recover the deleted data.

Note: Although the recovery of the data totally depends on recovery models and also depends on user, i.e. which recovery model has been fixed for the database.

How to Read A Transaction Log In SQL Server?

Microsoft doesn’t provide any tool to read the transaction logs, but it does provide some undocumented functions using which a user can read all the transaction logs. But Microsoft doesn’t support these undocumented functions, rather it gives a warning: “use these functions at your own risk”.

Here are some problems in fn_db_dumplog. Microsoft’s SQL team is aware of this problem and will fix it in future. These undocumented functions show what transaction logs captures. Here is an undocumented function fn_dblog, which helps you to read the transaction logs.

Let’s see how an undocumented fn_dblog function works in SQL server.

Reading Transactions using fn_dblog function

Following steps tells, how we can read the transaction logs in SQL server:

1. Create database readtranlog;
        GO

In the first step I have created a database & named it readtranlog.

2. Use readtranlog;
        GO
        Create table persons
        (sn int IDENTITY,
        Name CHAR (25)
        );

After that in second step I have created a table named persons.

3. Use readtranlog;
        GO
        Select count(*) from fn_dblog(null,null)

In the third step we can check what steps and processes have been used by the SQL server to create both; the database and table.

We can see that there are number of processes that have been generated for just creating a database and a table.

4. Use readtranlog;
        GO
        select [current lsn],
        [operation],
        [transaction name],
        [transaction id],
        [transaction sid],
        [spid],
        [begin time]
        From  fn_dblog(null,null)

In the fourth step i have shown a few records but we can see what data is available in the transaction log file. There are some important columns (Transaction Name) in the fourth step, which shows the database name as well as the table name. The [Transaction Id] is same for all the [Current LSN].

5. Use readtranlog
        GO
        Insert into persons values (1, ‘mike’);
        GO 
        Update persons
        Set Name =’peter’
        Where Name =’mike’
        GO
        Delete persons
        Where sn=’1’
        GO

In the fifth step we perform insert, update and delete operations to check how these transactions are logged in the database log file.

6. USE readtranlog;
        GO
        SELECT
        [current lsn],
        [transaction id],
        [operation],
        [transaction name],
        [context],
        [allocunitname],
        [page id],
        [slot id],
        [begin time],
        [end time],
        [number of locks],
        [lock Information]
        from sys.fn_dblog(NULL,NULL)
        where operation IN 
      ('LOP_INSERT_ROWS','LOP_MODIFY_ROW',
   'LOP_DELETE_ROWS','LOP_BEGIN_XACT','LOP_COMMIT_XACT')

In last, sixth step, it shows that how these three transactions are logged in the transaction log file.

Conclusion

The above six steps illustrate how we can use the fn_dblog function to read a transaction log in SQL server. We can detect those transactions which were accidentally deleted and also detect those transactions which we do not know about. But it is a too long and time consuming process and the fn_dblog function can only read and show the log data, but it cannot decode the log data so it is difficult to read the output of fn_dblog function. Because Microsoft does not deliver any log reader tools so it is good to have an SQL log reader tool by which transaction logs can easily be read and also be used for forensics.

Tuesday, 19 May 2015

Compromising with corrupted transaction logs files in SQL server

As we know that without any transaction we cannot perform any task in the database. To maintain every field in the database, we need to perform transactions for a particular change. These transactions are very important for every database and make it interactive for users.SQL server also dealing with these transaction logs and stores them into a separate file. Below is a brief description of these transaction logs.

At first we will discuss about transaction log and then we will further know about its storage.

Nature of a transaction log and the purpose of using it in SQL server

The nature of a transaction log is totally depends on its properties. Transaction log uses following four properties to complete its task in SQL server database.

  1. Atomicity
  2. Consistency
  3. Isolation
  4. Durability

Below is a small introduction of the above four properties:

1. Atomicity:
The Atomicity defines that if all the operations of a work unit are not executed properly, then the transaction will be considered a failed transaction and the previous Transaction will come in its initial position.
2. Consistency:
This property tells that, after a committed transaction the database is completely changing or not its previous state.
3. Isolation:
This property makes transactions to able to remain independent of each other.
4. Durability:
It ensures the persistency of a committed transaction in case of system failure.

This above four properties tell the nature of a transaction. The main purpose of using transaction log in SQL server is that we can bring back our database from a critical condition if any failure occurs in the system. Now the point is, where are these transaction logs stored in SQL server?

What Is A Log File And What It Stores?

After completing a successful transaction, it is very important to store the transactions in a separate file. The log file stores all the log events (insert, delete, update …etc) executed in SQL server and the size of a log file depends on users’ choice. It is necessary to have one log file for every database and you can have more than one log file for a database. The file extension for log files is “.ldf”.

Why Do We Need To Store The Transactions In The Log File?

It is very important to store the transaction logs into a log file, although they follow the A.C.I.D property. But after all, the transaction logs are very critical components of the database. If any system failure occurs, then you can recover your database from this file. Only the committed transactions are stored in a log file in a sequential manner. We can recover our update, delete or insert and creation tables and all other logged operations through this file and also can roll back the deleted and truncated transactions.

Mainly the log file contains all the transactions logs in a sequential order and maintains it for future use. If any failure occurs in the system, then you can manage and recover your database from this file.

Is a log file can be corrupt?

Yes, the log file can also be corrupt. Because it is also a system file so it can also be corrupted by some input/output subsystem. A log file can corrupt if the database is in the process and suddenly a power failure occurs.

Causes that can corrupt a log file

As if we consider the corruption reason of a log file, we see that the hardware part is more responsible for this corruption issue, they can be an operating system, device drivers, cables, networks and file system drivers... Etc.

In such condition just detect the defected hardware part and immediately change it. Otherwise again, it could be the cause of the problem.

Some other reasons that can corrupt a log file

  • Compression in data files size and unsupported folders can be the cause of corruption.
  • PSS is also found as a bug in the Microsoft product so it could be the cause of corruption.

SQL server provides some recovery options that can recover your corrupted database. But it depends on you that which option you should have to choose.

Which Option Is Better For Database Recovery?

Recovery depends on whether you are recovering a log file or the transaction logs. If you are recovering the transaction logs so it depends on your recovery models to which recovery model you have chosen to recover your database. But to recover the transactions is not a good option because the database recovery depends on your recovery model. So to rebuild the log file is a perfect option for you.

How To Rebuild A Corrupted Log File?

Implementing the following steps in SQL server can rebuild a corrupted log file.

  1. The sp_detach_db command helps you to detach your database. To detach your database at first you need to alter your database and switch it to emergency mode.
    Syntax:
    ALTER DATABASE database_name 
    { 
        < set_database_options > 
    } 
    [;]
    < set_database_options >::= 
    SET 
    { 
    { 
    < optionspec > [ ,...n ] [ WITH < termination > ] } 
    }
    < optionspec >::= 
    { 
        < db_state_option > 
    }
    < db_state_option >::= 
        { ONLINE | OFFLINE | EMERGENCY }
    
  2. Now you can modify the corrupt Transaction Log File(s) by performing delete or rename operations and then, create database, and use FOR ATTACH_REBUILD_LOG option to attach your database while rebuilding the Log File(s).
Syntax:
CREATE DATABASE database_name 
    ON < filespec > [,..n ] 
    FOR { ATTACH_REBUILD_LOG } 
[;] 

FOR ATTACH_REBUILD_LOG

It tells that how to create a database by attaching an existing operating system file. This option will only read/write the databases. If there is any damage in a transaction log file, then the log file is built again.

Note:There is No need to rebuild the log files if the log files are already available.

The ATTACH_REBUILD_LOG expect the following:

  1. The database should fully closed
  2. All the MDF and NDF file should be available

Important:

This following operation destroys the log backup chain. After the operation to make a full database backup is a good option to avoid the problem of recovery in the future. It is very important for every database to keep secure the log files. If the above method failed to recover your database, use a SQL log file recovery software.

Tuesday, 12 May 2015

Know about SQL server Objects

Introduction to SQL server Objects

In databases, when we talk about database objects, it means we are talking about SQL Tables. SQL Tables are also known as SQL Objects which manages all the records in a specific order in SQL server database. The data, stored in a Table are managed in a column and row manner. Each column in a Table stored a specific value. Each row and column must be unique in a Table. By assigning a key constraint on the table you can uniquely specify each record in a table and can also show the relationship between one or more tables. You can have a number of Tables in SQL Server database, depends on its storing capacity. The Tables are arranged by the database Schema.

Role of Tables in SQL server

A table is everything in a SQL server database. It contains information in a specific order and provides easy accessibility to the user through SQL queries. SQL queries are used to perform create, drop, alter, duplicate, rename..etc Tasks on the Table.

  • The Create command creates a table in SQL server.
  • The drop command deletes the table with its structure.
  • The alter command in SQL server modifies the structure of a table.
  • Through duplicate command you can create a new table, which holds the same properties as old one.
  • Rename command is used to rename an existing table.

Through SQL commands we can also perform the insert, delete, update…etc tasks on Table elements.

Create Table Syntax in SQL Server

CREATE TABLE table_name
(
Column _name 1 data _type (size),
Column _name 2 data _type (size),
Column _name 3 data _type (size),
. . . . . 
);

Types of Tables in SQL server

For a superior result and a good accessibility, SQL server basically uses four types of tables.

  1. Partitioned Tables
  2. Temporary Tables
  3. System Tables
  4. Wide Tables

From a small introduction, let’s consider the basic concept of each table.

1.Partitioned Tables
To quickly access to data, Tables are divided horizontally in SQL server. Thus may be Tables can be expanded across more than one file group in SQL server database. Partitioning makes more accessible to large tables and indexes.
2.Temporary Tables
SQL server uses two types of temporary tables. The first one is Local temporary tables which have only one sign (#) as the first character of their names and they only visible until the connection is not closed by the user. The second one is global temporary tables, which have two signs (##) as the first character of their names and they are visible whether the connection is closed or not. Both tables are stored in tempdb.
3.System Tables
System tables are those which cannot directly altered through a SQL query. The information of System tables is made available by the System Views. System tables are also used to track the database objects.
4.Wide Tables
It is a special kind of tables in SQL server, which uses column sets as well as sparse columns.It is important to limit both fixed and variable length data within 8019 bytes. One other thing is that the transaction or merge replications do not work with wide tables.

Tables Components

1.Field
A Field in a table is a single block or a set of blocks which contains records, related to the subject.
2.Record (row)
A record is a single or multiple rows, in a database table, which contains information according to table fields.
3.Column
A column is a single or multiple blocks, in a database table, which contains the information of a particular field in a vertical manner.

Constraints of a Table in SQL server

Constraints are the rules for a table or column, which provides accuracy, integrity and reliability of the data. There are two types of SQL constraints available in SQL server.

1.Column level constraints:column level constraints are those which applied only to one column.

2.Table level constraints:Table level constraints are those which applied to the whole table.

Some commonly used constraints of SQL server:

NOT NULL Constraints, DEFAULT Constraints, UNIQUE Constraints, PRIMARY KEY Constraints, FOREIGN KEY Constraints, CHECK Constraints and INDEX.

Note: Using constraints in a table prevent invalid entries in the table. But it cannot prevent to corruption issues of a table.

Corruption issue in a SQL Table

Issue: Sometimes while fetching a record from a table in SQL server; it displays an error message 823. It occurs when the systems operating system failed to perform the input/output operations.

Recovery Options

Solution:To solve this error, you need to restore the database from a good backup. However, if you don’t have a good backup of your database, the CHECKDB provides an alternate way to repair this error.

The REPAIR_ALLOW_DATA_LOSS is used to repair these errors. This method can be applied under a transaction, which allows rolling back the changes, made by the user.

It doesn't mean that, this repairing option will solve all the Errors; even it takes too much time to resolve the problem. To solve these issues you need to have a third party tool like SysTools SQL Recovery tool to recover your lost and corrupted database.

Thursday, 7 May 2015

Know How SQL Server Works Using Stored Procedures & Triggers

Amongst databases, every database has some specific pre-defined functions which are used to execute a particular task on it. SQL server also uses these pre-defined functions to execute any task in its database. Similarly, Trigger is also a special kind of stored procedure .In SQL, Triggers automatically execute whenever an event occurs in the database .Below is a detailed description of Stored procedure and Triggers.

Stored Procedures in SQL server

On SQL server, the query execution for any operation (insert, delete, update…etc...) depends on some procedures. Such procedures are called Stored Procedures. Because these procedures are pre-defined in SQL server and they are the library functions of any program. Without Stored Procedures you cannot execute any task on SQL server.

When you perform or execute any task on SQL server, it doesn’t execute directly. Before the execution, it will be checked in the library of the function and if all the functions in the query are matched, then only the query will be executed. Otherwise, it shows an error.

A Stored Procedure is nothing more than an already defined SQL code that you save and can access it over and over again. So, to prevent writing an SQL code again and again and execute it, you can save it as a Stored Procedure instead. The following diagram shows how SQL works with stored procedures.

Types of Stored Procedure

  1. User-defined
  2. Temporary
  3. System
  4. Extended Stored Procedure

SQL server uses four types of stored procedure methods. below is a small description of each method.

1. User-defined
This type of procedure can be created in a user defined database or in all system databases, but cannot created in the resource database.
2. Temporary
Basically There are two types of temporary procedures are available in SQL server. First one is Local and second one is Global. A Local temporary stored procedure exists in the current session.
3. System
There are so many system stored procedure available in SQL server and it can be executed from any database without specification of database context.
4. Extended Stored Procedure
From Extended Stored Procedures you can create your choice external routines these stored procedures can dynamically load into the server and run easily.

Benefits of stored procedures

  • Stored procedures are Reduce the network traffic between server and client.
  • Maintain all the data structure and provide Stronger security.
  • Provide security from SQL injection invasion.
  • Stored procedures are pre-compiled statements and can be executed quickly.

Drawbacks

  • Without visual studio it is difficult to debug the stored procedure.
  • It is difficult to convert the stored procedure if it is written by the best developers.
  • Stored procedures are slower than dynamic SQL’s.
  • Business logic cannot be written at the database side.

When to use stored procedures

In some other systems, stored procedures may use to control the transaction management. Stored procedures mainly run inside of a transaction, such that transactions are effectively transparent to them. Stored procedures are just like with writing a good quality application if you can write a good quality stored procedure, then you can implement them otherwise, another solution might be best for you.

Issues with stored procedures

The stored procedures are very useful objects of SQL Server database and provide constitutive performance, abstraction, code rescue, reduced network traffic and it has some of its advantages. But there are a number of issues that are encountered while using the stored procedures.

Following Error message can be occur when performing a task on SQL Server:

Error 0: [SQL-DMO] Object 'dbo.SP_ProcName' was not scripted

In such condition, you cannot delete the stored procedure by selecting 'Delete' option. At this point, finding the cause of this issue and carrying out SQL Repair by resolving it becomes essential.

In such condition, you need to repair and restore damaged database file and retrieve data from it.

Manual method to recover Stored Procedures

  1. Log on to the application-tier server.
  2. Click Start and point to Control Panel and then click Add or Remove Programs.
  3. Click Microsoft Visual Studio 2008 Team Foundation Server - LOC and then click on Change/Remove.
  4. On the Maintenance Mode Options, click on Repair or Reinstall, and then click on Next.
  5. On the Team Foundation Server Service Account page, check the type of account that is used for installation.
    • If it is specified to use a system account, then click on Next.
    • If Specify an account is specified, click the Password box, type the password for the specified account, and then click Next.
  6. On the Reporting Services Data Source Account page, check the type of account that is used for installation.
    • If Use Team Foundation Server service account is specified, click Next.
    • If Specify an account is specified, click the Password box, type the password for the specified account, and then click Next.
  7. On the Ready to Repair page, click Repair.
  8. The Maintenance - Repair/Reinstall page shows installation progress.
    You may ask to specify the location of the original installation media.
  9. On the Maintenance - Setup Complete page, click Finish.
  10. When prompted, click Restart Now, and wait for the server to restart.

The above method shows us how we can manually recover SQL servers lost Stored Procedures. Now we come to know about Triggers.

What is Trigger in SQL server?

As I told you before the SQL Trigger is an exclusive type of stored procedure which executes automatically whenever an event occurs in the SQL server database. It is special because it is called automatically not directly like a stored procedure.

The difference between a Trigger and a stored procedure is that whenever a DML or DDL event is made against the database a Trigger is called automatically whereas stored procedure must be called specifically.

Basic Syntax of Trigger is as follows

CREATE TRIGGER name ON table
   [WITH ENCRYPTION]
   [FOR/AFTER/INSTEAD OF]
   [INSERT, UPDATE, DELETE]
   [NOT FOR REPLICATION]
AS
BEGIN
--SQL statements
...
END

Types of Triggers in SQL server

There are three types of Triggers in SQL server mentioned below:

  1. DDL Triggers
  2. DML Triggers
  3. LOGON Triggers
1. DDL Triggers
In SQL server database, whenever ALTER, CREATE, DROP...Etc operations are performed; the DDL Triggers are fired automatically. The DDL Triggers do not fire when an INSERT, UPDATE and DELETE operations are performed in the database. DDL Triggers used to create the database object schema.
2. DML Triggers
As opposed to DDL Triggers, DML Triggers do not execute in response to ALTER, CREATE, DROP, DENY, REVOKE, GRANT. First of all they execute in response to DML statements which include UPDATE, INSERT and DELETE statements on a table. These DDL statements, fire DML Triggers. DML triggers are often used for applying business rules and data integrity.
3. LOGON Triggers
These types of Triggers are executed when a LOGON event occurs on SQL server. LOGON Triggers often used to audit and control server sessions, by tracking login activity or extent the number of sessions for a specific login. This event executes when a user perform login operation on SQL server. This event depends on user’s login operation.

Triggers have some of its advantages and disadvantages. because Triggers come with some potential pitfalls. Here we can see the advantages and disadvantages of triggers:

Advantages of Triggers

  • SQL, Triggers provide an option to check the integrity of data.
  • Without SQL, Triggers you cannot insert any invalid data into database.
  • Triggers are also used for calling stored procedures.
  • You don’t need to invoke the Trigger. It executes automatically when an event occurs in the database.

Disadvantages of Triggers

  • We can see all the executed events in SQL server but we cannot see Trigger’s execution event in SQL server.
  • In case of transaction loss it is difficult to troubleshoot with Trigger.
  • Triggers may increase the complexity of a database.

Triggers are very important to design a database because they are high maintenance database objects. But there are some cases, such as; sometimes you cannot see Triggers application on the desktop, although you see in Task Manager that the application is running.

Issue with Triggers

  • Sometimes inside the Network Service account, The Message Queuing Triggers service runs by default; the desktop functionality, interaction is only possible with the Local System account.

Manual methods to solve the issue

  • It is required to set up the Triggers service and switch to its interaction with desktop mode.
  • Computer management > services > pane > Message Queuing Triggers(double click).
  • Now Click the Log On tab and then allow service.

Conclusion

Triggers and Stored Procedures are very important parts of the database because these two primary events are one of many events in SQL server database.

If the both(Stored procedure and Triggers) recovery methods discussed above failed to resolve the problem, then use SysTools SQL Recovery Tool that helps to recover your SQL database quickly.

Thursday, 30 April 2015

Know About .MDF and .NDF In SQL Server

In SQL Server Records (Data) and log information is not stored in one file. There are three types of individual files used by SQL server to store its information. These files are Primary data file and secondary data file. These two individual files are used by one SQL server. These different files have their different file extensions. Below is a brief description of these two files.

Primary data files (.Mdf file)

In a nutshell, .Mdf, also known as a master data file of SQL server and is the Primary database file where the data stored physically. It is a very important file of SQL server. Because it stores very crucial information of the database like tables, views, stored procedure, triggers… etc. and it also links to other database files. In another way we can say, a Primary data file is a file which contains the schema with data. It is necessary to have one primary data file in every database.

When we create a database through create command, it creates a data file with .Mdf extension. This extension is recommended for Primary data file.

Secondary data files (.Ndf file)

The Ndf file of the database is also known as a secondary data file. These are optional and user defined data files and also store users' data. It is not important to have a secondary data file. If a database uses maximum size for a single file, then we can use secondary data file. Therefore, some databases not required any secondary data file. A simpler way, we can say that a secondary data file is an extra file by which you can continue to grow your database.

While it is not necessary to have a secondary data file, but you can have more than one secondary data file for a single database.The recommended file extension for a secondary data file is .Ndf.

Note:Though the required file extensions for these two files is .Mdf and .Ndf. The SQL server Never enforces you to use these file extensions.

These two files (Primary and secondary) are located and stored in the Primary file of the database and in the master database. Whenever a SQL server database engine wants to use file location of those two files, it retrieves the data from the master database.

Sometimes complete database inaccessibility may cause of corruption in any of these data files.

.Mdf and .Ndf File Corruption issues on SQL server

The SQL Server database files (MDF and NDF) involve important data so they should be well maintained. It should be frequently retrieved, managed and stored, so the integrity maintenance of the data is a very important term in SQL server database. If it is not managed properly, it can be cause of corruption

There are many corruption issues arising in SQL Server. Some of the common error messages that could appear while accessing corrupt MDF file are mentioned below.

Error messages:

  • Table error: Object ID 0, index ID 0, and page ID (1:105). The PageId in the page header = (0:0)
  • Buffer provided to read column value is too small
  • Conflict, occurred in database'db_name', table 'table_name', column 'column_name'
  • Memory or buffer error, space provided to read column is too small

In such circumstances, you should use the DBCC CHECKDB command-line tool to repair data corruption.

Run following command to check the physical consistency of the database:

'DBCC CHECKDB ('neo') WITH PHYSICAL_ONLY; GO'

The two manual repair options used with DBCC CHECKDB are:

REPAIR_ALLOW_DATA_LOSS
This option will usually try to repair all reported errors and might also cause some data loss. This option only uses as the last resort
REPAIR_REBUILD
This option does not elevate the data loss. For example, if a non-clustered index is damaged, you can be easily repaired the index by rebuilding it.

If the methods discussed above fail to resolve the problem, use third party tool SysTools SQL Recovery software.

Wednesday, 15 April 2015

Tips To Fix MS SQL Server Master Database Corruption

There are two types of databases that are supported by SQL Server: System database and User database. The system databases are used by the SQL Server, SQL Server services and functions while the user database are used to store data of user’s choice, the data for which SQL Server is being set up.
There are five types of system database: master, msdb, model, resource, and tempdb. Here, we are going to discuss the Master database of SQL Server, its importance, and options available to troubleshoot if it gets corrupted.

SQL Server Master Database: An Introduction

Master database contains the primary configuration details of SQL Server. The system database tables along with the Master DB is known as system tables that records the server parameters as well as detailed information about every user and database.

The master database gets stored in physical file called master.mdf file and its corresponding transaction logs gets saved into masterlog.ldf file. Generally, this database is stored at default location and is small in size. For this reason, sharing the drive with the SQL Server instance will not cause any performance issues. If the master database gets corrupted, system database will not start along with the user database.

How to detect that Master DB is Corrupt?

Before we actually move to the topic as how to recover a corrupt master database, we will have an idea as how to discover that the DB is actually corrupt. Here, we break a master DB to exemplify its consequences.

Let us have a hypothetical scenario that the enterprise confronted a power surge and when the server was rebooted, it failed to start with error registered in the event log.

How to Fix Corrupt Master Database?

Here we are going to discuss three options to resolve MS SQL Server master database corruption issue. Any of them is adopted according to convenience and availability of resources for their proper execution.

#1: Rebuild the master Database

To repair the system database of including master DB, run SQL Server setup.exe. Open Command Prompt and move to \servers folder. The syntax for rebuilding the database in SQL 2005, the syntax used is:
Start /wait setup.exe /qn INSTANCENAME=<InstanceName> REINSTALL=SQL_Engine REBUILDDATABASE=1 sapwd=<NewStrongPassword>

Note: The parameter “qn” will suppress the dialog boxes and errors while processing the command.
Since the model, msdb, and master database reside on same disk, it is likely that a disk failure may lead to loss of all three system databases, The process mentioned above will help to rebuild all three DB together.

#2: Restore Database from Backup

To restore master database, it is necessary to have full backup of the master.mdf and master.ldf file available. Before starting up the restoration process, it is important to start SQL in single user mode. For this, follow the steps mentioned below:


1. Open “SQL Server Configuration Manager” and then click on “SQL Server 2005 Services”.
2. Now, select the SQL Server instance, right-click on it and choose “Properties”.


3. On the window that gets opened, click on “Advanced” tab. For Startup Parameters box, prefix the parameter “-m;” before already existing parameters.


Make sure that the added parameter is removed one the required task is done. Once this is done, you can connect to SQL Server using “sqlcmd” and run following command to restore the database:

RESTORE DATABASE master FROM DISK = ‘C:\BackupLocation\master.bak’ WITH REPLACE;GO


#3: Recover Master Database .mdf File

Another option that can be adopted to start up SQL Server in case of master database corruption is MDF Recovery tool that helps to restore SQL Server Master Database into healthy form. There are solutions that give the benefit of recovering system databases (including master.mdf) database. The best part about these software applications is they give a solution repair system database for any SQL Server which means even if you upgrade or degrade SQL edition, they will be with you as helpful DPR plan.

Rebuild, Recover, or Restore: Which is the Best Option? 

In our day to day life, we use our mobile phone that stores so many contacts in it. This saves us from memorizing them and of course do not demand to write all these contacts. If the cell phone is lost, you can get back to normalcy only when you get a new phone. That means you have to manually add all the contacts to the phone because the contact details are lost with the old phone.

A master database plays the same role in SQL Server as contacts in the mobile phone. If you lose access to it, all information needed to start up the day-to-day functioning will be lost. Rebuilding master database is like getting a new phone where you have to manually add information about user-accounts (login details), the permissions assigned to them, the previous configuration details and much more. On the contrary, if the database is restored using backup, it is always positive point DB will be received in the same state as it was before.

Conclusion:

The master database stores the all the metadata about the SQL database be it configuration details, login details, file location, information about pointers and much more. With the master database in corrupt or inconsistent state, it is not possible to start SQL Server and run any query. The above mentioned solutions are tried-and-tested for their successful master database recovery and can be adopted.

Saturday, 31 January 2015

Types of SQL Server Commands

SQL commands are used as an instruction to communicate with the database to perform specific tasks like create database, delete, update records, alter etc. These commands perform different types of task to execute within the database. With the help of these commands user can create different objects. There are four types of commands that are categorized given below according to their importance or role in database.

DDL (Data Definition Language): These statements are used to define the structure or schema of the database. For example:
  • Create: used to create objects in the database
  • Alter: used to alter or change the database structure
  • Drop: used to delete objects in the database
  • Rename: used to rename the object in the database
  • And truncate, comment etc.
DML (Data Manipulation Language): These statements are used to manipulate or manage data within schema objects. For example:
  • Select: It is used to get back or retrieve data from the database
  • Insert: It is used to insert data into table.
  • Update: It is used to update existing data in the table.
  • Delete: It is used to delete records from the table.
  • Merge: Used to merge insert or update operation.
DCL (Data Control Language): These statements are used to control access to the data within the database. For example:
  • Grant: It is used to give user access to the database.
  • Revoke: It used to release or drop user access to the database by grant command.
TCL (Transaction Control Language): These statements are used to manage changes made by DML statements and helps to group statements in logical transactions. For example:
  • Commit: Used to save process.
  • Rollback: Used to rollback or restore the transaction to the previous state of commit.
  • Savepoint: Used to save a point in transaction which can be further executed.
  • Set Transaction: Used to set transaction level.

Saturday, 10 January 2015

An Overview of the SQL Server System Databases

The endowment of Microsoft’s extensive data storage platform, SQL server carries out breakthrough efficiency in storing and maintenance of data. It is a highly featured database that is primarily designed to cope with the business environment. The SQL server supports ANSI-SQL and T-SQL query languages. The query languages are used to manage and retrieve data in any Relational database Management system.

Moving to the Database Concept in SQL

A Relational Database System like SQL server consists of many objects. Among them, the database is considered as the most significant-level object. A database is defined as a structured group which includes objects such as table, views, stored procedures related to the data that is stored in the tables of database. SQL server’s powerful RDBMS architecture deployment supports the storage of data in four system databases.
  1. master
  2. model
  3. msdb
  4. tempdb
View all these databases in SSMS (SQL Server Management Studio)

Let us discuss the role and details of data stored by each of the database in SQL server.

Master Database

As the name implies, the master database forms the primary database of SQL server. It maintains a set of system tables which keeps a complete track of the overall system. The master database contains the following list of information.
  • Details of SQL server configuration settings
  • Login information details of the account
  • Transactional locks and processes
  • Regarding registrations related to server
  • Logins from remote sites

Path Location of Master Database Files on System

On installing SQL server, the master.mdf files and its corresponding log files (master.ldf) is created in the location by default
If the master database gets corrupted and is not recoverable from the backup, then a user has to again rebuild the master database. Therefore, it is always advised to maintain a current backup of the master database. As, everything crucial to SQL server is stored in the master database, so it cannot be possibly deleted. For this reason master database is often referred as mother or heart of all SQL Server.

Model Database

The model database sets a model for the entire newly created database. Technically, it serves as a template for the SQL server in order to create a new database. Whenever a user tends to create a new database, the data present in model database are moved to new database to create its default objects which include tables, stored procedures, etc. Primarily, the requirement of model database is not specific to creation of new database only. Whenever the SQL server initiates, the Tempdb is again created by using model database in the form of a template. The Model database does not contain any data by default.

Locating the Model Database Files

During the installing process of SQL server, the model database file and its related log file (model.ldf) are saved in in the same location as for master file.

MSDB Database

The Microsoft database (MSDB) is used by SQL server Management Studio, SQL Server Agent and SQL server, to store data related to backup and restores history and information pertaining to task scheduling. Additionally, the MSDB database stores data pertaining to log shipping, replication and maintenance etc.

List of Data Which Are Present in the MSDB Database
  • Information associated with SQL Server Agent like job history, scheduling of jobs, notifications, etc.
  • Configuration data about log shipping
  • Maintenance data related to backup created online
  • Configuration details about replication

As the volume of configuration related information keeps on increasing in the msdb database, it is always recommended to back it up at regular intervals. In the event msdb database getting corrupted, a user has to rebuild the database by making use of SQL build script which was set up during the installation procedure of SQL server on the system.

Location of SQL Build Script

The SQL build script for rebuilding MSDB database is instmsdb.sql and it is present in path. C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Install

When the msdb database is not present, the SQL build script will first ensure to again create the database and then rebuild the associated objects. A user can carry out the processing of instmsdb.sql script with the help of Query Analyzer application. After successfully rebuilding the msdb database, a user has to again configure the configuration settings associated with log shipping, replication and task scheduling.

Tempdb Database

From its name temporary, it refers that Tempdb database serves as a temporary storage place for processing of data such as tables or temporary stored procedures with their respective objects. It can be said that the tempdb works as a resource for users who are working on a particular instance of SQL server. The tempdb database stores the following list of data
  • Temporary cursors, variables, tables and stored procedures etc
  • Objects that are handled by SQL database engine to carry out jobs like sorting
  • Row versions which are created during the transaction pertaining to modification of data

Location of Tempdb files

The tempdb.mdf files and tempdb.ldf can be located on the same path for Master file

Initially the tempdb file is set to a size of 8.0MB but a user can further increase its size by making use of the database properties or by initiating the command ‘Alter DATABASE’ for removing the processing overhead.

Instances Of Corruption in Database

Often the database of SQL database gets corrupted or damaged by corruption issues and in such cases if there is no proper backup of the database, then a user has to depend on third party solution to get access to the data that is stored in the database of the server. Learn more about database corruptions here

Friday, 2 January 2015

How to configure SQL Server Database Mail in 2014

SQL Server database mail keeps ail copies of the sent or outgoing email messages and user can see them in the MSDB database views section like sysmail_allitems, sysmail_unsentitems, sysmail_faileditems and sysmail_sentitems etc. User can view the sysmail_event_log for log details and to check the email message status run the query against this view in query editor. In SQL Server database mail, it is possible to add multiple user profiles at the same time and their requirement will be according to the need.
Follow Simple Manual Steps to Configure Database Mail

1) Open SSMS and go to the Management node on left panel.

2) Expand the Management node then go to the Database Mail option, Right click on the Database Mail, and then select Configure Database Mail.

3) After that a new pop-up Windows will be opened then click on the next button.


4) New Windows will show options where user have to choose 1st one i.e. Setup database mail then click on next button.


5) On the next Window fill up the profile filed as your name, description field is not mandatory then click on Add button.


6) New Window will be shown as below, fill up all the fields as below:

Here I have used my managed account which is same as new, so fill up Outgoing SMTP fields

  • Email address- your email address
  • Display Name- your display name
  • Reply email – same as above email address
  • Server name – smtp.gmail.com (here I have used gmail smtp address) and Port no- 587

Select Authentication- Basic Authentication, type username, email passwords etc.
After all fields completion, click on the next button.


7) New Window will show profile name and on its next row select yes to default profile. Then click on next.


8) Next Window will show system parameter, view them and click on Next button.


9) New Window will show status of the created profile. Then click on the finish button.


10)  At last window will show success status of the account then click close.



11) 
To check the mail database, right click on the database mail then go to Send Test E-Mail


12) Then type email address on To field then message, then click on send email button.