SQL Server 2014 introduced DBCC CLONEDATABASE for creating a blank database with only Schema and Statistics.

SQL Server 2016 added support of the Query Store in DBCC CLONEDATABASE.

This feature is very helpful in certain conditions.
For example, Your production database size is around 800 GB, and You faced some performance related issues because the problem of outdated Statistics or Indexes issue.

Now the situation is, you can do a test and trial in your Production Database, so DBA takes a copy of Production Database and restore it in different server for further investigation.

Do you think, this is the only one solution because Its require additional time and infrastructure.

In this kind of situation, you can use the DBCC CLONEDATABASE feature of SQL Server 2014.

It creates a blank database copy with the only Schema, Statistics and Query Store information. It is not copying the data, so it does not require any additional space.

You can find the same statistical information in the new clone database which generates the same execution plan for your investigation.

A Query Execution Plan is prepared to base on Database Statistics so If Database Statistics are same then you check your query execution plan without data.

Once you are finished with your task with Clone Database, you can delete it.

How internally SQL Server creates a Clone Database?

It validates the source database and acquires the shared lock on the source database

It creates a snapshot of the source database (Include only: Schema, Statistics, Query Store)

Create Clone Database and acquires an exclusive lock on it

Copy the metadata, schema, statistics, query store information from the source database to clone database

Release all locks from Clone Database

How to create a Clone Database?

Use DBCC CLONEDATABASE command to create a Clone Database.

DBCC CLONEDATABASE (MyDatabase,MyDatabase_Clone);

In this post, I am sharing performance test of the problem of mismatched column data type in SQL Server.

The Database Designer is also defining a wrong mismatched column data type by giving different data types to the same column for many tables.

For example, empid column -> assigned INT in tbl_emp table and -> assigned BIGINT in tbl_dept table. Because of this kind of problem, your query will execute slowly, and it requires implicit data conversion for each record.

Another example is, your column data type is VARCHAR, and you are checking N’DATA in WHERE clause which is NVARCHAR, so this is also required implicit data conversion.

Please check below full demonstration and, test it yourself:

Create a sample table, where [id] column type is varchar:

CREATE TABLE tbl_DiffDataTypes 
(	id varchar(25)
	,name VARCHAR(25)
	,constraint pk_tbl_DiffDataTypes_id primary key (id)
)
GO

Insert few dummy records:

DECLARE @i INT,@max INT
SET @i =1 
SET @max =99999
WHILE @i<=@max
BEGIN
   INSERT INTO tbl_DiffDataTypes VALUES(@i,'dbrnd.com')
   SET @i=@i+1
END

Please enable STATISTICS:

SET STATISTICS IO ON
SET STATISTICS TIME ON

Test WHERE filter with VARCHAR value: (Only 3 logical reads)

SELECT * FROM tbl_DiffDataTypes WHERE id = '1'

Result of Statistics:

Table 'tbl_DiffDataTypes'. Scan count 0, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Test WHERE filter with NVARCHAR value: (62 logical reads)

SELECT * FROM tbl_DiffDataTypes WHERE id = N'1'

Result of Statistics:

Table 'tbl_DiffDataTypes'. Scan count 1, logical reads 62, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Test WHERE filter with INTEGER value: (621 logical reads)

SELECT * FROM tbl_DiffDataTypes WHERE id = 1

Result of Statistics:

Table 'tbl_DiffDataTypes'. Scan count 1, logical reads 621, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

In this post, I am sharing a script to find the size and usage statistics of Greenplum Indexes. Having the complete knowledge of our database indexes is imperative. We should check the size and usage of indexes.

Recently, I started my work with Greenplum which based on PostgreSQL 8.2, so I am sharing a script to check index usage in Greenplum.

SELECT
    t.schemaname AS schema_name
    ,t.tablename AS table_name
    ,indexname AS index_name
    ,c.reltuples AS num_rows
    ,pg_size_pretty(pg_relation_size(quote_ident(t.tablename)::text)) AS table_size
    ,pg_size_pretty(pg_relation_size(quote_ident(indexrelname)::text)) AS index_size
    ,CASE WHEN indisunique THEN 'Y'
       ELSE 'N'
    END AS UNIQUE
    ,idx_scan AS number_of_scans
    ,idx_tup_read AS tuples_read
    ,idx_tup_fetch AS tuples_fetched
FROM pg_tables t
LEFT OUTER JOIN pg_class c ON t.tablename=c.relname
LEFT OUTER JOIN
( SELECT c.relname AS ctablename, ipg.relname AS indexname, x.indnatts AS number_of_columns, idx_scan, idx_tup_read, idx_tup_fetch, indexrelname, indisunique FROM pg_index x
   JOIN pg_class c ON c.oid = x.indrelid
   JOIN pg_class ipg ON ipg.oid = x.indexrelid
   JOIN pg_stat_all_indexes psai ON x.indexrelid = psai.indexrelid )
AS t1
ON t.tablename = t1.ctablename;

In this post, I am sharing one script to find Outdated Index Statistics of SQL Server.

Database Statistics are playing the main role to prepare a best query execution plan because Query Optimizer reads the Object Statistics and takes the decision accordingly.

SQL Server Statistics stores information like: object meta-data, location information, number of records.
If your Object Statistics are not updated, It impacts your query performance so You should find outdated statistics and periodically, you should update the statistics data.

SQL Server:Warning in Query Execution Plan, “Operator used tempdb to spill data during execution with spill level 2”

Script to find Outdated Index Statistics Information:

SELECT 
	OBJECT_NAME(id)
	,name
	,STATS_DATE(id, indid)
	,rowmodctr
FROM sys.sysindexes
WHERE STATS_DATE(id, indid)<=DATEADD(DAY,-1,GETDATE()) 
AND rowmodctr>0 
AND id IN (SELECT object_id FROM sys.tables)
GO

Statistics for query optimization are objects that contain statistical information about the distribution of values in one or more columns of a table or indexed view.

The query optimizer of Microsoft SQL Server is a cost-based optimizer.
One of the most important of is the information about the number of rows that are expected to be returned when the query is executed. This information is gleaned from what is called Statistics.

If statistics are not accurate enough, the query optimizer of Microsoft SQL Server may choose an inappropriate execution plan because of overestimates the number of records.

When AUTO_CREATE_STATISTICS is on, query optimizer creates statistics for single columns and also query optimizer creates statistics for indexes on tables or views when the index is created.

If an error or other event prevents the query optimizer from creating statistics, the query optimizer creates the query plan without using statistics. The query optimizer marks the statistics as missing and attempts to regenerate the statistics the next time the query is executed.

Statistics updates can be either synchronous (the default) or asynchronous:

With synchronous statistics updates, queries always compile and execute with up-to-date statistics.
When statistics are out-of-date, the query optimizer waits for updated statistics before compiling and executing the query.

With asynchronous statistics updates, queries compile with existing statistics even if the existing statistics are out-of-date.

Your query response times might be more predictable with asynchronous statistics updates than with synchronous statistics updates because the query optimizer can execute incoming queries without waiting for up-to-date statistics.

The query optimizer determines when statistics might be out-of-date and then updates them when they are needed for a query plan.
In some cases you can improve the query plan by updating Statistics manually using sp_updatestats.
You can also set AUTO_UPDATE_STATISTICS is on.

In any RDBMS system, Different type of Statistics is very important for Query Optimizer and Planner to choose and generate the best Query Execution Plan.

PostgreSQL Database Server also managing different types of Statistic which are used by the Query Optimizer to generate the best Query Execution Plan.

Statistical data should be updated, Why?
For Example,

We have one table with 100000 rows, but table statistic data are not updated and showing only 1000 tuples information.

Query optimizer always looks into Statistic tables, It never looks into direct table files.

So in this situation, It generates the wrong Query Execution Plan because It has only 1000 rows information, but actually there are 100000 rows.

PostgreSQL Database Server is mainly using two Statistical Table.

SELECT *FROM pg_class;
SELECT *FROM pg_stats;

You can also query these tables and can find information about Tables, Indexes, Pages and others.

When you look into table pg_class, you can find “reltuples” column. You can compare this column value with your actual table record count.

If you find any mismatch, for that table statistic information is not updated.

Execute Analyze command:

When you find that Statistical information is not updated, you can execute the ANALYZE command on the Database or Table.
After executing the ANALYZE command, It updates all require statistics.

PostgreSQL: Short note on VACUUM, VACUUM FULL and ANALYZE