Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Dzianis Member Откуда: Сообщений: 80 |
Полный тест Error: Time-out occurred while waiting for buffer latch type 3 for page (11:485280), database ID 2. Версия Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64) Oct 28 2016 18:17:30 Copyright (c) Microsoft Corporation Standard Edition (64-bit) on Windows Server 2012 R2 Standard 6.3 <X64> (Build 9600: ) Checkdb выдает 0 ошибок. Ошибка выплыла второй раз на пару недель. Так как это tempDb, то а промежуток времени, между предыдущей ошибкой. Сервер минимум 1 раз перегружался. А также tempDb была пересена на другой диск (то есть вопроса к "битости" диска как бы быть не может). В логе sql за 4 минуты времени около 12 аналогичных ошибок. С buffer latch type 3 и buffer latch type 4. Все относятся к tempdb и за 6 минут порядка 20и сообщений типа Process 0:0:0 (0xad8) Worker 0x00000049EC400160 appears to be non-yielding on Scheduler 17. Thread creation time: 13150541410851. Approx Thread CPU Used: kernel 0 ms, user 124703 ms. Process Utilization 60%. System Idle 38%. Interval: 130882 ms. Предыдущий раз. Встретил упоминание, что в 2005 версии это может быть конфликт многопоточности за дисковые ресурсы и рекомендацию увеличить количество файлов в базе. В tempdb сейчас состоит из 12 файлов (на 3х независимых IO) куда дальше копать искать причину? |
23 сен 17, 15:13 [20818026] Ответить | Цитировать Сообщить модератору |
Dzianis Member Откуда: Сообщений: 80 |
вся информацию, которую нахожу, относится или к 2008 и ранее, максимум к 2012 версии. |
23 сен 17, 15:19 [20818031] Ответить | Цитировать Сообщить модератору |
Дедушка Member Откуда: Город трёх революций Сообщений: 5114 |
dbcc page(2, 11, 485280) тип 3 это какой-то апдейт - несколько процессов меняют одну и ту же страницу |
||
23 сен 17, 15:48 [20818065] Ответить | Цитировать Сообщить модератору |
Dzianis Member Откуда: Сообщений: 80 |
|
||||||
23 сен 17, 16:12 [20818080] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5491 |
Dzianis, а покажите exec sp_helpdb tempdb |
23 сен 17, 16:21 [20818087] Ответить | Цитировать Сообщить модератору |
Dzianis Member Откуда: Сообщений: 80 |
|
||||
24 сен 17, 12:48 [20818828] Ответить | Цитировать Сообщить модератору |
invm Member Откуда: Москва Сообщений: 9633 |
|
||
24 сен 17, 15:24 [20818920] Ответить | Цитировать Сообщить модератору |
Dzianis Member Откуда: Сообщений: 80 |
по этой статье мы приходим только к https://support.microsoft.com/en-us/help/328551/concurrency-enhancements-for-the-tempdb-database Что необходимо дальше увеличивать количество фалов данных у темпбд, допустим до 24х штук. |
||||
24 сен 17, 16:53 [20819024] Ответить | Цитировать Сообщить модератору |
invm Member Откуда: Москва Сообщений: 9633 |
|
||
24 сен 17, 17:07 [20819034] Ответить | Цитировать Сообщить модератору |
Dzianis Member Откуда: Сообщений: 80 |
завтра попытаюсь пройтись. Хоть кажется что юзкейс к пользовательской БД может не подойти к темпБД. все таки это страницы, используемые неявно для "временных данных". ошибки появляются при выполнении стандартных запросов в пользовательских базах данных |
||||
24 сен 17, 18:15 [20819073] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5491 |
что-то у вас база размазана по трём дискам, один из них системный для локализации проблемы я бы сначала сгреб все файлы (уменьшить до 8 кол-во дата файлов) на один выделенный диск, чтобы нивелировать нагрузку со стороны других баз и приложений |
||||||
25 сен 17, 12:00 [20820180] Ответить | Цитировать Сообщить модератору |
Dzianis Member Откуда: Сообщений: 80 |
Поиск файла дампа для дебагера закончился неудачей. в файле лога нет упоминаний о пути и имени. Файловый поиск по диску то же ничего не дал. |
||
26 сен 17, 16:47 [20824495] Ответить | Цитировать Сообщить модератору |
Dzianis Member Откуда: Сообщений: 80 |
3 диска у каждого свой raid. Сгрести на один диск легко. Но нет возможности сделать выделенный диск для темпДБ. Чтобы нивелировать нагрузку - это единственная большая база на sql сервере. - прочее приложение используется только в рабочее время. Ошибка по логу не совпадает по времени с нагрузкой, она была ночью, когда почти все ресурсы свободны и юзаются sql. |
||
26 сен 17, 16:51 [20824504] Ответить | Цитировать Сообщить модератору |
Dzianis Member Откуда: Сообщений: 80 |
По логу так же присутствует ошибка. External dump process return code 0x20000001. External dump process returned no errors. |
26 сен 17, 16:54 [20824512] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5491 |
а это что показывает? select * from sys.dm_server_memory_dumps |
||||
26 сен 17, 17:19 [20824609] Ответить | Цитировать Сообщить модератору |
Все форумы / Microsoft SQL Server | ![]() |