[box type=”note” align=”” class=”” width=””]This article is an excerpt from a book written by Marek Chmel and Vladimír Mužný titled SQL Server 2017 Administrator’s Guide. In this book, you will learn the required skills needed to successfully create, design, and deploy database using SQL Server 2017.[/box]
Today, we will explore how SQL Server handles data as it is of utmost importance to get an understanding of what, when, and why data should be backed.
Data structures and transaction logging
We can think about a database as of physical database structure consisting of tables and indexes. However, this is just a human point of view. From the SQL Server’s perspective, a database is a set of precisely structured files described in a form of metadata also saved in database structures. A conceptual imagination of how every database works is very helpful when the database has to be backed up correctly.
How data is stored
Every database on SQL Server must have at least two files:
- The primary data file with the usual suffix, mdf
- The transaction log file with the usual suffix, ldf
For lots of databases, this minimal set of files is not enough. When the database contains big amounts of data such as historical tables, or the database has big data contention such as production tracking systems, it’s good practise to design more data files. Another situation when a basic set of files is not sufficient can arise when documents or pictures would be saved along with relational data. However, SQL Server still is able to store all of our data in the basic file set, but it can lead to a performance bottlenecks and management issues. That’s why we need to know all possible storage types useful for different scenarios of deployment. A complete structure of files is depicted in the following image:
Database
A relational database is defined as a complex data type consisting of tables with a given amount of columns, and each column has its domain that is actually a data type (such as an integer or a date) optionally complemented by some constraints.
From SQL Server’s perspective, the database is a record written in metadata and containing the name of the database, properties of the database, and names and locations of all files or folders representing storage for the database. This is the same for user databases as well as for system databases.
System databases are created automatically during SQL Server installation and are crucial for correct running of SQL Server. We know five system databases.
Database master
Database master is crucial for the correct running of SQL Server service. In this database is stored data about logins, all databases and their files, instance configurations, linked servers, and so on. SQL Server finds this database at startup via two startup parameters, -d and -l, followed by paths to mdf and ldf files.
| These parameters are very important in situations when the administrator wants to move the master’s files to a different location. Changing their values is possible in the SQL Server Configuration Manager in the SQL Server service Properties dialog on the tab called startup parameters. |
Database msdb
The database msdb serves as the SQL Server Agent service, Database Mail, and Service Broker. In this database are stored job definitions, operators, and other objects needed for administration automation. This database also stores some logs such as backup and restore events of each database. If this database is corrupted or missing, SQL Server Agent cannot start.
Database model
Database model can be understood as a template for every new database while it is created. During a database creation (see the CREATE DATABASE statement on MSDN), files are created on defined paths and all objects, data and properties of database model are created, copied, and set into the new database during its creation. This database must always exist on the instance, because when it’s corrupted, database tempdb can be created at instance start up!
Database tempdb
Even if database tempdb seems to be a regular database like many others, it plays a very special role in every SQL Server instance. This database is used by SQL Server itself as well as by developers to save temporary data such as table variables or static cursors. As this database is intended for a short lifespan (temporary data only, which can be stored during execution of stored procedure or until session is disconnected), SQL Server clears this database by truncating all data from it or by dropping and recreating this database every time when it’s started.
As the tempdb database will never contain durable data, it has some special internal behavior and it’s the reason why accessing data in this database is several times faster than accessing durable data in other databases. If this database is corrupted, restart SQL Server.
Database resourcedb
The resourcedb is fifth in our enumeration and consists of definitions for all system objects of SQL Server, for example, sys.objects. This database is hidden and we don’t need to care about it that much.
It is not configurable and we don’t use regular backup strategies for it. It is always placed in the installation path of SQL Server (to the binn directory) and it’s backed up within the filesystem backup. In case of an accident, it is recovered as a part of the filesystem as well.
Filegroup
Filegroup is an organizational metadata object containing one or more data files. Filegroup does not have its own representation in the filesystem–it’s just a group of files. When any database is created, a filegroup called primary is always created. This primary filegroup always contains the primary data file.
Filegroups can be divided into the following:
- Row storage filegroups: These filegroup can contain data files (mdf or ndf).
- Filestream filegroups: This kind of filegroups can contain not files but folders to store binary data.
- In-memory filegroup: Only one instance of this kind of filegroup can be created in a database. Internally, it is a special case of filestream filegroup and it’s used by SQL Server to persist data from in-memory tables.
Every filegroup has three simple properties:
- Name: This is a descriptive name of the filegroup. The name must fulfill the naming convention criteria.
- Default: In a set of filegroups of the same type, one of these filegroups has this option set to on. This means that when a new table or index is created without explicitly specified to which filegroup it has to store data in, the default filegroup is used. By default, the primary filegroup is the default one.
- Read-only: Every filegroup, except the primary filegroup, could be set to read- only. Let’s say that a filegroup is created for last year’s history. When data is moved from the current period to tables created in this historical filegroup, the filegroup could be set as read-only, and later the filegroup cannot be backed up again and again.
| It is a very good approach to divide the database into smaller parts– filegroups with more files. It helps in distributing data across more physical storage and also makes the database more manageable; backups can be done part by part in shorter times, which better fit into a service window. |
Data files
Every database must have at least one data file called primary data file. This file is always bound to the primary filegroup. In this file is all the metadata of the database, such as structure descriptions (could be seen through views such as sys.objects, sys.columns, and others), users, and so on. If the database does not have other data files (in the same or other filegroups), all user data is also stored in this file, but this approach is good enough just for smaller databases.
Considering how the volume of data in the database grows over time, it is a good practice to add more data files. These files are called secondary data files. Secondary data files are optional and contain user data only.
Both types of data files have the same internal structure. Every file is divided into 8 KB small parts called data pages. SQL Server maintains several types of data pages such as data, data pages, index pages, index allocation maps (IAM) pages to locate data pages of tables or indexes, global allocation map (GAM) and shared global allocation maps (SGAM) pages to address objects in the database, and so on. Regardless of the type of a certain data page, SQL Server uses a data page as the smallest unit of I/O operations between hard disk and memory. Let’s describe some common properties:
- A data page never contains data of several objects
- Data pages don’t know each other (and that’s why SQL Server uses IAMs to allocate all pages of an object)
- Data pages don’t have any special physical ordering
- A data row must always fit in size to a data page
These properties could seem to be useless but we have to keep in mind that when we know these properties, we can better optimize and manage our databases.
| Did you know that a data page is the smallest storage unit that can be restored from backup? As a data page is quite a small storage unit, SQL Server groups data pages into bigger logical units called extents. An extent is a logical allocation unit containing eight coherent data pages. When SQL Server requests data from disk, extents are read into memory. This is the reason why 64 KB NTFS clusters are recommended to format disk volumes for data files. Extents could be uniform or mixed. Uniform extent is a kind of extent containing data pages belonging to one object only; on the other hand, a mixed extent contains data pages of several objects. |
Transaction log
When SQL Server processes any transaction, it works in a way called two-phase commit. When a client starts a transaction by sending a single DML request or by calling the BEGIN TRAN command, SQL Server requests data pages from disk to memory called buffer cache and makes the requested changes in these data pages in memory. When the DML request is fulfilled or the COMMIT command comes from the client, the first phase of the commit is finished, but data pages in memory differ from their original versions in a data file on disk. The data page in memory is in a state called dirty.
When a transaction runs, a transaction log file is used by SQL Server for a very detailed chronological description of every single action done during the transaction. This description is called write-ahead-logging, shortly WAL, and is one of the oldest processes known on SQL Server.
The second phase of the commit usually does not depend on the client’s request and is an internal process called checkpoint. Checkpoint is a periodical action that:
- searches for dirty pages in buffer cache,
- saves dirty pages to their original data file location,
- marks these data pages as clean (or drops them out of memory to free memory space),
- marks the transaction as checkpoint or inactive in the transaction log.
Write-ahead-logging is needed for SQL Server during recovery process. Recovery process is started on every database every time SQL Server service starts. When SQL Server service stops, some pages could remain in a dirty state and they are lost from memory. This can lead to two possible situations:
- The transaction is completely described in the transaction log, the new content of the data page is lost from memory, and data pages are not changed in the data file
- The transaction was not completed at the moment SQL Server stopped, so the transaction cannot be completely described in the transaction log as well, data pages in memory were not in a stable state (because the transaction was not finished and SQL Server cannot know if COMMIT or ROLLBACK will occur), and the original version of data pages in data files is intact
SQL Server decides these two situations when it’s starting. If a transaction is complete in the transaction log but was not marked as checkpoint, SQL Server executes this transaction again with both phases of COMMIT. If the transaction was not complete in the transaction log when SQL Server stopped, SQL Server will never know what was the user’s intention with the transaction and the incomplete transaction is erased from the transaction log as if it had never started.
The aforementioned described recovery process ensures that every database is in the last known consistent state after SQL Server’s startup.
It’s crucial for DBAs to understand write-ahead-logging when planning a backup strategy because when restoring the database, the administrator has to recognize if it’s time to run the recovery process or not.
To summarize, we introduced internal data handling as it is important not only during performance backups and restores but also for optimizing a database.
If you are interested to know more about how to backup, recover and secure SQL Server, do checkout this book SQL Server 2017 Administrator’s Guide.
