Какой доверять?

Мы устраняем давнюю проблему с поставщиком. Их программное обеспечение имеет тенденцию зависать и прекращать работу один или два раза в неделю, что приводит к серьезным сбоям в нашей работе. Они не смогли определить причину, несмотря на то, что мы отправили им много ГБ журналов и резервных копий БД. В последнее время они начали предполагать, что проблемы связаны с нашим обслуживанием, а, возможно, не с их программным обеспечением (несмотря на то, что при возникновении проблем не выполняются длительные запросы, нагрузка на ЦП / ОЗУ / ввод-вывод или даже тупики). В частности, они говорят, что наши индексы являются проблемой.

Их любимый инструмент - DBCC showcontig, несмотря на мои аргументы, MS устарела. Особенно они зациклены на плотности сканирования и степени фрагментации. Чтобы устранить это оправдание, я ввел некоторые агрессивные ночные обслуживания, которые перестраивают индексы с <90% плотности сканирования или> 10% фрагментации. Это несколько отбросило их от последовательности плотности сканирования, но они остаются зацикленными на степени фрагментации. DBCC showcontig демонстрирует высокую степень фрагментации даже для индекса, который был перестроен несколько часов назад. Ниже приведены результаты dbcc_showcontig и sys.dm_db_index_physical_stats для таблицы, которую они указали как «возможную проблему».

DBCC SHOWCONTIG

• Отсканированные страницы ................................: 1222108
• Отсканированные экстенты ..............................: 152964
• Выключатели экстента ..............................: 180904
• Avg. Количество страниц в объеме ........................: 8,0
• Плотность сканирования [Количество лучших: Фактическое число] .......: 84,44% [152764: 180905]
• Фрагментация логического сканирования ..................: 3.24%
• Фрагментация сканирования экстентов ...................: 35,97%
• Avg. Свободно байт на страницу .....................: 692,5
• Avg. Плотность страницы (полная) .....................: 91,44%

sys.dm_db_index_physical_stats

index_type_desc      alloc_unit_type_desc     Avg_fragmentation_in_percent  page_count

CLUSTERED INDEX       IN_ROW_DATA          3.236803129  1222070

NONCLUSTERED INDEX    IN_ROW_DATA          0.680074642  48230

NONCLUSTERED INDEX    IN_ROW_DATA          0.093237195  48264

NONCLUSTERED INDEX    IN_ROW_DATA          0.03315856   48253

NONCLUSTERED INDEX    IN_ROW_DATA          0.194653248  48291

NONCLUSTERED INDEX    IN_ROW_DATA          0.393480436  58961

NONCLUSTERED INDEX    IN_ROW_DATA          0.23622292   64346

NONCLUSTERED INDEX    IN_ROW_DATA          0.041445623  48256

NONCLUSTERED INDEX    IN_ROW_DATA          0.701172007  59044

NONCLUSTERED INDEX    IN_ROW_DATA          0.216397724  53605

Должен ли я быть обеспокоен моими индексами? Тот, что выше, не является нетипичным. Предполагается, что предпочтительный MS DMV показывает, что он в порядке, но поставщик застрял на фрагментации в 35,97% степени. Я подозреваю, что это просто они отчаянно пытаются найти что-то, в чем виноваты их проблемы с программным обеспечением, но если у меня есть реальная проблема, я хочу попытаться исправить ее.

Их программное обеспечение имеет тенденцию зависать и прекращать работу один или два раза в неделю, что приводит к серьезным сбоям в нашей работе. Они не смогли определить причину, несмотря на то, что мы отправили им много ГБ журналов и резервных копий БД. ... В частности, они говорят, что наши индексы являются проблемой.

О, верно, я думаю, что слышал эту шутку раньше. Разве это не идет что-то вроде:

Утка заходит в бар и говорит: "Ой!" (шучу ;-) и бармен говорит: "Что у тебя будет?"

Утка говорит: «Дай мне 3 пальца твоей сильнейшей водки».

Бармен говорит, как если бы он шутил: «Разве вы не имеете в виду 3« перья »?»

Утка говорит: «Слушай, мне жаль, что ты больше не являешься главным писателем« Все любят Рэймонда » , но это был тяжелый день, так что ты мог бы быть приятелем и делать с водкой?»

Бармен говорит: «Конечно, приятель. Подожди».

Он возвращается через мгновение, явно чуть менее счастливым, чем когда ушел, и говорит утке: «Похоже, у нас все хорошо». Все, что у нас осталось, это Скай. Будет ли это работать? »

Утка вскакивает на стойку, хватает бармена за воротник одним крылом (каким-то образом), вытаскивает нож, ну где-то с другого крыла, и говорит, довольно медленно, мягко, но отчетливо: «Я. Уилл Вырезать. Ты. "

Бармен в панике говорит: «Эй, чувак, это база данных. Она медленная. Она не отвечает».

Утка, немного смущенная тем, должен ли он просто покончить с барменом - прямо здесь, прямо сейчас - сердито лает на него: «База данных? О чем, черт возьми, ты говоришь?»

Бармен, теперь рыдая, выпаливает: «Я не знаю ... Происходит ли какое-либо блокирование? .. Это только то, что мы говорим…. Вы можете попробовать перестроить индексы или что-то? .. Вы знаете, когда мы не знаем, что еще сказать .... может быть, нам следует добавить больше памяти на сервер ... вы думаете, это поможет? ... все знают, что код приложения работает быстро, а базы данных являются узким местом ... .. Эй, я слышал об этих базах данных NoSQL, которые являются <air-quotes> web-scale </ air-quotes> и, как правило, с открытым исходным кодом, поэтому они бесплатны, например, Twitter, Google и Facebook все используют этот материал, так как реляционные базы данных в значительной степени выходят ».

И с этим, утка приняла решение ...........

Хм. Ну, поверь мне, в оригинальном венгерском намного смешнее.

Но все же, почему первоначальная реакция такого большого количества людей, когда система замедляется, просто предположить, что это база данных? Как будто код приложения не может быть написан ужасно, или просто есть ошибки? Вещи, которые становятся медленнее, безусловно, могут быть базы данных. Но просто запереть / заморозить? Это не кажется мне проблемой, связанной с базой данных.

То, как это звучит, может быть кодом приложения, который не высвобождает должным образом внешние ресурсы (сетевые сокеты, дескрипторы файловой системы и т. Д.). Если мы говорим о приложении .NET, то иногда разработчики забывают правильно Dispose()об объектах, связанных с неуправляемыми ресурсами. Например: открытие SqlConnectionобъекта. Вы не получаете бесконечное их количество. Так что, если они хотят посмотреть в базе данных, то хорошо. Но, может быть, в следующий раз, когда система зависнет, взгляните на:

SELECT sdec.*, '---' AS [---], sdes.*
FROM sys.dm_exec_connections sdec
INNER JOIN sys.dm_exec_sessions sdes
        ON sdes.session_id = sdec.session_id

Если их код не освобождает соединения, тогда должно быть достаточно очевидно, если слишком много соединений, особенно если у многих из них длительное время простоя.

А может быть, этот материал уже проверен и просто не раскрыт в Вопросе. Но мне кажется странным, что они так сосредоточены на индексах и фрагментации. Конечно, есть проблемы с прослушиванием параметров, которые иногда приводят к тому, что одна, а может и несколько, хранимых процедур занимают ДЕЙСТВИТЕЛЬНО ＬＯＮＧ время, но блокируют целое приложение? Я не покупаю его, особенно если вы не видите, что запрос выполняется и требует много ресурсов, блокировок или времени, когда это происходит.

Итак, "чему доверять?" Конечно, не этот поставщик ;-).

Чтобы проверить, нужно ли реорганизовать или перестроить ваши индексы, нужно воспользоваться этим запросом:

declare @strBD nvarchar(50)

set @strBD = N'Tu_BD';

select table = OBJECT_NAME(object_id, database_id)
    ,index = index_id
    ,Index_Type = index_type_desc
    ,Logic_Frag = avg_fragmentation_in_percent
    ,Action = case 
        when avg_fragmentation_in_percent < 30.0
            then 'ALTER INDEX REORGANIZE'
        else 'ALTER INDEX REBUILD WITH (ONLINE = ON)'
        end
from sys.dm_db_index_physical_stats(DB_ID(@strBD), null, null, null, 'LIMITED');

Заменить @strBDна your database name.

Согласно результатам, действуйте, как указано в https://msdn.microsoft.com/en-us/library/ms189858(v=sql.110).aspx . Эта ссылка для версии 2012 SQL Server; Пожалуйста, выберите правильную версию, чтобы продолжить.

Как кто-то прокомментировал, лучше сообщить вашему поставщику, что пересмотреть и исправить, помимо «проблемы фрагментации». Возможно, выявление некоторых запросов и планов выполнения с помощью захвата SQL Profiler.