SQL Server xóa bộ nhớ cache và thống kê thực hiện định kỳ


24

Sau khi nâng cấp SQL Server 2014 lên 2016, máy chủ sẽ tiếp tục đặt lại các gói và dm*chế độ xem thực thi được lưu trong bộ nhớ cache (như dm_exec_query_stats), cứ sau vài giờ

Như thể ai đó thực thi DBCC FREEPROCCACHEDBCC DROPCLEANBUFFERSthủ công (ngoại trừ không có ai làm, nó sẽ tự động xảy ra).

Cơ sở dữ liệu tương tự cũng hoạt động tốt trên SQL Server 2014 và Windows Server 2012, mọi thứ đã đi về phía nam sau khi chuyển sang SQL Server 2016 (và máy chủ Windows 2016)

Điều tôi đã kiểm tra: cơ sở dữ liệu không có cờ "tự động đóng". Máy chủ SQL được ad hoc optimizedđặt thành true(Tôi nghĩ nó sẽ giúp ích, nhưng không được). "Cửa hàng truy vấn" là "tắt". Máy chủ có bộ nhớ 16 GB.

Không có gì hữu ích trong "Nhật ký máy chủ SQL". Chỉ cần một tin nhắn sao lưu hàng tuần ...

Tôi cũng đã kiểm tra bài viết này https://docs.microsoft.com/en-us/sql/t-sql/statements/alter-database-transact-sql-set-options (cuộn xuống phần "Ví dụ" và bên phải nó) có một danh sách các tình huống khi kế hoạch được xóa tự động. Không ai trong số đó áp dụng.

CẬP NHẬT:

Thật không may, không có gợi ý nào giúp được. Cấp quyền LPIM, phát hiện và sửa các truy vấn không tham số tạo ra hàng tấn kế hoạch cho cùng một truy vấn, giảm "bộ nhớ máy chủ tối đa" ... Các kế hoạch tiếp tục đặt lại ngẫu nhiên, từ vài giờ đến 5-10 phút một lần. Nếu máy chủ "chịu áp lực bộ nhớ" thì tại sao phiên bản 2014 hoạt động tốt trên cùng một máy.

Đây là đầu ra sp_Blitz theo yêu cầu

**Priority 10: Performance**:

- Query Store Disabled - The new SQL Server 2016 Query Store feature has not been enabled on this database.

    * xxx


**Priority 50: Server Info**:

- Instant File Initialization Not Enabled  - Consider enabling IFI for faster restores and data file growths.


**Priority 100: Performance**:

- Resource Governor Enabled  - Resource Governor is enabled.  Queries may be throttled.  Make sure you understand how the Classifier Function is configured.


**Priority 120: Query Plans**:

- Implicit Conversion Affecting Cardinality - One of the top resource-intensive queries has an implicit conversion that is affecting cardinality estimation.

    * 

- Missing Index - One of the top resource-intensive queries may be dramatically improved by adding an index.

    * 

- RID or Key Lookups - One of the top resource-intensive queries contains RID or Key Lookups. Try to avoid them by creating covering indexes.

    * 

**Priority 170: File Configuration**:

- System Database on C Drive
    * master - The master database has a file on the C drive.  Putting system databases on the C drive runs the risk of crashing the server when it runs out of space.

    * model - The model database has a file on the C drive.  Putting system databases on the C drive runs the risk of crashing the server when it runs out of space.

    * msdb - The msdb database has a file on the C drive.  Putting system databases on the C drive runs the risk of crashing the server when it runs out of space.


**Priority 200: Backup**:

- MSDB Backup History Not Purged msdb - Database backup history retained back to Jun 10 2017  9:47PM


**Priority 200: Informational**:

- Backup Compression Default Off  - Uncompressed full backups have happened recently, and backup compression is not turned on at the server level. Backup compression is included with SQL Server 2008R2 & newer, even in Standard Edition. We recommend turning backup compression on by default so that ad-hoc backups will get compressed.


**Priority 200: Non-Default Server Config**:

- Agent XPs  - This sp_configure option has been changed.  Its default value is 0 and it has been set to 1.

- max server memory (MB)  - This sp_configure option has been changed.  Its default value is 2147483647 and it has been set to 15000.

- optimize for ad hoc workloads  - This sp_configure option has been changed.  Its default value is 0 and it has been set to 1.

- show advanced options  - This sp_configure option has been changed.  Its default value is 0 and it has been set to 1.

- xp_cmdshell  - This sp_configure option has been changed.  Its default value is 0 and it has been set to 1.


**Priority 200: Performance**:

- Buffer Pool Extensions Enabled  - You have Buffer Pool Extensions enabled, and one lives here: Z:\sql_buffer_pool.BPE. It's currently 60.00000000000 GB. Did you know that BPEs only provide single threaded access 8KB (one page) at a time?

- cost threshold for parallelism  - Set to 5, its default value. Changing this sp_configure setting may reduce CXPACKET waits.

**Priority 240: Wait Stats**:

- No Significant Waits Detected  - This server might be just sitting around idle, or someone may have cleared wait stats recently.

**Priority 250: Informational**:

- SQL Server Agent is running under an NT Service account  - I'm running as NT Service\SQLSERVERAGENT. I wish I had an Active Directory service account instead.

- SQL Server is running under an NT Service account  - I'm running as NT Service\MSSQLSERVER. I wish I had an Active Directory service account instead.

**Priority 250: Server Info**:

- Default Trace Contents  - The default trace holds 125 hours of data between Aug 19 2017 11:55AM and Aug 24 2017  4:59PM. The default trace files are located in: C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Log

- Hardware  - Logical processors: 2. Physical memory: 15GB.

- Hardware - NUMA Config  - Node: 0 State: ONLINE Online schedulers: 2 Offline schedulers: 0 Processor Group: 0 Memory node: 0 Memory VAS Reserved GB: 29

- Locked Pages In Memory Enabled  - You currently have 12.02534484863 GB of pages locked in memory.

- Memory Model Unconventional  - Memory Model: LOCK_PAGES

- Server Last Restart  - Aug 20 2017 12:32PM

- Server Name  - xx

- Services
 - Service: SQL Full-text Filter Daemon Launcher (MSSQLSERVER) runs under service account NT Service\MSSQLFDLauncher. Last startup time: not shown.. Startup type: Manual, currently Running.

 - Service: SQL Server (MSSQLSERVER) runs under service account NT Service\MSSQLSERVER. Last startup time: Aug 20 2017 12:32PM. Startup type: Automatic, currently Running.

 - Service: SQL Server Agent (MSSQLSERVER) runs under service account NT Service\SQLSERVERAGENT. Last startup time: not shown.. Startup type: Automatic, currently Running.

- SQL Server Last Restart  - Aug 20 2017 12:33PM

- SQL Server Service  - Version: 13.0.4446.0. Patch Level: SP1. Edition: Enterprise Edition (64-bit). AlwaysOn Enabled: 0. AlwaysOn Mgr Status: 2

- Virtual Server  - Type: (HYPERVISOR)

- Windows Version  - You're running a pretty modern version of Windows: Server 2012R2 era, version 6.3


**Priority 254: Rundate**:

 - Captain's log: stardate something and something...

1
Tôi đã giải quyết vấn đề tương tự, bạn có thể thử. dba.stackexchange.com/questions/179618/query-plan-delave/ith
Yunus UYANIK

Câu trả lời:


27

Đầu tiên, hãy lấy thời gian chính xác khi bộ nhớ cache của gói đang bị xóa. Đây là cách dễ nhất để làm điều đó - nó sẽ chạy gần như ngay lập tức và sẽ không chặn bất kỳ ai:

SELECT TOP 1 creation_time
FROM sys.dm_exec_query_stats WITH (NOLOCK)
ORDER BY creation_time;

Nếu ngày / giờ đó có vẻ cũ hơn so với bạn mong đợi , thì chỉ một phần của bộ đệm kế hoạch đang bị xóa. Ví dụ, có thể ai đó đang thực hiện việc xây dựng lại chỉ mục hoặc cập nhật công việc thống kê, điều này sẽ xóa bộ đệm của kế hoạch cho các đối tượng cụ thể bị ảnh hưởng - nhưng các đối tượng khác sẽ vẫn ở xung quanh. Tôi thấy điều này rất nhiều khi các truy vấn hệ thống (như truy vấn DMV) xuất hiện, nhưng kế hoạch cơ sở dữ liệu người dùng rõ ràng.

Nếu ngày / giờ đó cập nhật theo các khoảng thời gian cụ thể , như nếu nó dường như cập nhật chính xác cứ sau 2 giờ để nói 6:00, 8:00, 10:00, v.v. thì có lẽ ai đó đang chạy một công việc hoặc truy vấn gây ra bộ đệm của kế hoạch tẩu thoát. Khi bạn biết tần số chính xác, sau đó bạn có thể:

  • Nhìn vào lịch trình công việc của bạn để xem những gì chạy trong khoảng thời gian đó
  • Chạy theo dõi Profiler hoặc theo dõi Sự kiện mở rộng trong khoảng thời gian đó để tìm ra bí ẩn (Tôi thường không phải là người thích truy tìm trong sản xuất, nhưng nếu bạn biết chính xác khi nào kẻ giết người sẽ tấn công, thì đủ dễ để bắn hạ mẫu đầu của những gì đang chạy)
  • Đăng nhập sp_WhoIsActivevào một bảng trong thời gian đó (phương pháp dễ nhất, nhưng ít có khả năng thu hẹp nó vào truy vấn chính xác gây ra nó)

Nếu ngày / giờ đó liên tục thay đổi mỗi khi bạn chạy truy vấn , thì máy chủ của bạn có thể chịu áp lực bộ nhớ. Chạy phần này để tạo thông tin kiểm tra sức khỏe cơ bản và sau đó bạn có thể sao chép / dán nó vào câu hỏi Stack của mình để chúng tôi có thể chẩn đoán nó:

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1, @CheckUserDatabaseObjects = 1

(Tiết lộ: Tôi là một trong những tác giả của sp_Blitz.)

Đã cập nhật 2017/08/25 với dữ liệu sp_Blitz của bạn - cảm ơn vì đã chạy sp_Blitz và thêm nó vào câu hỏi của bạn và nó thực sự giúp hiển thị một vài điều. Bạn đang chạy SQL Server 2016 Enterprise Edition trên máy ảo có 2 lõi và 16GB RAM. Đầu tiên, một lưu ý nhanh về cấp phép: nếu bạn cấp phép cho khách, yêu cầu mua tối thiểu là 4 lõi, không phải 2. (Xem Hướng dẫn cấp phép SQL Server để biết thêm chi tiết.) 4 lõi của Phiên bản doanh nghiệp là khoảng $ 28K USD và thật bất thường khi thấy rằng nhiều tiền cấp phép chỉ dành cho RAM 16 GB. Nếu bạn cấp phép SQL Server Enterprise Edition ở cấp máy chủ, bạn có thể bỏ qua điều đó và chạy các máy ảo nhỏ hơn.

Có vẻ như SQL Server của bạn đang chịu áp lực bộ nhớ ngoài. Bạn đã có 16GB RAM và bạn đã đặt bộ nhớ máy chủ tối đa ở mức 15 GB. Thật không may, 1GB không đủ cho hệ điều hành (cộng với mọi thứ khác bạn sẽ chạy trên đó, như phần mềm sao lưu và SSMS.) Trong Hướng dẫn thiết lập máy chủ SQL của chúng tôi, chúng tôi khuyên bạn nên để lại 4GB hoặc 10% miễn phí lớn hơn - trong trường hợp của bạn, đó sẽ là 4GB, vì vậy cài đặt bộ nhớ máy chủ tối đa của bạn phải là 12 GB thay vì 15 GB.

Nhiều bằng chứng hiển thị trong phân bổ bộ nhớ hiện tại của bạn: bạn đã bật các trang trong bộ nhớ (LPIM), nhưng bạn chỉ có 12,02 GB trang bị khóa trong bộ nhớ. Điều đó có khả năng (nhưng không được bảo đảm) có nghĩa là một số ứng dụng khác cần bộ nhớ, vì vậy Windows đã gửi thông báo áp suất bộ nhớ và SQL Server đã từ bỏ 3GB bộ nhớ khác để cho ứng dụng kia làm việc đó. Đó là nhiều bằng chứng cho thấy bạn không thể thực sự sử dụng tối đa 15 GB - bạn cần bộ nhớ cho những thứ khác.

Khi SQL Server của bạn chịu áp lực bộ nhớ ngoài đó và cần giải phóng bộ nhớ cho các ứng dụng khác, bộ nhớ cache của gói sẽ bị ảnh hưởng.

Vì vậy, bạn có một vài lựa chọn:

  • Đặt bộ nhớ tối đa một cách thích hợp - giả sử, 12GB (hoặc thậm chí thấp hơn nếu bạn sẽ chạy các ứng dụng khác trên máy chủ.) Bằng cách đó, SQL Server sẽ không phải bán giảm giá bộ nhớ và loại bỏ mọi thứ chỉ vì một số khác ứng dụng cần 2-3 GB RAM - nó sẽ có sẵn
  • Dừng chạy các ứng dụng khác trên máy chủ - điều này có thể khó khăn nếu đó là các hệ thống máy tính để bàn từ xa và chạy các công cụ như SSMS. Tôi đã thiết lập báo động truy cập Perfmon cho số phiên RDP mở và được cảnh báo khi có bất kỳ thứ gì khác 0 - có thể giúp bắt được thủ phạm hoạt động.
  • Thêm nhiều bộ nhớ hơn cho VM - nhưng tôi không nghĩ bạn thực sự cần nó. Một số bằng chứng được hiển thị bởi báo cáo sp_Blitz về "không có sự chờ đợi đáng kể nào được phát hiện". Tôi không nghĩ rằng bạn đang chịu áp lực bộ nhớ thường xuyên, đặc biệt là khi bạn báo cáo rằng điều đó chỉ xảy ra mỗi giờ và sau đó. Đây là lựa chọn ít hiệu quả nhất.

5

OK, OP ở đây, cuối cùng tôi đã khắc phục vấn đề này bằng cách cập nhật SQL Server 2016 lên phiên bản mới nhất. Tôi đã có SP1và ngày hôm qua tôi đã cài đặt Cumulative Update 6.

Tôi cũng đặt "bộ nhớ tối đa" một cách thích hợp như câu trả lời của Brent gợi ý. Bằng cách này, câu trả lời tuyệt vời, tôi kêu gọi mọi người nâng cao nó.

Đã 36 giờ và đếm, kế hoạch không được thiết lập lại.

Brent Ozar cũng có một trang web rất đẹp ở đây: https://sqlserverupdates.com/ để giúp xác định những cập nhật nào bạn cần.

Một điều khác đã giúp là phát hiện và giải quyết vấn đề "khóa ngoại không tin cậy". Brent có một bài viết rất hay (hahah, yeah, Brent, tôi biết đúng) về cách giải quyết nó, chỉ cần google, anh ấy là kết quả số 1


1

Tôi đã gặp vấn đề này trong hộp thử nghiệm tại nhà và tôi phát hiện ra rằng bằng cách thêm quyền 'Khóa trang trong bộ nhớ' vào tài khoản dịch vụ SQL Server đã giải quyết vấn đề, nhưng tôi không chắc đây là lời khuyên tốt nhất.

Xem Kích hoạt trang khóa trong tùy chọn bộ nhớ (Windows)


Các trang bị khóa trong bộ nhớ sẽ không sửa được nếu chỉ xóa bộ nhớ cache của gói (không phải vùng đệm).
Brent Ozar
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.