gifts2017

Настройка регламентных работ на SQL сервере + (сбор данных по работе SQL и т.д)

Опубликовал Сергей Пономарёв (izidakg) в раздел Администрирование - Системное

Тема не новая, вариантов найти можно массу. Последнее время появляются статьи с очень подробным описанием, что-то из этого не встречал за всю практику работы с 1С. Фактически эта публикация как памятка основной части 1С-ников, что не имеют глубоких знаний по SQL и 1С. Это готовая инструкция по настройке обслуживания БД на сервере ля большинства мелких и средних компаний\баз. Но бывают случаи поломок баз данных, поэтому приложен материал и для таких случаев, например, восстановление БД после обновления не очень удачного, и некоторые другие плюшки.

Регламентные работы по БД на SQL 

Реакция на эту публикацию оказалась очень неоднозначной, в практике встречал многое, но того что высказано в критике не видел. Что конечно не говорит что этого не может быть. Как говорил оин из моих учителей наставников - "Видишь суслика? Нет? А он есть! Так и с ошибками в коде любой программы." Впрочем это все лирика.

Не буду утверждать что преложенный регламент обслуживания подойдет всем. Также отмечу что SQL server развивается и регламент обслуживания также может претерпеть изменения. Текущий пример регламента прелагаю использовать всем малым и средним компаниям. Навредить предложенный регламент не может. После описания регламента приведены запросы по более детальному анализу скульной БД, ремонт БД (2 типовые ошибки), запуск отладки на сервере, режимы запуска 1С (+ в файле есть описание для тех кто потерял ключи от БД, только для баз на сервере).

Базы данных нынче очень тяжелые, раньше делал регламент по бэкапам средствами SQL каждые 4 часа на базе размером более 20 Gb. Сейчас на более сильном железе это дает ошибки транзакции, что бесит пользователей. Поэтому теперь все делаем ночью. Встречается, что бэкап средствами SQL при разворачивании оказывается нерабочим, поэтому предпочитаю бэкапы средствами 1С (ВНИМАНИЕ: 1С рекомендует бэкапы средствами скуля делать). Скрипт по запуску на сервере прилагаю ниже.

В приложенном файле собрано много чего: работа с файлами (скрипты cmd) и их можно в регламент SQL смело вставлять при необходимости, перезапуск ragent (сервера), собранные материалы из статьи ниже (на всякий случай все проверил на живом\рабочем сервере), решение некоторых ошибок связанных с обновление (БД разрушена, недоступна или БД не выгружается через конфигуратор), кратко памятка основных и часто используемых команд по входу в БД (блокировка, лог, отладка серверных процедур и т.д), регламентные работы на сервере и возврат доступа к БД на сервере. Приложены ссылки на похожие публикации.

Самая упрощенная схема реламента эта бэкап средствами 1С раз в неделю. А обслуживание БД состоит из 4 заданий: Шринкование (вручную или раз в неделю автоматом), реиндексация, обновление статистики, очистка процедураного кэша.

В качестве примера приведена БД "ara2014"

Обслуживание SQL (пример большой статьи по индексам и т.д на SQL):
http://infostart.ru/public/308762/

+++++++++++++++++++++++++++++++++++++++++++++++++++++

Запуск конфигуратора для создания бэкапа БД 1С (вход в заблокированную БД, файл с пропиской тек. даты, запись лога работы сеанса):

Пользователь Б -"exchange", пароль БД - "exc878787", имя файла с датой - "1Cv8_ARA_%date:~6,4%%date:~3,2%%date:~0,2%.dt", код блокировки (как и пароль как вы указали) - "55513", и имя лога работы сеанса 1С.

"C:\Program Files (x86)\1cv82\common\1cestart.exe" CONFIG /S"winsrv02\ara2014" /N"exchange" /P"exc878787" /DumpIB"C:\1C\Arxiv\1Cv8_ARA_%date:~6,4%%date:~3,2%%date:~0,2%.dt" /UC55513 /Out"C:\1C\Arxiv\LOGBackupARA.txt" -NoTruncate

+++++++++++++++++++++++++++++++++++++++++++++++++++++

Шринкование БД (вручную, если ставите в атоматическое выполнение, то раза в неделю остаточно):

USE [ara2014]
GO
DBCC SHRINKDATABASE(N'ara2014' )
GO

+++++++++++++++++++++++++++++++++++++++++++++++++++++

Реиндексация базы данных (раз в сутки, в не рабочее время) (рекомендовано от 1С):

DECLARE reindex_cursor CURSOR 

FOR 

SELECT name FROM sysobjects WHERE type = 'U'

OPEN reindex_cursor

DECLARE @tablename sysname

FETCH NEXT FROM reindex_cursor INTO @tablename 

WHILE (@@FETCH_STATUS <> -1)

BEGIN

EXECUTE ('DBCC DBREINDEX (''' + @tablename + ''')')

FETCH NEXT FROM reindex_cursor INTO @tablename

END          

CLOSE reindex_cursor

DEALLOCATE reindex_cursor

+++++++++++++++++++++++++++++++++++++++++++++++++++++

Обновление статистики базы данных (один или несколько раз в день) (рекомендовано от 1С):

exec sp_msforeachtable N'UPDATE STATISTICS ? WITH FULLSCAN'
DBCC UPDATEUSAGE (ara2014)

+++++++++++++++++++++++++++++++++++++++++++++++++++++

Очистка процедураного кэша СУБД (после обновления статистики) (рекомендовано от 1С):

DBCC FREEPROCCACHE


ДОПОЛНИТЕЛЬНЫЕ СКРИПТЫ ОБСЛУЖИВАНИЯ SQL сервера:

Временами, при восстановлении базы из архива может сбиться настройка смещения дат, что чревато серьезными проблемами. 
Проверить настройку смещения дат можно следующим скриптом: 

SELECT TOP 1 Offset FROM _YearOffset

Для оценки самых тяжелых запросов я использую немного другие скрипты: 

1. Топ 10 самых тяжелых для процессора: 

SELECT TOP 10 
 [Average CPU used] = total_worker_time / qs.execution_count
,[Total CPU used] = total_worker_time
,[Execution count] = qs.execution_count
,[Individual Query] = SUBSTRING (qt.text,qs.statement_start_offset/2, 
         (CASE WHEN qs.statement_end_offset = -1 
            THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2 
          ELSE qs.statement_end_offset END - 
qs.statement_start_offset)/2)
,[Parent Query] = qt.text
,DatabaseName = DB_NAME(qt.dbid)
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt
ORDER BY [Average CPU used] DESC;

2. Топ 10 самых тяжелых по вводу/выводу: 

SELECT TOP 10 
 [Average IO] = (total_logical_reads + total_logical_writes) / qs.execution_count
,[Total IO] = (total_logical_reads + total_logical_writes)
,[Execution count] = qs.execution_count
,[Individual Query] = SUBSTRING (qt.text,qs.statement_start_offset/2, 
         (CASE WHEN qs.statement_end_offset = -1 
            THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2 
          ELSE qs.statement_end_offset END - qs.statement_start_offset)/2) 
        ,[Parent Query] = qt.text
,DatabaseName = DB_NAME(qt.dbid)
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt
ORDER BY [Average IO] DESC;

Статистика ввода/вывода по файлам баз данных: 

USE master
GO
SELECT TOP 10    DB_NAME(saf.dbid)           AS [База данных]
    ,    saf.name                            AS [Логическое имя]
    ,    vfs.BytesRead/1048576               AS [Прочитано (Мб)]
    ,    vfs.BytesWritten/1048576            AS [Записано (Мб)]
    ,    saf.filename                        AS [Путь к файлу]
FROM        sysaltfiles                      AS saf
JOIN    ::    fn_virtualfilestats(NULL,NULL) AS vfs
ON        vfs.dbid = saf.dbid 
AND        vfs.fileid = saf.fileid
AND        saf.dbid NOT IN (1,3,4)
ORDER BY vfs.BytesRead/1048576 + BytesWritten/1048576 DESC
GO

Статистика ввода/вывода по дискам: 

SELECT   SUBSTRING(saf.physical_name, 1, 1)        AS [Диск]
       , SUM(vfs.num_of_bytes_read/1048576)        AS [Прочитано (Мб)]
       , SUM(vfs.num_of_bytes_written/1048576)     AS [Записано (Мб)]
FROM     sys.master_files                          AS saf
JOIN     sys.dm_io_virtual_file_stats(NULL,NULL)   AS vfs
ON     vfs.database_id = saf.database_id 
AND     vfs.file_id = saf.file_id
AND     saf.database_id NOT IN (1,3,4)
AND     saf.type < 2
GROUP BY SUBSTRING(saf.physical_name, 1, 1)
ORDER BY [Диск]
GO

Производительность журнала транзакций: 

SELECT (wait_time_ms - signal_wait_time_ms) / waiting_tasks_count AS [Время отклика долговременного носителя журнала (ms)],    
       max_wait_time_ms                                           AS [Максимальное время ожидания (ms)]
FROM  sys.dm_os_wait_stats
WHERE wait_type = 'WRITELOG' AND waiting_tasks_count > 0;

Многострадальный sys.dm_exec_query_stats можно еще использовать так, топ 30 запросов по длительности блокировки: 

SELECT TOP 30 
 (total_elapsed_time - total_worker_time) / qs.execution_count AS [Average Time Blocked],
 total_elapsed_time - total_worker_time AS [Total Time Blocked],
 qs.execution_count AS [Execution count],
 SUBSTRING (qt.text,qs.statement_start_offset/2,
         (CASE WHEN qs.statement_end_offset = -1 
            THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2 
          ELSE qs.statement_end_offset END - qs.statement_start_offset)/2) AS [Individual Query], 
 qt.text [Parent Query],
 DB_NAME(qt.dbid) AS [Database name]
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt
/* этот кусок отберет по базе, если надо по всем - удалить */
 /*WHERE DB_NAME(qt.dbid)='ИмяБазы'*/
 ORDER BY [Average Time Blocked] DESC;

Наблюдаем за памятью: если Free Pages меньше 300, объем ОЗУ узкое место в производительности системы: 

SELECT * FROM sys.sysperfinfo  where counter_name like 'Page Writes%' or counter_name like 'Page reads%' 
or counter_name like 'lazy%' or counter_name like 'Page Life%' or counter_name like 'Memory Grants Pending%'
or (counter_name = 'Free pages' and [object_name] LIKE '%BUFFER MANAGER%')

Перекрывающаяся статистика: 

WITH    autostats ( object_id, stats_id, name, column_id )
 AS ( SELECT   sys.stats.object_id ,
 sys.stats.stats_id ,
 sys.stats.name ,
 sys.stats_columns.column_id
FROM     sys.stats
 INNER JOIN sys.stats_columns ON sys.stats.object_id = sys.stats_columns.object_id
 AND sys.stats.stats_id = sys.stats_columns.stats_id
 WHERE    sys.stats.auto_created = 1
 AND sys.stats_columns.stats_column_id = 1
 )
 SELECT  OBJECT_NAME(sys.stats.object_id) AS [Table] ,
 sys.columns.name AS [Column] ,
 sys.stats.name AS [Overlapped] ,
 autostats.name AS [Overlapping] ,
 'DROP STATISTICS [' + OBJECT_SCHEMA_NAME(sys.stats.object_id)
 + '].[' + OBJECT_NAME(sys.stats.object_id) + '].['
 + autostats.name + ']'
 FROM    sys.stats
 INNER JOIN sys.stats_columns ON sys.stats.object_id = sys.stats_columns.object_id
 AND sys.stats.stats_id = sys.stats_columns.stats_id
 INNER JOIN autostats ON sys.stats_columns.object_id = autostats.object_id
 AND sys.stats_columns.column_id = autostats.column_id
 INNER JOIN sys.columns ON sys.stats.object_id = sys.columns.object_id
 AND sys.stats_columns.column_id = sys.columns.column_id
 WHERE   sys.stats.auto_created = 0
 AND sys.stats_columns.stats_column_id = 1
 AND sys.stats_columns.stats_id != autostats.stats_id
 AND OBJECTPROPERTY(sys.stats.object_id, 'IsMsShipped') = 0

Статистика ожиданий (более информативно чем перекрывающаяся статистика): 

WITH [Waits] AS
    (SELECT
        [wait_type],
        [wait_time_ms] / 1000.0 AS [WaitS],
        ([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS],
        [signal_wait_time_ms] / 1000.0 AS [SignalS],
        [waiting_tasks_count] AS [WaitCount],
        100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage],
        ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum]
    FROM sys.dm_os_wait_stats
    WHERE [wait_type] NOT IN (
        N'BROKER_EVENTHANDLER',         N'BROKER_RECEIVE_WAITFOR',
        N'BROKER_TASK_STOP',            N'BROKER_TO_FLUSH',
        N'BROKER_TRANSMITTER',          N'CHECKPOINT_QUEUE',
        N'CHKPT',                       N'CLR_AUTO_EVENT',
        N'CLR_MANUAL_EVENT',            N'CLR_SEMAPHORE',
        N'DBMIRROR_DBM_EVENT',          N'DBMIRROR_EVENTS_QUEUE',
        N'DBMIRROR_WORKER_QUEUE',       N'DBMIRRORING_CMD',
        N'DIRTY_PAGE_POLL',             N'DISPATCHER_QUEUE_SEMAPHORE',
        N'EXECSYNC',                    N'FSAGENT',
        N'FT_IFTS_SCHEDULER_IDLE_WAIT', N'FT_IFTSHC_MUTEX',
        N'HADR_CLUSAPI_CALL',           N'HADR_FILESTREAM_IOMGR_IOCOMPLETION',
        N'HADR_LOGCAPTURE_WAIT',        N'HADR_NOTIFICATION_DEQUEUE',
        N'HADR_TIMER_TASK',             N'HADR_WORK_QUEUE',
        N'KSOURCE_WAKEUP',              N'LAZYWRITER_SLEEP',
        N'LOGMGR_QUEUE',                N'ONDEMAND_TASK_QUEUE',
        N'PWAIT_ALL_COMPONENTS_INITIALIZED',
        N'QDS_PERSIST_TASK_MAIN_LOOP_SLEEP',
        N'QDS_CLEANUP_STALE_QUERIES_TASK_MAIN_LOOP_SLEEP',
        N'REQUEST_FOR_DEADLOCK_SEARCH', N'RESOURCE_QUEUE',
        N'SERVER_IDLE_CHECK',           N'SLEEP_BPOOL_FLUSH',
        N'SLEEP_DBSTARTUP',             N'SLEEP_DCOMSTARTUP',
        N'SLEEP_MASTERDBREADY',         N'SLEEP_MASTERMDREADY',
        N'SLEEP_MASTERUPGRADED',        N'SLEEP_MSDBSTARTUP',
        N'SLEEP_SYSTEMTASK',            N'SLEEP_TASK',
        N'SLEEP_TEMPDBSTARTUP',         N'SNI_HTTP_ACCEPT',
        N'SP_SERVER_DIAGNOSTICS_SLEEP', N'SQLTRACE_BUFFER_FLUSH',
        N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
        N'SQLTRACE_WAIT_ENTRIES',       N'WAIT_FOR_RESULTS',
        N'WAITFOR',                     N'WAITFOR_TASKSHUTDOWN',
        N'WAIT_XTP_HOST_WAIT',          N'WAIT_XTP_OFFLINE_CKPT_NEW_LOG',
        N'WAIT_XTP_CKPT_CLOSE',         N'XE_DISPATCHER_JOIN',
        N'XE_DISPATCHER_WAIT',          N'XE_TIMER_EVENT')
    )
SELECT
    [W1].[wait_type] AS [WaitType],
    CAST ([W1].[WaitS] AS DECIMAL (16, 2)) AS [Wait_S],
    CAST ([W1].[ResourceS] AS DECIMAL (16, 2)) AS [Resource_S],
    CAST ([W1].[SignalS] AS DECIMAL (16, 2)) AS [Signal_S],
    [W1].[WaitCount] AS [WaitCount],
    CAST ([W1].[Percentage] AS DECIMAL (5, 2)) AS [Percentage],
    CAST (([W1].[WaitS] / [W1].[WaitCount]) AS DECIMAL (16, 4)) AS [AvgWait_S],
    CAST (([W1].[ResourceS] / [W1].[WaitCount]) AS DECIMAL (16, 4)) AS [AvgRes_S],
    CAST (([W1].[SignalS] / [W1].[WaitCount]) AS DECIMAL (16, 4)) AS [AvgSig_S]
FROM [Waits] AS [W1]
INNER JOIN [Waits] AS [W2]
    ON [W2].[RowNum] <= [W1].[RowNum]
GROUP BY [W1].[RowNum], [W1].[wait_type], [W1].[WaitS],
    [W1].[ResourceS], [W1].[SignalS], [W1].[WaitCount], [W1].[Percentage]
HAVING SUM ([W2].[Percentage]) - [W1].[Percentage] < 95; -- percentage threshold
GO

Восстановление баз данных:

Восстановление SQL базы 1С 8.2. рухнувшей во время сохранения конфигурации:
("Внимание!!! При обновлении данных, после последней реструктуризации, произошла критическая ошибка. Повторить обновление?")

Сразу уточним, что конфигуратор не открывается, а если открывается, продолжение обновления вываливается в ошибку. Итак в открытом окне SQL Managment Studio ищем нашу базу - открываем Таблицы, ищем в конце списка таблицу с конфой dbo.config на таблице - правую кнопку - Открыть таблицу. Далее в правом окне спускаемся в самой таблице вниз по алфавиту на поле где FileName  = "commit". Встаем на эту запись - правую кнопку мыши - Удалить. В общем удаляем  запись с двоичным файлом. Далее пробуем зайти в конфу. Ошибка та же самая первая появляется. Наверно не получилось? Нажимаем Ок. И тут, прежде чем выдать как ранее 2-е сообщение о невозможности сохранить -  компьютер задумался. Спустя секунд 30! Конфигуратор открылся. Пробуем сохранить конфигуратор (предварительно сохранив cf файл). Конфигуратор сохраняется. Таким образом и волки сыты и овцы целы. 
Не уверен насчет полной работоспосбности базы после таких измывательств - так что посоветую сделать реструтуризацию и пересчет итогов уже потом вечером (предварительно конечно же сделав архив).

----------------------------------------------------
Ошибка SDBL (Возникает при обновлении конфигурации ИБ): Для полей, начиная с FileName, не хватило значений (pos=19)

Лечится путем запуска в консоли SQLсервера команд:

TRUNCATE TABLE _ConfigChangeRec
TRUNCATE TABLE _ConfigChangeRec_ExtProps

----------------------------------------------------

Отладка на сервере

Иногда возникает необходимость отладки серверных процедур 1С при работе с программой в клиент-серверном варианте. По умолчанию отладка на сервере 
выключена. Существует, по крайней мере, два способа:

Можно сделать выгрузку конфигурации и развернуть ее в файловом варианте.
Можно включить отладку серверных процедур, запустив агента сервера с параметром debug.
Остановимся на последнем варианте более подробно.Алгоритм примерно следующий:

Останавливаем службу 1C:Enterprise 8.2 Server Agent, например, вот так: "C:\Program Files (x86)\1cv82\8.2.19.130\bin\ragent.exe" –stop
В системном реестре находим ветку «HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\1C:Enterprise 8.2 Server Agent» и для параметра «ImagePath» добавляем «-debug».
Было: "C:\Program Files (x86)\1cv82\8.2.19.130\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files (x86)\1cv82\srvinfo"
Стало:"C:\Program Files (x86)\1cv82\8.2.19.130\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files (x86)\1cv82\srvinfo" -debug

Запускаем службу.
Запускаем 1С:Предприятие в обычном режиме, заходим в меню «Сервис - Параметры», закладка «Системные». Проверяем, чтобы было отмечено: «Отладка разрешена».
Запускаем 1С:Предприятие в режиме Конфигуратора, заходим в меню «Отладка - Подключение», нажимаем кнопку «Автоматическое подключение», выбираем необходимые типы подключения.

Варианты запуска

***********[ вход в заблокированную базу (файловая\SQL) ]*************************

"C:\Program Files (x86)\1cv8\common\1cestart.exe" ENTERPRISE /F"C:\LocalBase8\Demo\DemoTrd" /UC555

"C:\Program Files (x86)\1cv8\common\1cestart.exe" ENTERPRISE /S"sky-1\trd" /UC555

"C:\Program Files (x86)\1cv8\common\1cestart.exe" CONFIG /F"C:\LocalBase8\Demo\DemoTrd" /UC555

"C:\Program Files (x86)\1cv8\common\1cestart.exe" CONFIG /S"sky-1\trd" /UC555

***********[ выгрузка базы данных ]*************************

"C:\Program Files (x86)\1cv8\common\1cestart.exe" CONFIG /S[my_server]\[my_base] /N[привелигерованая_учетка] /P[пароль] /DumpIB"[путь_приема_файла]\backup.dt"

move "[путь_приема_файла]\backup.dt" "[путь_приема_файла]\%date%.dt"


"C:\Program Files (x86)\1cv8\common\1cestart.exe" CONFIG /F"C:\LocalBase8\Demo\DemoTrd" /N"exchange" /P"exc878787" /DumpIB"C:\NS\Arxiv_1С8\Accounting_%date:~0,2%.%date:~3,2%.%date:~6,4%.dt"

"C:\Program Files (x86)\1cv8\common\1cestart.exe" CONFIG /S"sky-1\trd" /N"exchange" /P"exc878787" /DumpIB"C:\NS\Arxiv_1С8\Trd\1Cv8_Trd_%date:~0,2%.%date:~3,2%.%date:~6,4%.dt"

// Бэкап заблокированной базы
"C:\Program Files (x86)\1cv8\common\1cestart.exe" CONFIG /S"sky-1\trd" /UC555 /N"exchange" /P"exc878787" /DumpIB"C:\NS\Arxiv_1С8\Trd\1Cv8_Trd_%date:~0,2%.%date:~3,2%.%date:~6,4%.dt"


***********[ Запуск с записью в лог ]*************************

"C:\Program Files (x86)\1cv8\common\1cestart.exe" CONFIG /S"sky-1\ara" /UC55513 /Out"E:\Distr_1C8\Update\Error.txt" -NoTruncate

"C:\Program Files (x86)\1cv8\common\1cestart.exe" /UC55513 /Out"E:\Distr_1C8\LOG\Error_%date:~6,4%%date:~3,2%%date:~0,2%.txt" -NoTruncate

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

P.S. Регламент обслуживания без правильной настройки сервера толку много не даст и дублировать хорошо написанное не вижу смысла, поэтому очень рекомендую ознакомится с публикацией http://infostart.ru/public/65955/

Скачать файлы

Наименование Файл Версия Размер Кол. Скачив.
Регламент обслуживания на сервер (ПЛЮС)
.7z 2,89Mb
10.09.16
19
.7z 2,89Mb 19 Скачать

См. также

PowerTools от 1 000
Подписаться Добавить вознаграждение

Комментарии

1. Сергей Рудаков (fishca) 13.09.16 14:09
ну сколько же можно пережевывать?
2. Сергей Рудаков (fishca) 13.09.16 14:12
"C:\Program Files (x86)\1cv82\common\1cestart.exe" CONFIG /S"winsrv02\ara2014" /N"exchange" /P"exc878787" /DumpIB"C:\1C\Arxiv\1Cv8_ARA_%date:~6,4%%date:~3,2%%date:~0,2%.dt" /UC55513 /Out"C:\1C\Arxiv\LOGBackupARA.txt" -NoTruncate
Хотя бы расписал какие параметры подставить куда, а то у меня сервера winsrv02 не было и не будет :)
C:\Program Files (x86)\1cv82 - для версии 8.3 как будет выглядеть?
3. Alexander Speshilov (speshuric) 13.09.16 16:29
(0) НЕ НАСТРАИВАЙТЕ ТАК SQL SERVER!!!
1. Шринковать нельзя. Это вредно для производительности.
2. Ваш скрипт по переиндекации нещадно заполняет журнал транзакций, использует устаревший синтаксис SQL 2000 и вешает всю работу (даже там, где этого можно избежать).
3. Обновление статистики лучше производить с учетом переиндексации (ребилд индекса вполне может собрать статистику, если ему не запретить). Уж у меня-то насколько устарела статья http://infostart.ru/public/256292/ - и то лучше, чем так.
4. Для современных версий SQL FREEPROCCACHE лучше применять ОЧЕНЬ обоснованно. Но это, пожалуй, самая безобидная рекомендация.
5. Бэкап средставми 1С - не бэкап. http://infostart.ru/public/173494/ - тоже старо, но тоже правильнее.
6. По каждому из диагностических скриптов можно написать отдельную статью, что они показывают (крайне важно правильно это интерпретировать). Почитайте Glenn Berry и Brent Ozar. У них этой диагностики на порядок больше и внятно разжёвано.
IfYouWant_YouCan; gadjik; Артано; Tavalik; cleaner_it; aexeel; alyaev.a.v; m_aster; DeD MustDie; digital; Дмитрий74Чел; Solovyeff; meuses; awk; +14 Ответить 2
4. Александр Аляев (alyaev.a.v) 13.09.16 17:28
Прочитал про "предпочитаю бэкапы средствами 1С" дальше читать желание пропало.
Даже сами 1с не рекомендуют http://its.1c.ru/db/metod8dev/content/2922/hdoc/
IfYouWant_YouCan; Tavalik; aexeel; Дмитрий74Чел; +4 Ответить 1
5. Василий Казьмин (awk) 13.09.16 18:12
Ох не люблю, но придется минусовать.
Tavalik; Дмитрий74Чел; +2 Ответить
6. Сергей Пономарёв (izidakg) 13.09.16 21:54
(2) fishca, расписывать смысла не вижу
во первых если интуитивно непонятно про что речь, то лучше не делать вовсе
что касается как в 8.3 - также. единственное что в документации написано что версия 8.3 ставится в C:\Program Files, возможно неправильно на кнопки нажимаю, но у меня ставится в C:\Program Files (x86)
я храню эти файлы со скриптами как шаблоны и для конкретного случая заменяю пути, как правило место хранения архивов или логов у всех различны

7. Сергей Пономарёв (izidakg) 13.09.16 22:02
(4) alyaev.a.v, рекомендации это хорошо, возможно даже что еще ни разу вы не нарвались на исключения. могу только пожелать вам и дальше идеальных согласно инструкции ситуаций.
мне так не везет, вот пример - в одной конторе стоит PostgreSQL, бэкапы делаются, НО БД из этого бэкапа не разворачивается. Делали все что только можно и без результата.
Ну а рекомендация это ведь не указание. 1С также рекомендует регулярно проводить тестирование БД, а что делать если БД более 50 Гб и используется ежедневно без выходных с пропуском ночью около 7 ч максимум?
8. Сергей Пономарёв (izidakg) 13.09.16 22:37
(3) speshuric,
1. Да вредно, поэтому там не написано что это рекомендовано 1С. К сожалению без этой операции очень часто не обойтись. Чисто из практики - часто встречаете админа хорошо настраивающего 1С базы на скуле или 1С-ника знающего администрирование? Ситуации разные бывают. Вот один из дурных примеров - на сервере свободно 5 гб и лог базы съедает их за 3-4 дня, а так все счастливы.
2. Написан давно и вроде не чайником. возможно скрипт устарел, ознакомлюсь с вашим, возможно статью в этом разрезе поправлю.
3. в общем аналогично п.2, хотя в техподдержке дали эту команду как рекомендованную и на сайтах часто этот пример приводили. пользовался этим скриптом много лет и только недавно на сайтах увидел что в основном используют:
exec sp_msforeachtable N'UPDATE STATISTICS ? WITH FULLSCAN'
мне еще в далеком 2003 рекомендовали использовать с:
DBCC UPDATEUSAGE (ara2014)
4. была рекомендация, вот и использую. Думаю вопрос конкретной ситуации. Некоторые вот наоборот возмущены что не по рекомендациям, а тут по рекомендации и снова плохо?
5. Уже в комментариях писал что случаи бывают разные. Для больших баз и хороших контор, где все сделано вами с любовью к делу - ДА, лучше средствами скуля. У меня конторы сплошь "неправильные" и очень часто начинаю с восстановления убитой БД.
6. Диагностические скрипты приведены для примера\ознакомления. Можно сказать стимул разобраться. жаль что мне в свое время эти примеры не попались. Взяты как раз из одной из больших статей, ссылка в начале. Считаю что начинающим нужно обратить внимание, может кому и поможет.

Эта публикация как шаблон\памятка, рекомендованные пункты отмечены, для тех 1С-ников что не обладают обширными знаниями, профессионалы конечно многое дополнят или изменят, опят же по ситуации.
Пока собирал все это сам прекрасно понял, что многое поменялось за последние лет 10, поэтому сбор материала продолжаю и если руки дойдут, все дополню и выложу.
9. Артано Майаров (Артано) 14.09.16 07:38
Впечатления неоднозначные от статьи.
Достаточно сумбурно изложен текст. Оформление хромает.
Есть претензии к самой сути статьи. Более подробно и обстоятельно опытные товарищи уже указали выше в (3). Это и подход к бэкапированию и к обслуживанию индексов.

Но сама задумка статьи здравая. Поэтому прошу автора в самом начале статьи сделать жирным шрифтом оговорку, что рекомендации по обслуживанию могут помочь и скорее всего не навредить, только для небольших баз в небольших конторах, где неоптимальный тюнинг, будет лучше чем отсутствие какой-либо настройки вообще.
IfYouWant_YouCan; cleaner_it; aexeel; izidakg; +4 Ответить
10. Сергей Зверев (serferian) 14.09.16 08:32
Скрипты по лечению ошибки ("Внимание!!! При обновлении данных, после последней реструктуризации, произошла критическая ошибка. Повторить обновление?")
use [ИмяБазы]
delete from [Config] where FileName = 'commit'
delete from [Config] where FileName = 'dbStruFinal'

заходим в конф и обновляемся
11. Александр Аляев (alyaev.a.v) 14.09.16 11:00
(7) izidakg, из вашего же ответа "Делали все что только можно и без результата" опять читается уровень спецов. Если уж не умеете работать с бэкапами, то копируйте тупо файло базы, уж все проще будет развернуть потом чем из ДТ 50гб базу восстанавливать.
Набор скриптов выглядит так:у меня куча фалов с непонятными скриптами которые я когдато по неопытности запускал для чего то, и что то из них помогало но не знаю что, вот пользуйтесь.
12. Сергей Пономарёв (izidakg) 14.09.16 11:40
(11) alyaev.a.v, Статья немного сумбурная, не спорю, а вот обижаться не стоит. Как и копировать скульные файлы для создания бэкапа.
Ругать других и называть плохими спецами к сожалению принято везде, особенно своих предшественников. Да бывает что все сказанное правда, Но ситуации бывают разные. Встречал базы, что работают, но не выгружаются средствами 1С из скуля, а ведь полное тестирование и исправление там не всегда возможно и нужно выгрузить в файловый вариант чтобы восстановить.
Моя практика более чем на 70% это работа со средними и мелкими базами среднего бизнеса, есть крупные, но с кучей мелких баз и все это как правило полудохлое и хронически подыхающее. Поэтому лично я хорошо осведомлен об уровне поддерживающих специалистов, о жадности собственников на нормальное железо и т.д. Воспринимайте эту статью как тревожный чемоданчик скорой помощи ля тех кто не научился еще.
Статью в любом случае постараюсь дополнить и причесать, да и с критикой в целом согласен.
13. Михаил Краснобаев (milo1) 14.09.16 15:38
Если речь идет о MSSQL, то чем плох агент в менеджмент студии, который будет делать по расписанию все эти задачи - реиндексацию, обновление индексов, сжатие и тд и тп?
14. Сергей Пономарёв (izidakg) 14.09.16 16:01
(13) milo1, ни чем, собственно задания для плана регламента как раз для него и расписаны тут.
Не думал что столь старая тема будет во внимании таком, тут еще клиент один попросил с PostgreSQL регламент настроить, думаю нужно все комментарии учесть и дописать эту публикацию более подробно
15. Alexander Speshilov (speshuric) 15.09.16 01:35
(8) izidakg,
Если разово надо уменьшить БД на SQL - это и мышкой в SSMS можно сделать. Хотя скорее всего сразу после этого надо будет делать выделение нормального объёма и перестроение индексов, а тот, кто может сделать эти две операции уже может и сам выбрать способ сжатия.

По перестроению иднексов и обновлению статистики ситуация не такая простая, как кажется.
1. Начнем с того, что на AllFlash массивах, на SSD и на массивах, где достаточный SSD кэш влияние фрагментации не такое сильное как раньше. Точнее оно там уже вообще на грани погрешности.
2. Фрагментация сильнее всего влияет на проход по большому диапазону, а не на "точечных" поисках - то есть всегда возникает вопрос: а почему у вас фрагментация так сильно влияет?
3. Дефрагментация/перестроение очень ресурсоёмкая операция и она мешает работе. Если у вас Standard редакция, то нет возможности перестроить индекс не блокируя его, с другой стороны, если у вас Enterprise, который сейчас стоит пару годовых зарплат хорошего DBA, то пусть этим занимается DBA. Во время перестроения и дефрагментации диски/память/процессора используются достаточно активно, и даже если блокировки не мешают, то работать сложно. Ну и огромные (по количеству изменений) транзакции приводят к тому, что LDF становится примерно как база.
То есть дефрагментация/перестроение требуют внятного обоснования, а не "профилактического" подхода, под них надо выделять окно (разводя с бэкапами, работой пользователей и обслуживанием). Обновление статистики операция чуть полегче (записи нет), но всё равно: чтение с диска, процессор, блокировки (хоть и Sch-S). При этом статистику имеет смысл пересчитывать вовсе не на всех таблицах, да еще и она обновляется "бесплатно" при перестроении индекса.
1С когда дает эту рекомендацию при вполне конкретных симптомах и не приводя именно этих примеров (про раз в сутки полное перестроения точно ничего нет). Так что не надо "стрелки переводить". В вашей статье это изнасилование БД предлагается делать несколько раз в извращённой форме.
У вас приведен один из худших скриптов по перестроению, если хочется пальцем в вендора тыкать, то возьмите хоть из MSDN - пример D

И перестроение/дефрагментация, и обновление статистик, и, тем более FREEPROCCACHE применяются в конкретной ситуации по конкретной клинической картине. Это как с лекарствами - в одних обстоятельствах нужно, а в других навредит. После ваших рекомендаций выживут только те, у кого и без вас всё замечательно.

Про бэкапы. Еще раз: выгрузка ИБ в dt - не бэкап. 1C рекомендует делать бэкап средствами СУБД. Бэкап SQL настраивается мышкой за 15 минут. Тем более его надо делать, когда видишь "убитую БД". Тем более, что ненастроенность резервного копирования - самая частая причина "на сервере свободно 5 гб и лог базы съедает их за 3-4 дня". Куда и зачем у вас там лог растет? Что показывает log_reuse_wait_desc?
Пример с PostgreSQL из (7) тоже показателен. Хочешь простого обслуживания и легкодоступных специалистов - плати за MS. Не хочешь платить MS - ищи дефицитных специалистов.

Вы позиционируете статью как "для начинающих" и при этом вываливаете им на дорогу кучу граблей и сомнительных советов - это чтобы "стоя и в гамаке"?

Ваша диагностика им никак не поможет:
1. Запросы к sys.dm_exec_query_stats выводят только те запросы, что есть в кэше. Для типовой БД 1С это может и половины не составить. К тому же вы их сортируете по "Average ...". Ну запускается у меня пару раз в час отчет на 5 минут - и что? На работе остальных пользователей это хоть как-то сказывается? Если нет, то зачем лечить? Чуть ниже вы почему-то total_elapsed_time - total_worker_time трактуете как "время блокировки". С чего бы? И потом неопытных специалистов от этих заблуждений пару лет лечить придётся.
2. В fn_virtualfilestats выбрали самые ненужные показатели. Там же есть IoStallReadMS, IoStallWriteMS и IoStallMS! Они важны как сами по себе (сколько мы ждали диска), так и деленные на количество операций. А количество записанных/прочитанных мегабайтов почти и даром не нужно.
3. Вместо sys.sysperfinfo пора уже использовать dm_os_performance_counters и не давать некорректных рекомендаций про счетчики. По памяти есть гораздо более точная и корректная диагностика (Glenn Berry - SQL Server Diagnostic Information Queries и Brent Ozar и его sp_Blitz и First Responder Kit)
4. Я вообще не понял фразы про "Статистика ожиданий (более информативно чем перекрывающаяся статистика)". Перекрывающаяся статистика (анализ почти бесполезный) - это "лишние" (на самом деле не всегда) частотные статистики. Статистика ожиданий - это накопленное время ожидания ответа от тех или иных категорий внутренних системных функций. Да, для диагностики второе полезнее. Но у них общего - ровно слово "статистика" в названии.
5. Из sys.dm_os_wait_stats вы какие-то данные вывели (весьма странные, впрочем). А дальше с ними что делать? Вот вы WRITELOG проанализировали. Какой показатель Latency допустимый? А что делать, если у меня ожидания на PAGELATCH? Как будете бороться с CXPACKET (хотя в этом случае скорее вопрос - надо ли с ним бороться)? "Погугли" - плохой ответ. Применительно к 1С далеко не все рекомендации выполнимы и далеко не все будут корректными.

Я считаю, что статья весьма вредна - в ней смешана правда и неправда, старое и новое, грабли и молотки. Именно после таких статей приходится долго и упорно разъяснять специалистам, что они делают вредные вещи.
16. Виталий Онянов (Tavalik) 15.09.16 06:14
Не стал читать статью, так как в корне не согласен даже с первым абзацем, а именно:
1. "Сейчас на более сильном железе это дает ошибки транзакции, что бесит пользователей" - Когда это бэкап журнала транзакций вызывал ошибки на блокировках? Чушь какая-то.
2. "Регламент по бэкапам средствами SQL каждые 4 часа" - А я делаю бэкап журнала транзакций каждые 15 минут на терабайтной базе. 4 часа - может быть очень критично для бизнеса.
3. "Поэтому теперь все делаем ночью" - 4 часа то редко было, а теперь раз в сутки? А в случае сбоя, что вы скажете пользователям? День пропал? Для большой организации это многотысячные убытки.
4. "Встречается, что бэкап средствами SQL при разворачивании оказывается нерабочим, поэтому предпочитаю бэкапы средствами 1С" - Еще одна чушь. Здесь скорее все наоборот.
5. "Самая упрощенная схема реламента эта бэкап средствами 1С раз в неделю или ежедневно" - Раз в неделю? Терабайтная база? Средствами 1С? Ну-ну...
6. "А обслуживание БД состоит из 4 шагов: Шринкование" - Шринк - вредная операция на продуктивной базе.

Вывод: Статья скорее вредная, чем полезная. Увы.
17. Сергей Пономарёв (izidakg) 15.09.16 10:32
(15) speshuric, Если вопрос в методах решения того или иного вопроса по обслуживанию, то да. Скорей всего что-то устарело и наверняка не для каждого случая.
1С рекомендует обслуживать на скуле и данный регламент с их рекомендаций в общем вышел много лет тому назад. И считаю он должен быть. Со многими комментариями согласен и собираю подробно новый материал для обновления публикации, хотя сразу понятно что не все согласятся, ведь ситуации разные бывают. И любое универсальное решение даже не всем подойдет.
18. Сергей Лепинин (IfYouWant_YouCan) 21.11.16 09:26
тот момент когда комментарии полезней самой статьи )
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа