INSERT INTO goes much slower with time in SQL Server 2012

Question

We have a very big database WriteDB, which store raw trading data and we use this table to fast writes. Then with sql scripts I import data from WriteDB into ReadDB in comparatively the same table, but extended with some extra values + relation added. Import script is like that:

TRUNCATE TABLE [ReadDB].[dbo].[Price]
GO
INSERT INTO [ReadDB].[dbo].[Price]
SELECT a.*, 0 as ValueUSD, 0 as ValueEUR
from [WriteDB].[dbo].[Price] a
JOIN [ReadDB].[dbo].[Companies] b ON a.QuoteId = b.QuoteID

So initially there is around 130 mil. rows in this table (~50GB). Each day some of them added, some of them changes, so right now we decide not over complicate logic and just re-import all data. The problem that for some reason with time this script works longer and longer, on the almost same amount of data. First run it's take ~1h, now it's already taken 3h

Also SQL Server after import work not well. After import (or during it) if I try to run different queries, even the simplest they often fail with timeout errors.

What is the reason of such bad behavior and how to fix this?

Staw

There's two pieces to this - the INSERT and the SELECT. Work out which one it is by just running the SELECT. – Kimberlykimberlyn

How much memory does the server have? It could be that the working set exceeds memory gradually over time. – Bandler

@Bandler Server have 64GB ram, 55GB addressed to SQL server. All available memory consumed by MS SQL. Disks type - HDD i think. But server configuration not changed with time - so I can't understand this performance degradation. – Staw

Did the data size increase over time? You are on the edge of exceeding available memory (or already have). Depending on query plans this can kill perf by up to 1000x. – Bandler

Yes, it's goes more and more data. But it's grows not fast, I think less than 1% per day. – Staw

take a look at a similar question. #5296606. Also when your transfer is complete consider rebuilding indexes/statistics on the table as mass data changes confuse sql server. – Doggo

Answer 1

One theory is that your first 50GB dataset has filled available memory for caching. Upon truncating the table, your cache is now effectively empty. This alternating behavior makes effective use of the cache difficult and incurs a substantial number of cache misses / increased IO time.

Consider the following sequence of events:

1. You load your initial dataset into WriteDb. During the load operation, pages in WriteDb are cached. There's very little memory contention because there's only one copy of the dataset and sufficient memory.
2. You initially populate ReadDb. The pages required to populate ReadDb (the data in WriteDb) are already largely cached. Fewer reads are required from disk, and your IO time can be dedicated to writing the inserted data for ReadDb. (This is your fast first run.)
3. You load your second dataset into WriteDb. During the load operation, there is insufficient memory to cache both existing data in ReadDb and new data written to WriteDb. This memory contention leads to fewer pages of WriteDb cached.
4. You truncate ReadDb. This invalidates a substantial portion of your cache (i.e. the 50GB of ReadDb data that was cached).
5. You then attempt your second load of ReadDb. Here you have very little of WriteDb cached, so your IO time is split between reading pages of WriteDb (your query) and writing pages of ReadDb (your insert). (This is your slow second run.)

You could test this theory by comparing the SQL Server cache miss ratio during your first and second load operations.

Some ways to improve performance might be to:

• Use separate disk arrays for ReadDb / WriteDb to increase parallel IO performance.
• Increase the available cache (amount of server memory) to accomodate the combined size of ReadDb + WriteDb and minimize cache misses.
• Minimize the impact of each load operation on existing cached pages by using a MERGE statement instead of dumping / loading 50GB of data at a time.

Thriller