One thing we should always keep in mind that if we change database default path in SQL Server then it will not change or move the database file locations for your existing databases. If you want to move all existing databases or you want to change database files path to the new location then you need to manually do it for each database.

Once you will change default database file locations then all databases you will create on that SQL Server Instance will be created on new location. Suppose your existing SQL Server default database location is set in C drive and now you have decided to change it to D drive for data files and F drive for Log files then all databases you will create post this change will be created in these both drives. If you will mention any other specific drive during database creation then SQL Server uses that drive and not these database default locations. The SQL Server data file will be created in D drive and log file will be created in F drive but all the existing databases that were created earlier in C drive will not move to new SQL server database file location. If you want to move these databases or want to change database files location then you need to manually do it either by detach-attach method or by ALTER statement.

Change Database Default Locations in SQL Server

It’s very simple method to change default log file location or default data file location in SQL Server. Let’s start to change default database path in SQL Server.

• Launch SQL Server Management Studio and connect to your SQL Server Instance for which you must change default log file location or default data file location in SQL Server.
• Now right click at SQL Server Instance node and choose Properties option.
• You will get server properties window on your screen. Click at “Database Settings” from left side pane. You will get all server level details for SQL Server databases in right side pane. Look at the database default locations option given bottom of the right-side pane. Here you can see separate default location for data files, Log file and backup files.

• You can see database default locations for each file are showing in C drive. It means every database that will be created without mentioning their data or log file location will go to above given SQL Server database default locations.
• To change database default path, you need to browse current database default locations for each file to new the new location. Click at three dots showing next to data file or log file locations and then select the new path.
• Repeat same exercise for each file. To change default data file location, click at three dots next to data path and select new path here. Similarly, click at three dots next to log file location to change default log file location. If you want to change default backup file location then do the same for backup location as well.
• Click ak Ok button once you made changes for desired database file locations.
• Last step is to restart SQL Server services to apply this change and bring it into effect.

Once you will restart SQL Server services, your SQL Server default database location will be changed to the new path. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• Get Total Number of Virtual Log Files in SQL Server Transaction Log File
• SQL Server Error 1105: Could Not Allocate Space for Object in Database because the filegroup is full
• How to Change SQL Server Instance Name?
• Why Should You Always Turn Off Database Auto Shrink Property?

The post How to Change Database Default Locations in SQL Server? appeared first on Techyaz.com.

Error: 1101, Severity: 17, State: 2
Could not allocate a new page for database ‘DBNAME’ because of insufficient disk space in filegroup ‘PRIMARY’. Create the necessary space by dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

There is another error 1105 that is also very much like above error code. Error 1105 can also be fixed using same solution given in this article.

Error 1101 – Root Cause

Main reason behind error 1101 or error 1105 is the insufficient disk space in filegroup/files. You might also get this error if your database drives are running out of space. There are multiple reasons that can cause this error to generate. Some of them are given below.

• You have restricted database maximum file size or put size limits for files.
• Database file drives are running out of space.
• Autogrowth is not enabled for database files.

Solutions

To fix this issue we need to make space for database files to grow. Issue might vary depending on the nature of issue mentioned in above section. Sometimes, you might face this issue if maximum size for database files are restricted to some values so whenever database will grow to that point, SQL Server will not allow to allocate any page to that database. Sometimes you might get error 1101 because you don’t have any space on your database drives. Here, I will discuss each case individually and its solution to fix it.

Unrestrict or Increase Database File Size Limits

You might have enough space in your database drives but still you can get error 1101 because the maximum file size of database files is limited to some value and that causes not to grow your database beyond that size. You can unrestrict or increase the existing value of maximum file size to some bigger value. We have also an option to set database file size to unlimited size value that means database file will grow till the database file drive limit. Make sure to set appropriate autogrowth size for each database files.

You can set unlimited file size option or increase the value of maximum file size using GUI in SQL Server Management Studio or using ALTER statement.

• Connect to Database Instance in SQL Server Management Studio. Expand Database folder.
• Right Click on your database and choose Property window.
• Click on Files tab from left side pane in database property window.
• Here you can see all database files. Now you can click on three dots given next of database files in “Autogrowth/Maxsize” column. You can see max size is set to a limited value as shown in below screenshot. I have chosen unlimited option and clicked on Ok button.

Now we will not get any issue if our database drive has enough space.

Space in Database Drives

Another possibility for this error is, there might be possibility that your drives on which you have placed your database files are running out of space. If this is the case then you have below 4 options.

• Add additional database file to different disk where there is enough space.
• Move additional/unwanted files from your existing database drives.
• Drop/Purge or Move unwanted data (table/indexes)
• Add Additional Disk Space

Immediate fix of this issue is to add new database file to another drive where you have enough space to run your transactions. You can use below command to add addition database file to another disk.

USE [master]
GO
ALTER DATABASE [DBNAME]
ADD FILE (NAME = N'NewFileName', FILENAME = N'F:\mssql\data\newdatafile.ndf', SIZE = 100096KB, FILEGROWTH = 10240KB)
TO FILEGROUP [SECONDARY]
GO

You can also add new database file in SQL Server Management Studio by launching Database Property Window. Select Files from left side pane and Click on “Add” button showing in below screenshot. Make sure to set autogrowth value carefully for any database file. Also it is recommended to enable IFI – Instant File Initialization to speed up autogrowth process for your databases. Refer to below article to get best value for autogrowth for your database files. You can also read what are the benefits and how to enable IFI – Instant File Initialization in below article.

• What Should be the Best Value for database Autogrowth settings?
• How to Enable Instant File Initialization in SQL Server?

You can also have a look at the existing database drives whether there is any unwanted files or older backup files (*.bak) are not stored. Sometimes we run backups into database drives and forgot to delete or move them. Make sure to drop or move all unwanted files to some other location. Database drives should have only database files.

Final and long-term solution is the data purging. Identify the database objects that are not needed and then plan the data removal or data purging process to make space on your database.

We also have an option to extend the database drives as per the data growth. Make sure to plan this activity carefully before deploying it on production servers.

Enable Autogrowth

I have already written an article on Database autogrowth property setting. Read attached article to find out best value for Autogrowth settings.

You might get error 1101 if you have not enabled authogrowth setting for your database files. You need to enable it by launching database property window. You can click on three dots next to each database files in column “Authogrowth/Maxsize” and click at the enable authogrowth checkbox as showing in below screenshot.

You can also use ALTER statement to enable database autogrowth setting for your database file. Remember, you need to run this ALTER statement for each database file separately.

Run below ALTER command to enable autogrowth for database file.

--Pass logical filename of your database file for under NAME section.
ALTER DATABASE [Techyaz] MODIFY FILE ( NAME = N'Techyaz_Data', FILEGROWTH = 10000KB )

Make sure to enable Instant File Initialization to speedup autogrowth operations. Links to enable Instant File Initialization is attached in this article.

If you are facing this issue for tempdb database then you can consider one more option apart from all of the above options. And this option is to restart SQL Server service if it’s allowed. Keep in mind, SQL Server service restart will cause an outage for few minutes but it will create new tempdb files with initial size and error 1101 will be disappeared. This is not recommended solution because of outage so you should work on long terms solutions.

You can also use above solutions to fix error 1105 that is very much similar to error 1101. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• Fix Error 5144 and Error 5145 for Long or Failed Autogrow of Database Files
• Understanding Autogrowth Operation in SQL Server Databases
• How to Enable IFI – Instant File Initialization?
• Manage Database Files during huge Data Load

The post Fix Error 1101: Could not allocate a new page for database appeared first on Techyaz.com.

Related Articles:

• Manage Transaction Log File during Data Load
• Why Should You Always Turn Off Database Auto Shrink Property?
• What is the Best Value for Database File Autogrowth?
• SQL Server Architecture Interview Questions & Answers

SQL Server Data Files

When we create any SQL Server database, few operating system files are created and placed in to their respective directories. These files are known as database files. SQL Server databases have three types of files to handle data and log separately.

• Primary data file
• Secondary data files
• Log files

Every database has only one primary data file but none to multiple secondary data files whereas same database has minimum one log file and can have multiple log files depending on the requirements. Log files hold all the log information that is used to recover the database whereas all data files keeps or stores the actual data of the database.

The recommended file extension for primary, secondary data file and log file are .mdf, .ndf and .ldf respectively although it is not mandatory to keep same extension names but it helps you identify the different kinds of files and their use.

Each database file has two names one is logical file name another one is physical file name. The logical file name is the name used to refer to the physical file in all Transact-SQL statements whereas physical file name is the name that appear on the OS directory path.

Pages & Extents

We read in above section that every database has data files to store actual data. Data stores inside these data files in form of Pages so Page is the fundamental unit of data storage in SQL Server but Log files do not store any data, they contain a series of log records so log files do not have any pages.

The disk space allocated to a data file (.mdf or .ndf) in a database is logically divided into pages numbered contiguously from 0 to n. Pages in a SQL Server data file are numbered sequentially, starting with zero (0) for the first page in the file. Each file in a database has a unique file ID number. To uniquely identify a page in a database, both the file ID and the page number are required.

The size of page is 8 KB. Each page begins with 96-byte header as shown in above image that is used to store system information about the page. This information includes the page number, page type, the amount of free space on the page, and the allocation unit ID of the object that owns the page.

Data rows are put on the page serially, starting immediately after the header. A row offset table starts at the end of the page, and each row offset table contains one entry for each row on the page. Each entry records how far the first byte of the row is from the start of the page. The entries in the row offset table are in reverse sequence from the sequence of the rows on the page.

Extents are a collection of eight physically contiguous pages and are used to efficiently manage the pages. All pages are stored in extents.

The first page in each file is a file header page that contains information about the attributes of the file. Several of the other pages at the start of the file also contain system information, such as allocation maps. Below are the list of page types used in the data files of a SQL Server database.

1. Data: Data Page stores data rows with all data, except large object data types like text, ntext, image, nvarchar(max), varchar(max), varbinary(max), and xml data, when text in row is set to ON.
2. Index: Stores Index data.
3. Text/Image: Stores large object data types like text, ntext, image, nvarchar(max), varchar(max), varbinary(max), and xml data
4. Global Allocation Map: GAM pages record what extents have been allocated. Each GAM covers 64,000 extents, or almost 4 GB of data. The GAM has one bit for each extent in the interval it covers. If the bit is 1, the extent is free; if the bit is 0, the extent is allocated.
5. Shared Global Allocation Map: SGAM pages record which extents are currently being used as mixed extents and also have at least one unused page. Each SGAM covers 64,000 extents, or almost 4 GB of data.

The SGAM has one bit for each extent in the interval it covers. If the bit is 1, the extent is being used as a mixed     extent and has a free page. If the bit is 0, the extent is not used as a mixed extent, or it is a mixed extent and all     its pages are being used.

6. Page Free Space: Page Free Space (PFS) pages record the allocation status of each page, whether an individual page has been allocated, and the amount of free space on each page. The PFS has one byte for each page, recording whether the page is allocated, and if so, whether it is empty, 1 to 50 percent full, 51 to 80 percent full, 81 to 95 percent full, or 96 to 100 percent full.

After an extent has been allocated to an object, the Database Engine uses the PFS pages to record which pages     in the extent are allocated or free. This information is used when the Database Engine has to allocate a new           page.

7. Index Allocation Map: Information about extents used by a table or index per allocation unit. When the SQL Server Database Engine has to insert a new row and no space is available in the current page, it uses the IAM and PFS pages to find a page to allocate, or, for a heap or a Text/Image page, a page with sufficient space to hold the row. The Database Engine uses the IAM pages to find the extents allocated to the allocation unit.
8. Bulk Changed Map: Information about extents modified by bulk operations since the last BACKUP LOG statement per allocation unit. This tracks the extents that have been modified by bulk logged operations since the last BACKUP LOG statement.

If the bit for an extent is 1, the extent has been modified by a bulk logged operation after the last BACKUP LOG   statement. If the bit is 0, the extent has not been modified by bulk logged operations.

Although BCM pages appear in all databases, they are only relevant when the database is using the bulk-logged recovery model. In this recovery model, when a BACKUP LOG is performed, the backup process scans the             BCMs for extents that have been modified. It then includes those extents in the log backup. This lets the bulk       logged operations be recovered if the database is restored from a database backup and a sequence of   transaction  log backups.

 BCM pages are not relevant in a database that is using the simple recovery model, because no bulk logged  operations are logged. They are not relevant in a database that is using the full recovery model, because that  recovery model treats bulk logged operations as fully logged operations.

9. Differential Changed Map: Information about extents that have changed since the last BACKUP DATABASE statement per allocation unit. This tracks the extents that have changed since the last BACKUP DATABASE statement.

  If the bit for an extent is 1, the extent has been modified since the last BACKUP DATABASE statement. If the bit is 0, the extent has not been modified.

Differential backups read just the DCM pages to determine which extents have been modified. This greatly reduces the number of pages that a differential backup must scan. The length of time that a differential backup runs is proportional to the number of extents modified since the last BACKUP DATABASE statement and not the overall size of the database.

Sequence of Pages in Data file

A PFS page is the first page after the file header page in a data file (page number 1). This is followed by a GAM page (page number 2), and then an SGAM page (page 3). There is a PFS page approximately 8,000 pages in size after the first PFS page. There is another GAM page 64,000 extents after the first GAM page on page 2, and another SGAM page 64,000 extents after the first SGAM page on page 3. The DCM and BCM pages are located behind the GAM and SGAM pages in a physical file and interval between DCM pages and BCM pages is the same as the interval between GAM and SGAM page, 64,000 extents.

I hope this article helps you to understand data files, pages and extents. The source of this article is MSDN Book Online.  If you like this article, you can follow us on our facebook page and on Twitter handle to get latest updates.

The post Understanding SQL Server Data Files, Pages & Extents appeared first on Techyaz.com.