Рекомендации по обслуживанию MS SQL

[VarankDA]

Со временем база сильно разраслась, и работает заметно медленнее.
Может кто подскажет какие-то регламентные работы по MS SQL для увеличения быстродействия и снижения объема?

[edward_K]

Все здесь относится к Studio!
Чистка хранимых процедур - требует выгона всех.

Код: Выделить всё

GO

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON

GO


IF  EXISTS (SELECT * FROM sys.objects WHERE 
object_id = OBJECT_ID(N'[dbo].[DelAtlProc]') 
AND type in (N'P', N'PC')) 
DROP PROC [dbo].[DelAtlProc]

GO


Create proc [dbo].[DelAtlProc]
as 
begin
 Declare @DelProc varchar(150) 
 Declare RecCur Cursor FAST_FORWARD For
-----------
  select 
    'Drop Procedure dbo.'  + obj.name
  From sys.all_objects as obj
  Where obj.Type='P' And obj.Name Like '%0000000%' 
  and  (not (obj.Name Like 'NT00000000%'))
  AND OBJ.modify_date<DATEADD(DD,-15,GETDATE())
-----------   
Open RecCur 

Fetch Next From RecCur Into @DelProc
if @DelProc<>''
  exec (@DelProc)
While @@FETCH_STATUS = 0
begin
  Fetch Next From RecCur Into @DelProc
  exec (@DelProc)
end
Close RecCur 
Deallocate RecCur 
return 1
end
GO


Go

exec dbo.DelAtlProc
go

Чистка значений хэша - как правило всегда после установки патчей(там это есть в рекомендациях)

Код: Выделить всё

USE BASE
truncate table xx$hashvalues

Ну а дальше нужно смотреть почему база разраслась.
1. Нужно смотреть на файл журнала - я ставлю требование, что он не должен быть больше 10 гиг
2. System - как правило там не больше 2 гиг
3. Лог - как правило его размер должен быть фиксирован под самую большую транзакцию - от 2 гиг до 50(для очень большой базы + работа переиндексации в агенте)
также попробуйте сжать(Shrink даже без запуска) таблицы - посмотрите сколько там свободного места. Можно сжать с реорганизацией - будет чутка шустрее. Приведите здесь на каждый файл информацию - размер , свободно
Ну и обычное Del tmp*.* по всему диску и прочего мусора. Дефрагментация винта, и так далее.
По чистке галактических данных вам лучше обратиться в ТП. Есть автоматические режимы, что то можно руками подчистить - в общем это отдельная тема.

[Den]

база сильно разраслась, и работает заметно медленнее.

Все, прям-таки, вряд ли разрослось . Работают медленнее, почти наверняка, какие то конкретные процессы (запускаемые внутри гал - будь то расчет остатков каких либо, пакетное проведение ордеров, расчет зэпы, формирование каких то отчетов). Их и нужно анализировать и оптимизировать стараться . Если объемы таблиц некоторых содержат большое кол-во данных (эта цифра неоднозначна - в смысле зависеть может от вашего железа, когда и несколько млн записей уже будут критичны, а может и несколько десятков млн записей быть не критичны), нужно задуматься над обрезкой БД в свете этого (удаление складских ордеров, бух сальдо и проводок и т.п.).
Со стороны hardware можно тоже попробовать что то поделать (если есть ресурсы для этого ). Попробуйте, например, тупо добавить ОЗУ в 2 раза больше на сервак БД. И прогнать тебе самые процессы ДО и ПОСЛЕ сего действа , на предмет посмотреть "станет ли быстрее".

[zna]

Добрый день всем! У нас такая же проблема- тормоза у клиентов с Win10 Pro, ищем причину. Имеется такой зоопарк:
Windows Server 2008 R2 Standard 8-х ядерный 64-х, 3,4..3,9 Ггц, Озу 32 Гб
На нём живут:
1. MS Sql Server 2008 R2 Standard
2. Галактика 9.1.5529, двухуровневая архитектура
3. Пользователи удалённого раб.стола- до 7 сессий одновременно
4. Основная база: System-1,7Gb; Log- 31Gb; Journal- 4Gb; Data- 6Gb
5. Есть доработанные интерфейсы и тяжёленькие процедуры для сводных отчётов
6. Сеть 1гигабит, обмен с сервером ключа пакетами TCP

На клиентах стоят Win10 Pro 16Gb- всё остальное летает, Галактика же тормозит в разных местах
Сервер не сказать, что перегружен:

[zna]

Есть подозрение на то, что MS SQL 2008, хоть он и R2, в связке с Win10 вносят свой вклад в тормоза, т.к. не являются рекомендованной конфигурацией, как это написано в документации softcfg.
Вопросы:
1. Для Win 10, в соответствии с рекомендациями, нужен Ms Sql 2012. Это даст ощутимый прирост на клиенте?
2. Есть мысль развернуть сервер приложений и перевести на него часть клиентов, которые сейчас в терминальном режиме. Это возможно на инсталлированной рабочей двухуровневой архитектуре?

[edward_K]

1. А вы давно запускали оптимизацию? Чистили то, что я писал выше и так далее
2. Советую почитать описания патчей. В частности ms70drv_dll_55330.txt ищем Native
В частности 106.10318 и так далее.
Года три назад драйвер заточили под использование Native Client
Притом просадка на обычном клиенте ODBC была значительная - до 7-10 раз.
Потом добавили параметры в Cfg для переключение оптимизации под основных клиентов
Рекомендуется использовать один тип клиента, поскольку иначе сервер вынужден обслуживать 2 плана выполнения.
Native Client априори шустрее, но иногда при длинных запросах он уходит в suspend(я не админ, подозреваю что дело в настройке сервера, но эмпиричеки установил, что запросы длинее 12 секунд опасны для работы).
Можно последить монитором ресурсов(В Studio в тулбаре) за процессами. Если появляются процесы в suspend, то с ними нужно разбиратся. Там же есть последние ресурсоемкие запросы. Если запрос тяжелый или слишком частый, то нужно искать причину его появления. Это тяжело.
Можно попробовать профайлером отследить(MSSQL или галактическим) аботу конкретного пользователя

3. Очень сильно помогает переключение пользовательских таблиц на локальный кэш (в DataBase параметр)
Там же нужно настроить таблицы для исключения( Pick нарпимер нужен некоторым отчетам на DSQL)
Ну и так далее.
В порядке критичности
1. Сеть
2. Память на сервере СУБД
3. Память на клиентской станции(в том числе и на терминальном сервере).
4. Процессор СУБД
5. Процессор на клиентской станции.
6. Тонкие и не очень настройки системы
7. Оптимизация кода.
Самый медленный процесс остановит всех.
Могу еще привести байку, как клиент меня год убеждал, что у них супер супер сеть. Из доступных средств был только Ping
-зациклив его на вывод в текстовый файл выяснил, что иногда случаются провалы(каждый день в одно и то тоже время - сервера стояли в очень хорошем месте).
В итоге через год поменяли все таки свичи и проблема ушла.
Трехзвенный клиент субъективно выйгрыша не даст - терминал не хуже, но тут нужно пробовать. + Раньше у него были ограничения например по Excel отчетам - не знаю решили или нет.

[zna]

п.1-Хранимые процедуры чищены, дисковая система недавно новая поставлена- тут норм.
п.2- свежая мысль, мы пользуем драйвер ОДВС старый- "SQL Server". В списке драйверов ОДВС есть SQL Server Native client 10.0 (и 11.0)- попробуем их.
Благодарю, Эдвард!