Another interesting news that comes from the new SQL Server 2016 RC0 is the use of new database-scoped parameters AUTOGROW_SINGLE_FILE / AUTOGROW_ALL_FILES as well as MIXED_PAGE_ALLOCATION that will replace respectively the effects of the 1117 and 1118 trace flags for a particular database. This is a very great news because we will benefit of a more granular configuration regarding our specific workload against one particular database.

Let’s create this simple database and let’s enable the AUTOGROW_ALL_FILES on the primary filegroup

CREATE DATABASE [DB_2016]
 ON  PRIMARY 
( NAME = N'DB_2016', FILENAME = N'E:\SQLSERVER\SQL16\DB_2016.mdf' , SIZE = 524288KB , FILEGROWTH = 65536KB ),
( NAME = N'DB_20162', FILENAME = N'E:\SQLSERVER\SQL16\DB_20162.ndf' , SIZE = 524288KB , FILEGROWTH = 65536KB ),
( NAME = N'DB_20163', FILENAME = N'E:\SQLSERVER\SQL16\DB_20163.ndf' , SIZE = 524288KB , FILEGROWTH = 65536KB )
 LOG ON 
( NAME = N'DB_2016_log', FILENAME = N'F:\SQLSERVER\SQL16\DB_2016_log.ldf' , SIZE = 524288KB , FILEGROWTH = 65536KB )
GO

ALTER DATABASE [DB_2016]
MODIFY FILEGROUP [PRIMARY] AUTOGROW_ALL_FILES;
GO

The sys.filegroups system view has a new is_autogrow_files column to check if all files in the same filegroup will grow at the same time

USE [DB_2016];
GO

SELECT 
	DB_NAME() AS [db_name],
	mf.name AS logical_name,
	fg.name as [filegroup_name],
	fg.is_autogrow_all_files
FROM sys.database_files AS mf
JOIN sys.filegroups AS fg
	ON mf.data_space_id = fg.data_space_id
GO

Let’s validate this new option with the following pretty simple test:

CREATE TABLE dbo.test_2016
(
	id INT IDENTITY,
	col1 CHAR(8000) DEFAULT 'T'
);
GO

INSERT INTO dbo.test_2016 DEFAULT VALUES;
GO 210000

File sizes have increased as expected by refering to the following query output:

SELECT 
	name AS logical_name,
	size / 128 AS size_mb,
	CAST(FILEPROPERTY(name, 'SpaceUsed') * 100. / size AS DECIMAL(5, 2)) AS [%_free]
FROM sys.database_files
WHERE type_desc = 'ROWS'

All files seem to have grown with the same target size at the same time according to events found in the default trace.

DECLARE @path NVARCHAR(260);

SELECT 
   @path = REVERSE(SUBSTRING(REVERSE([path]), 
   CHARINDEX('\', REVERSE([path])), 260)) + N'log.trc'
FROM    sys.traces
WHERE   is_default = 1;

SELECT 
   DatabaseName,
   [FileName],
   SPID,
   Duration,
   StartTime,
   EndTime,
   FileType = CASE EventClass 
       WHEN 92 THEN 'Data'
       WHEN 93 THEN 'Log'
   END
FROM sys.fn_trace_gettable(@path, DEFAULT)
WHERE EventClass = 92
	AND DatabaseName = 'DB_2016'
ORDER BY StartTime DESC;

In the next scenario, let’s test the effect of the second interesting MIXED_PAGE_ALLOCATION option. Let’s say we want to disable the allocation of mixed extents (default behavior) by using the following command:

ALTER DATABASE [DB_2016] SET MIXED_PAGE_ALLOCATION OFF;
GO

As the previous database-scoped option we are able to control which databases are candidate for mixed or uniform allocations by default. This information is directly accessible from the sys.databases DMV as shown below:

SELECT 
	name, is_mixed_page_allocation_on
FROM sys.databases

You may notice that we are now able to confirm that mixed extent allocation is disabled by default for our user database and tempdb as well (without enabling the trace flag 1118).

Let’s perform the quick test of verifying if uniform extend is the default behavior for the DB_2016 database (my database is in SIMPLe recovery model here)

CHECKPOINT;

CREATE TABLE dbo.test_20161
(
	id INT IDENTITY,
	col1 CHAR(8000) DEFAULT 'T'
);
GO

INSERT INTO dbo.test_20161 DEFAULT VALUES;
GO 1

Let’s verify the context of the DB_2016 database transaction log. We may notice the related record that confirms a new uniform extent is allocated of the concerned dbo.test_20161 table as shown below:

We may also double check by using the sys.dm_db_database_page_allocations DMF against the same table as following:

SELECT 
	OBJECT_NAME(object_id) AS table_name,
	index_id,
	[partition_id],
	extent_page_id,
	allocated_page_page_id,
	page_type_desc as page_type
FROM sys.dm_db_database_page_allocations(DB_ID(), OBJECT_ID('dbo.test_20161'), 0, NULL, 'DETAILED')

Stay tuned! In the next blog we’ll see other interesting database-scoped options provided with the future release of SQL Server 2016.

By David Barbarin

L’article SQL Server 2016: new database-scoped configuration parameters est apparu en premier sur dbi Blog.

First of all, during my intervention, my customer complained of some performance issues, so I decided to take a look at different areas of its instance.

I found some interesting records inside the SQL Server error log file as follows:

A timeout that occurred while waiting for latch class LOG_MANAGER … Ouch, it was the first time I faced this issue and after taking a look at the latch stats it confirmed that an issue existed on this area:

Unfortunately, the Microsoft documentation is very poor concerning the description of this latch type.

But Paul Randal gives some clues on his very useful blog here. This latch may appear when transaction log file is growing (whatever the reason). After some investigations, I effectively found that the growing issue was due to an incorrect recovery model configuration (FULL and no backup log in this context).

But that’s not all and this is where the funny part of this story comes. To be honest, I have never seen a latch timeout causing by a growing of a transaction log file except on this situation. I first suspected the storage here but in fact after taking a look at the transaction log file size and the associated growth parameter, I definitely rule out this suspicion (at least the real problem was not here).

…

I replaced the real database name of my customer by User DB here. So what do you notice? No you don’t dream … the transaction log file size = 1.2 TB with a default auto growth configuration = 10%! So I imagine that you begin to understand where the problem is located

So, just for curiosity let’s have a look at the generated dump file:

So, it seems that an update query has generated log records after updating a BTree structure (sqlmin!BTreeRow:UpdateRecord()). In turn, the log manager tried to expand the transaction log file (sqlmin!SQLServerLogMgr::GrowAFile() method) without success after SQL Server has generated log records (sqlmin!XdesRMReadWrite::LogBeginXact() –> sqlmin!XdesRMReadWrite:GenerateLogRec() methods) . In this context, I guess that the expand operation has taken a very long time because 10% of the transaction log file represents a large chunk of disk space (roughly 100GB).

Finally let’s have a look at the wait stats:

We can also correlate the PREEMPTIVE_OS_WRITEFILEGATHER wait type to our issue here with the high average value. Zeroing the new portion of the transaction log file may be very long in our context.

My intention was not to blame my customer here but it was a good opportunity to point out the potential issue you may face with default database file auto growth settings!

See you

By David Barbarin

L’article Don’t use the default database file autogrow settings ! est apparu en premier sur dbi Blog.