SQL Server 2014 introduced Buffer Pool Extension to improve the performance of query cache which reduces the Disk I/O and increase the overall performance.

This buffer pool area is a global resource shared by all databases, and it stores cache related information like frequently used data, frequently executed execution plans and pages information.

The buffer pool area is a kind of memory cache which holds the frequently used result and returns the result from it rather than needing to go back to disk to retrieve the results.

The buffer pool is limited by the max server memory configuration option and the total available RAM.

Now using the concept of Buffer Pool Extension,

You can configure additional SSD disk to work as other buffer pool area. It doesn’t mean that you are increasing the RAM.

Why SSD (solid-state drive), because of it ten times faster than regular disk.

You should add SSD as buffer pool extension because with normal disk you will not get expected performance of the buffer pool.

What you should do?

Attached one SSD drive to the server and alter the server configuration parameter by adding the .bpe file. This BPE (Buffer Pool Extension) file works as an additional buffer pool area.

You just give to correct folder path of your SSD drive with .bpe filename and size, it automatically creates .bpe file with specified size.

Enable Buffer Pool Extenstion:

USE master 
GO
ALTER SERVER CONFIGURATION 
SET BUFFER POOL EXTENSION ON
(FILENAME = 'F:\SQLData\SQL2014_dbrnd.BPE', SIZE = 30 GB);
GO

Disable Buffer Pool Extension:

USE master 
GO
ALTER SERVER CONFIGURATION 
SET BUFFER POOL EXTENSION OFF;

Microsoft SQL Server Database Auto Close option is also crucial during the performance tuning activities.

When you set Auto_Close ON, SQL database automatically shut down after last user exit and free all the occupied resources. When a user wants to connect the database, it opens database related connections and starts utilizing resource again.

This looks like a good thing where the database can free all the resources when they are not in use.

Please do not forget about query cache and other procedure cache areas which are playing an important role in query execution.

If ou set Auto_Close ON, it removes all stored query cache, procedure cache, buffer cache which degrades the performance while accessing the database again. The biggest problem is that SQL Server has to load data back into the buffer to satisfy performance, and any queries fired against the database itself have to be re-compiled as well.

In very rare cases, you require to enable Auto Close for example, Your organization has thousand of databases and limited resources.
In general, Database Auto Close option should disable which requires very limited resources in idle mode.

So now, during your performance optimization activities, please check about Auto Close option. There are DMVs available to check the status of different types of cache data.

Using SSMS, Set Auto Close OFF:

Right-click on database -> Properties -> Options -> Automatice Section -> Auto Close

USE [master]
GO
ALTER DATABASE [DatabaseName] SET AUTO_CLOSE OFF;
GO

In the previous post, I shared a basic note on MySQL Query Cache.
In this post, I am sharing the details on Query Cache configuration and monitoring.

The first check, Query Cache is available or not.

Please execute below SHOW command:

mysql> SHOW VARIABLES LIKE 'have_query_cache';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| have_query_cache | YES   |
+------------------+-------+

To disable the query cache at server startup, set the query_cache_size system variable to 0. By default, the query cache is disabled.

Using query_cache_size you can set the size of Query Cache which must be larger when you are planning to hold more data into Cache but again this is a task of analysis of your memory usage.

mysql> SET GLOBAL query_cache_size = 1000000;
Query OK, 0 rows affected (0.04 sec)

mysql> SHOW VARIABLES LIKE 'query_cache_size';
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| query_cache_size | 999424 |
+------------------+--------+
1 row in set (0.00 sec)

Query Cache with SELECT :

SELECT SQL_CACHE * FROM tbl_users;
SELECT SQL_NO_CACHE * FROM tbl_users;

In the above two select statements, you can find two identifiers.

SQL_CACHE

The query result is cached if it is cacheable and the value of the query_cache_type system variable is ON or DEMAND.

SQL_NO_CACHE

The server does not use the query cache. It neither checks the query cache to see whether the result is already cached nor does it cache the query result.

SHOW VARIABLES LIKE 'query_cache_type';

• A value of 0 or OFF prevents caching or retrieval of cached results.
• A value of 1 or ON enables caching except of those statements that begin with SELECT SQL_NO_CACHE.
• A value of 2 or DEMAND causes caching of only those statements that begin with SELECT SQL_CACHE.

To monitor query cache performance, use SHOW STATUS to view the cache status variables:

mysql> SHOW STATUS LIKE 'Qcache%';
+-------------------------+--------+
| Variable_name           | Value  |
+-------------------------+--------+
| Qcache_free_blocks      | 36     |
| Qcache_free_memory      | 138488 |
| Qcache_hits             | 79570  |
| Qcache_inserts          | 27087  |
| Qcache_lowmem_prunes    | 3114   |
| Qcache_not_cached       | 22989  |
| Qcache_queries_in_cache | 415    |
| Qcache_total_blocks     | 912    |
+-------------------------+--------+

Introduction to MySQL Query Cache: Part I

Today morning, I was monitoring MySQL Production database.

I found out the list of running sessions with different SQL queries. I created some master and primary tables in MySQL which stored settings and configuration data for one of our Mobile App.

As these tables are for configuration purpose so not frequently update by the application.

But today, I was worry because of this configuration table was utilizing more CPU I/O. I created this all tables under InnoDB MySQL Storage engine.

I cannot store all this data under Memory engine because this all are primary data for our Application.

So I was finding a solution for faster retrieval and found that MySQL has a good option called a Query Cache.

In this post, I am sharing theory of MySQL Query Cache and I will share the second part of the practical configuration of MySQL Query Cache by tomorrow.

What is MySQL Query Cache ?
Sort & Simple, MySQL Query Cache stores some frequent SELECT statements with its corresponding results.

When table data are not changing frequently and the server receives many identical queries then only Query Cache returns data from the Cache area.

Whenever table modified with data, then Query cache will be flush.

I surprised by this feature of MySQL which improve your query performance in some circumstances.

When you trigger any select statement and if it is available in the cache, it will return from there and not require parsing and fetching from disk so it improves a query performance.

Please do not assume that this will work under all circumstances because this also depends on your load of memory and server.

You can also set the size for Query Cache but make sure that it should not be higher otherwise its create memory overhead for the whole server.

Few conditions in which Query Cache will not work:

• Not use when multiple server hitting to one query.
• Not use with Stored Procedure and UDF.
• Not use with any type of Variables.
• Not use with any table of default database like, MySQL, INFORMATION_SCHEMA.
• Not use with partition tables.
• Not use with Temporary tables.
• Not use with Prepared Statements.

Please visit MySQL Query Cache Part II for the configuration of Query Cache: