Меню

gilev настройка ms sql server

Настройка регламентов MS SQL Server

Зачем нужна настройка MS SQL

Microsoft SQL Server – мощный сервер СУБД, способный решать множество задач. Одним из преимуществ является его «неприхотливость», или способность работать со вполне приемлемой производительностью «из коробки», с настройками по умолчанию, под лёгкой и умеренной нагрузкой. Благодаря этому, создалось устойчивое мнение, что это простой сервер, который легко администрировать даже начинающему администратору-студенту.

Однако с ростом нагрузки на сервер – возникает ряд проблем, включая производительность баз данных (особенно баз данных 1С Предприятия). Это может сопровождаться высокой загрузкой оборудования, ухудшением времени работы ключевых бизнес-операций, замедлением отклика баз 1С у пользователей, блокировками и другими негативными симптомами.

При аудите подобных проблем, зачастую выясняется, что например:
— не были настроены или по какой-то причине перестали работать регламентные задания по обслуживанию баз данных;
— настройки сервера кардинально расходятся с best practices, оборудование используется неоптимально;

— базы данных не резервируются своевременно, что чревато потерями для бизнеса в случае форс-мажоров.

Эксперты команды gilev.ru умеют настраивать сервер СУБД, чтобы и оборудование использовалось оптимальным образом, и регламенты выполнялись своевременно, и резервные копии изготавливались регулярно и складывались в положенное место. В итоге эффективность работы сервера вырастает, объём жалоб пользователей заметно снижается, уровень спокойствия и общей удовлетворённости клиентов возрастает.

Кроме того, специалисты команды gilev.ru создали отличный инструмент SQLSize, позволяющий мониторить состояние сервера СУБД и отслеживать динамику событий на сервере. Благодаря этому инструменту – появляется возможность быстро отследить ряд сценариев, негативно влияющих на производительность и стабильность работы сервера СУБД, и принять необходимые меры по улучшению ситуации.

Стоимость: 30 000 рублей.

* при повторном обращении возможны скидки.

источник

Настройка сервера 1С и MS SQL Server

Оптимальные настройки СУБД зависят от:

  • Конфигурации компьютера (включая влияние виртуализации, совмещение с ролью терминального сервера, от количества сетевых карт);
  • Количества данных, хранящихся в БД;
  • Отношения количества запросов на чтение к запросам на запись;
  • Наличия других процессов, использующих ресурсы.

    На производительность сервера существенно могут настройки, управляющие поведением мощностей процессора, дисков, доступа к памяти и т.п.

    Например, в целях окономии электропитания процессоры могут «занижать» частоту процессора, что приемлемо для личных компьютеров и совершенно неприемлемо для серверов с 1С.

    В BIOS сервера отключаем все настройки по экономии электропитания процессора.

    Если есть «C1E» — обязательно ОТКЛЮЧАЕМ!!

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

    В некоторых случаях (особенно для HP!) надо зайти в BIOS сервера, и ВЫКЛЮЧИТЬ там пункты, в названии которых есть EIST и C1E.
    Взамен надо там же найти пункты, связанные с процессором, в названии которых есть Turbo Boost, включить Intel SpeedStep и ВКЛЮЧИТЬ их.
    Если в биосе есть общее указание режима энергосбережения — включить его в режим максимальной производительности (он ещё может называться «агрессивный»)

    Обратите внимание, что такие настройки популярны, но бывают исключения, когда вендоры реализуют обозначенные выше настройки и механизмы работы иначе, и тогда может потребоваться не выключать, а включать какие-то пункты, связанные с EIST, SpeedStep и Turbo Boost.

    Не забываем и также и про настройки схемы в операционной системе.

    В конечном итоге надо не ориентироваться на названия этих пунктов, а на итоговые максимальные частоты процессоров. Можно контролировать их утилитой CPU-Z. Приведём пример:

    вот снимок системы на базе процессора i7-4770, тактовой частотой 3.4 ГГц (о чём в явном виде написано в поле Specification: @3.40Ghz). В группе Clocks (Core #0) в пункте Multiplier (множитель) указан весь допустимый для данного процессора диапазон множителей: от 8 до 39. 8 – это состояние покоя, а 39 – это максимально возможный множитель при загрузке одного ядра. Если умножить значение множителя на написанную ниже частоту шины (Bus Speed), в данном случае 99.76 МГц, то получится текущая тактовая частота (Core Speed). В данном случае, 99.76*27 примерно равно 2693.57 МГц. Как видим, это ниже даже паспортной тактовой частоты.
    Допустим, мы проделали некоторый набор изменений, и хотим увидеть разницу. Заходим сюда же, и видим искомый максимальный множитель:

    Но не спешим радоваться, на снимке всего лишь моментально зафиксированная частота одного из ядер. А как обстоит ситуация на остальных ядрах? В новых версиях CPU-Z появилась возможность наблюдать множитель и частоту по всем имеющимся ядрам (меню Tools – Clocks)

    Заходим туда, и видим, что не на всех ядрах множитель максимальный, некоторые ядра «сачкуют»!

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

    Вот теперь уже можно со спокойной совестью запускать тест TPC и смотреть там улучшение результата.

    Внимание! Если выполнять тест CPU-Z внутри виртуальной машины — частоты и множители будут всегда показываться «номинально паспортные», независимо от того, какие они по факту, хост-машина не передаёт виртуалке фактические частоты. Данный тест полезен только в случае, когда выполняется ВНЕ виртуалки.

    Сервера с архитектурой Intel Sandy Bridge и более новые умеют динамически менять частоты процессора.

    Для управления под линуксом отправляем к документации редхат .

    Убедитесь что после настройки схемы энергоснабжения процессор работает на нужной максимальной частоте, заявленной производителем. Для этого посмотрите с помощью утилиты cpu-z на core speed.

    Использование виртуальной среды означает что может быть 4 места где надо проверить влияние настроек на частоты процессора (биос физического сервер, схему электроснабжения хостовой ОС, биос виртуального сервера, схему электроснабжения виртуальной ОС ).

    На серверах 1С и MS SQL Server использование антивирусов (даже сам факт инсталяции без включения) будет приводить к снижению производительности в виде периодических массовых замедлений и подвисаний интерфейса.

    Совмещение ролей сервера 1С и сервера MS SQL Server дает большую производительность, особенно если использовать протокол обмена данных напрямую через память «Shared Memory».

    Для настройки протокола воспользуйтесь статьей http://www.gilev.ru/sqland1c/

    Наши «рекомендуемые практики», полученные на основе опыта выполненных проектов

    Очень многие проекты выполнены нами с помощью MS SQL Server 2008 R2.

    источник

    Архив рубрики: MS SQL Server

    1. Создаем новую базу с таким же именем и такими же по именам и расположению .mdf и .ldf файлами

    2. Останавливаем сервер, подменяем файл .mdf

    3. Стартуем сервер, не обращаем внимания на статус базы

    4. Из «Query Analyzer» выполняем скрипт:

    и запоминаем/записываем значение на случай неудачи ребилда лога.

    6. Перезапускаем SQL Server.

    7. В принципе база должна быть видна (в emergency mode). Можно, например, заскриптовать все объекты.

    8. Из «Query Analyzer» выполняем:

    SQL Server скажет — Warning: The log for database ‘ ’ has been rebuilt.

    9. Если все нормально, то там же выполняем:

    9a.
    Если Вам не удалось перевести базу в single user mode, то для проверки целостности данных можно попробовать dbo only mode
    sp_dboption », ‘dbo use only’, ‘true’

    Обновление статистики базы данных

    MS SQL Server строит план запроса на основании статистической информации о распределении значений в индексах и таблицах. Статистическая информация собирается на основании части (образца) данных и автоматически обновляется при изменении этих данных. Иногда этого оказывается недостаточно для того, что MS SQL Server стабильно строил наиболее оптимальный план выполнения всех запросов.
    В этом случае возможно проявление проблем с производительностью запросов. При этом в планах запросов наблюдаются характерные признаки неоптимальной работы (неоптимальные операции).

    Для того, чтобы гарантировать максимально правильную работу оптимизатора MS SQL Server рекомендуется регулярно обновлять статистики базы данных MS SQL.

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

    exec sp_msforeachtable N’UPDATE STATISTICS ? WITH FULLSCAN’
    Обновление статистик не приводит к блокировке таблиц, и не будет мешать работе других пользователей. Статистика может обновляться настолько часто, насколько это необходимо. Следует учитывать, что нагрузка на сервер СУБД во время обновления статистик возрастет, что может негативно сказаться на общей производительности системы.

    Оптимальная частота обновления статистик зависит от величины и характера нагрузки на систему и определяется экспериментальным путем. Рекомендуется обновлять статистики не реже одного раза в день.

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

    Поэтому в общем случае, путем анализа планов запроса можно установить, какие таблицы больше других нуждаются в частом обновлении статистик, и настроить две (или более) различных регламентных процедуры: для часто обновляемых таблиц и для всех остальных таблиц. Такой подход позволит существенно снизить время обновления статистик и влияние процесса обновления статистики на работу системы в целом.

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

    Например, в период минимальной нагрузки на систему — в ночные часы.

    Можно сделать, например, так: В MS SQL:

    1) Создайте новый план обслуживания

    2) Создайте субплан (Add Subplan) и назовите его «Обновление статистик».

    3) Добавьте в него задачу Update Statistics Task из панели задач:

    4) Настройте расписание обновления статистик (рекомендация не реже 1 раза в день).

    5.1) Базу данных для который выполняется обновление статистики

    5.2) Список таблиц установите «All» — это означает что будет обновлена статистика по всем таблицам БД

    5.3) Укажите опцию Full scan

    (Примечание. Такой режим будет эквивалентен скрипту

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

    6) Добавьте задачу Execute T-SQL Statement Task.

    7) Соедините задачу Update Statistics Task стрелочкой с новой задачей

    8) В тексте созданной задачи Execute T-SQL Statement Task следует указать запрос «DBCC FREEPROCCACHE»

    9) если у вас значительная нагрузка на базу в пиковые моменты (сотни пользователей, роботы-фоновики и т.п.) то наряду с параметром «Автоматическое создание статистики (AUTO_CREATE_STATISTICS)» будет полезно также для базы данных включить параметр «Автоматическое асинхронное обновление статистики (AUTO_UPDATE_STATISTICS_ASYNC)»

    Важно знать:
    Если включен параметр AUTO_UPDATE_STATISTICS (автоматическое обновление статистики), оптимизатор запросов определяет, устарела ли статистика, и при необходимости обновляет ее, если она используется в запросе. Статистика становится устаревшей, после того как операции вставки, обновления, удаления или слияния изменяют распределение данных в таблице или индексированном представлении. Оптимизатор запросов определяет, устарела ли статистика, подсчитывая операции изменения данных с момента последнего обновления статистики и сравнивая число изменений с пороговым значением. Пороговое значение основано на количестве строк в таблице или индексированном представлении.

    Если используется версия до SQL Server 2014 (12.x), SQL Server применяет пороговое значение в зависимости от процента измененных строк. Это значение не зависит от числа строк в таблице. Пороговое значение:
    Если на момент оценки статистических данных кратность в таблице не превышала 500, обновление выполняется для каждых 500 модификаций.
    Если на момент оценки статистических данных кратность в таблице превышала 500, обновление выполняется для каждых 500 + 20 % модификаций

    Начиная с версии SQL Server 2016 (13.x) и при уровне совместимости базы данных 130 SQL Server используется пороговое значение для динамического обновления статистических данных по убыванию. Значение изменяется в зависимости от числа строк в таблице. Оно вычисляется как квадратный корень из произведения текущего значения кратности в таблице и 1000. Например, если таблица содержит 2 миллиона строк, значение вычисляется как квадратный корень из (1000 * 2000000) = 44721,359. Благодаря этому изменению статистика для больших таблиц будет обновляться чаще. Но если уровень совместимости для базы данных ниже 130, применяется пороговое значение SQL Server 2014 (12.x).

    Оптимизатор запросов проверяет наличие устаревшей статистики перед компиляцией запроса и до выполнения кэшированного плана запроса.
    Параметр AUTO_UPDATE_STATISTICS_ASYNC (асинхронное обновление статистики) определяет, какой режим обновления статистики использует оптимизатор запросов: синхронный или асинхронный. По умолчанию параметр асинхронного обновления статистики отключен, и оптимизатор запросов обновляет статистику синхронно.
    При синхронном обновлении статистики запросы всегда компилируются и выполняются с актуальной статистикой. Если статистика оказывается устаревшей, оптимизатор запросов ожидает появления обновленной статистики, прежде чем начать компиляцию и выполнение запроса. При асинхронном обновлении статистики запросы компилируются с существующей статистикой, даже если она устарела. Если на момент компиляции запроса статистика оказывается устаревшей, оптимизатор запросов может выбрать неоптимальный план запроса. Запросы, которые компилируются после выполнения асинхронного обновления, будут усовершенствованы благодаря использованию обновленной статистики.

    Читайте также:  eric ide установка windows

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

    Особенности 8.3.14

    Добавлен встроенный веб-сервер (только для одной базы, из командной строки управление).

    Реализован упрощенный OLAP . Теперь можно работать на чтение с копией таблицы с ведомой СУБД.
    Реализовано событие технологического журнала > .Механизм копий базы данных требует лицензию КОРП.

    При чтении помещеной копии таблицы в таблицу Inmemory используется новый механизм Дата акселератор. Добавлен в виде отдельной функции менеджера кластера.

    Добавлен альтернативный механизм управления сервером 1С программно и кроссплатформенно, реализован объект АдминистрированиеСервера . Дополнительно смотрите https://wonderland.v8.1c.ru/blog/razvitie-klastera-serverov/

    Улучшен механизм счетчиков потребления ресурсов — реализована возможность отбора по признаку использования безопасного режима работы и профиля безопасности (добавлены новые типы фильтров). Для выражений отбора счетчика потребления ресурсов реализована возможность сравнения на неравенство. Для выражений отбора счетчика потребления ресурсов реализована возможность объединять «по И» несколько условий на один тип фильтра.

    Реализован пакетный режим работы тонкого и толстого клиентских приложений. Пакетный режим распространяется от начала запуска клиентского приложения до окончания работы обработчика ПередНачаломРаботыСистемы модуля приложения. После окончания работы обработчика пакетный режим автоматически отключается. В пакетном режиме запуска подавляется вывод любых диалогов системы. Признаком пакетного режима работы клиентского приложения является команда командной строки запуска /DisableStartupDialogs .

    Уменьшено время полного пересчета итогов для регистров бухгалтерии и накопления в следующих случаях:

    • пересчет итогов во время операции Тестирование и исправление из конфигуратора;
    • использование метода ПересчитатьИтоги() при выполнении следующих условий:
      • монопольный доступ к информационной базе;
      • наличие административных прав у пользователя, от имени которого выполняется пересчет итогов;
      • метод исполняется в сеансе, в котором не используется ни одного разделителя.

    Ускорено выполнение реструктуризации информационной базы при использовании СУБД Microsoft SQL Server и IBM DB2.

    Уменьшилась вероятность одновременного закрытия множества соединений с Microsoft SQL Server, что положительно влияет на производительность работы с TempDB .

    Для регистра расчета реализован кластерный индекс по регистратору. Перестройка индекса будет выполнена при реструктуризации регистра расчета или при переиндексации во время выполнения операции тестирования и обновления.Если при удалении записей из таблицы фактического периода действия не установлен отбор по измерениям регистра, то для запроса удаления не формируется соединение с основной таблицей регистра. Снижена вероятность табличной блокировки при удалении записей фактического периода действия регистра расчета.

    Для динамического списка реализована возможность указания полей, которые будут использоваться в качестве ключевых полей выборки. Повышена производительность при использовании динамических списков с отсутствующей основной таблицей. Например, для динамического списка без основной таблицы, стало возможно использование группировки. Дополнительно смотрите https://wonderland.v8.1c.ru/blog/razvitie-dinamicheskikh-spiskov-s-proizvolnymi-zaprosami/

    В тонком, толстом и веб-клиентах, форма снимает блокировку объекта через 1 минуту после снятия признака модифицированности.(раньше снималась при закрытии формы)При работе под управлением СУБД PostgreSQL, в технологический журнал (событие

    ) помещаются планы запросов для запросов UPDATE , DELETE и INSERT . (Раньше был только SELECT)

    Реализовано отображение критических ошибок оптимизированного механизма обновления конфигурации базы данных в конфигураторе и в событии технологического журнала.

    В технологическом журнале реализованы свойства Dbms , Database , DBCopy для событий обращения к СУБД ( DB2 , DBMSSQL , DBPOSTGRS , DBORACLE ), событий EXCP и SDBL .

    Как получить последний id без использования функции max

    Заметка

    select id from table order by id desc limit 1

    select top 1 id from table order by id desc

    Получить 3ю строку

    Заметка

    Declare @N int
    set @N = 3;
    WITH CTE AS
    (
    SELECT Name, Salary, EmpID, RN = ROW_NUMBER()
    OVER (ORDER BY Salary DESC)
    FROM Employee
    )
    SELECT Name, Salary, EmpID
    FROM CTE
    WHERE RN = @N

    Как найти дубликат записи

    Заметка

    Дублирование записей с одним полем

    SELECT name, COUNT(email)
    FROM users
    GROUP BY email
    HAVING COUNT(email) > 1

    Дублирование записей с несколькими полями

    SELECT name, email, COUNT(*)
    FROM users
    GROUP BY name, email
    HAVING COUNT(*) > 1

    Лицензирование MS SQL Server

    Ошибка СУБД: Размер (39), выделенный тип «numeric», превышает максимально допустимое значение (38)

    Это зарегистрированная ошибка платформы 8.3.12.1412. Возникает когда есть ИТОГИ в запросе .

    1. пересчет итогов
    2. смещение даты актуальности итогов
    3. итоговое поле в запросе через Выразить(МоеПоле Как Число(15,2))

    Скрипт сжатие таблиц mssqlserver

    DECLARE @Table_catalog NVARCHAR(128)
    DECLARE @Table_schema NVARCHAR(128)
    DECLARE @Table_name NVARCHAR(128)
    DECLARE @Index_Name NVARCHAR(128)

    — включение сжатия для таблиц
    DECLARE TableNameCursor CURSOR
    FOR
    SELECT Table_catalog, Table_schema, Table_name FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = ‘BASE TABLE’
    ORDER BY Table_catalog, Table_schema, Table_name

    FETCH NEXT FROM TableNameCursor INTO @Table_catalog, @Table_schema, @Table_name
    WHILE @@fetch_status = 0
    BEGIN

    PRINT @Table_catalog + ‘.’ + @Table_schema + ‘.’ + @Table_name
    SET @cmd = ‘ALTER TABLE [‘ + @Table_catalog + ‘].[‘ + @Table_schema + ‘].[‘ + @Table_name + ‘] REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)’
    EXEC (@cmd)

    FETCH NEXT FROM TableNameCursor INTO @Table_catalog, @Table_schema, @Table_name
    END
    CLOSE TableNameCursor
    DEALLOCATE TableNameCursor

    — включение сжатия для индексов
    DECLARE IndexCursor CURSOR
    FOR
    SELECT DB_NAME(), schemas.name, tables.name, indexes.name
    FROM sys.schemas as schemas inner join sys.tables as tables inner join sys.indexes as indexes on tables.object_id = indexes.object_id on schemas.schema_id = tables.schema_id
    ORDER BY schemas.name, tables.name, indexes.name;

    FETCH NEXT FROM IndexCursor INTO @Table_catalog, @Table_schema, @Table_name, @Index_Name
    WHILE @@fetch_status = 0
    BEGIN

    PRINT @Table_catalog + ‘.’ + @Table_schema + ‘.’ + @Table_name + ‘: ‘ + @Index_Name

    SET @cmd = ‘ALTER INDEX [‘ + @Index_Name + ‘] ON [‘ + @Table_catalog + ‘].[‘ + @Table_schema + ‘].[‘ + @Table_name + ‘] REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)’
    EXEC (@cmd)

    FETCH NEXT FROM IndexCursor INTO @Table_catalog, @Table_schema, @Table_name, @Index_Name
    END
    CLOSE IndexCursor
    DEALLOCATE IndexCursor

    — делаем шринк базы — возвращаем свободное место на диск
    SELECT @cmd=(
    SELECT ‘DBCC SHRINKDATABASE(»’+ DB_NAME() + »’)’
    )
    EXEC (@cmd)

    Особенности 8.3.11

    Переработан механизм реструкторизации, актуально для баз с большими размерами

    Реализован новый механизм реструктуризации информационной базы. Основные отличия этого механизма:

    • При выполнении реструктуризации обрабатываются только те физические таблицы базы данных, в которых есть реальные изменения.
    • Максимальное количество изменений выполняется без создания копии таблицы и копирования информации между копиями.
    • Если копирование информации между версиями таблиц все-таки требуется, это копирование будет выполняться средствами СУБД во всех возможных случаях.

    Данная возможность включена в статусе бета-версии. Новый механизм реструктуризации используется только в клиент-серверном варианте, при работе с СУБД Microsoft SQL Server и PostgreSQL.

    Для работы нового механизма реструктуризации требуется наличие Java 1.8 на компьютере, где установлен сервер «1С:Предприятия».

    Для файла conf.cfg реализованы параметры J avaHome , JavaOpts , UpdateDBCfg .
    Смотрите дополнительно https://wonderland.v8.1c.ru/blog/optimizatsiya-restrukturizatsii-bazy-dannykh/

    Новый функционал «Система взаимодействия»

    Стало возможно информировать клиентское приложение о событиях на стороне сервера «1С:Предприятия», в том числе асинхронно.
    Реализована возможность развертывания собственного сервера системы взаимодействия. Сервер поставляется в виде отдельного дистрибутива и требует отдельной установки.

    Реализовано событие технологического журнала > .

    Событие предназначено для расследования событий, связанных с ошибками проверки действительности сертификатов средствами Windows API.Событие формируется только при работе под управлением ОС Windows.

    Стало возможно запускать более одного сеанса работы с веб-клиентом из одного веб-браузера.

    Повышена скорость работы поиска по началу строки в языке запросов при работе с СУБД PostgreSQL.

    При работе с СУБД PostgreSQL реализовано преобразование операции языка запросов ПОДОБНО `ТЕКСТ%` в более оптимальную операцию SQL-запроса.В режиме совместимости с версией 8.3.10 поведение не изменилось.

    Улучшена производительность и масштабируемость при использовании на стороне сервера «1С:Предприятия» объектов HTTPСоединение и FTPСоединение в том случае, если используется несколько соединений из различных сеансов.

    Ускорена работа с временными таблицами, при использовании СУБД Microsoft SQL Server

    • 2012, версия 11.0.5548.0 и старше.
    • 2014, версия 12.0.2430.0 и старше.
    • 2016.

    Повышена скорость работы сервера «1С:Предприятия» в том случае, когда одновременно проводятся документы, содержащие большое количество (десятки тысяч) строк.

    Оптимизирована работа с большими временными таблицами под управлением СУБД PostgreSQL.

    Оптимизированы операции удаления записей из временных таблиц при выполнении некоторых операций в СУБД PostgreSQL и IBM DB2.

    Уточнение отображения в линуксе

    При работе под управлением ОС Linux, параметр рабочего процесса Занято памяти , вычисляется на основании значения VmRSS (resident set size). Значение параметра Занято памяти стало меньше в абсолютном выражении и более точно соответствует реальности.Рекомендуется провести переоценку параметров перезапуска рабочих процессов в свойствах рабочего сервера.

    Добавлен платформенный вариант версионирования данных (для аудита) https://wonderland.v8.1c.ru/blog/istoriya-dannykh/

    Недопустимое преобразование типов данных в записи

    Ошибка СУБД:
    Microsoft SQL Native Client: Conversion failed when converting date and/or time from character string.
    HRESULT=80004005, SQLSrvr: SQLSTATE=22007, state=1, Severity=10, native=241, line=1

    ошибка может возникать например в момент обновления БД при изменении режима совместимости на «Не использовать»

    Вариант решения: Установить native client на все рабочие сервера 1С кластера 1С.

    Особенности 8.3.10

    Реализована поддержка СУБД PostgreSQL версии 9.6.

    Повышена масштабируемость кластера серверов в том случае, если:

    • на сервере установлены центральные процессоры с большим количество ядер;
    • обслуживается большое количество пользователей;
    • используется сжатие служебного обмена данными между клиентской и серверной частью системы.

    Снижено количество оперативной памяти, используемой сервером «1С:Предприятия», если в прикладном решении используются пакетные запросы.

    Упрощена диагностика использования циклических ссылок при работе встроенного языка.

    Реализована возможность дополнительно обработать данные, которые получил динамический список для отображения. Реализовано событие ПриПолученииДанныхНаСервере. Дополнительно смотрите https://wonderland.v8.1c.ru/blog/obrabotka-i-oformlenie-dannykh-dinamicheskogo-spiska/

    В технологическом журнале реализовано отражение событий, связанных с:

    • получением и освобождением лицензий (как программных, так и ключей HASP);
    • получением лицензий на базовые версии;
    • регулярным мониторингом соответствия реального оборудования и списка оборудования, зафиксированного в лицензии.

    Реализовано событие технологического журнала
    .

    Событие технологического журнала предоставляет возможность анализа только технологических аспектов работы с ключами HASP (вызовы интерфейса работы с HASP), не предоставляя возможности отслеживать получение и освобождение лицензий, получаемых с ключей HASP.

    Реализовано журналирование событий, возникающих при первом соединении сервера «1С:Предприятия» с СУБД Microsoft SQL Server, в технологическом журнале. Журналирование выполняется с помощью события .

    В документации данное изменение описано здесь и здесь.

    Изменен подход к хранению истории исполнения фоновых и регламентных заданий. В клиент-серверном варианте история хранится в разрезе информационных баз. Для каждой информационной базы хранится история:

    • до 1 000 фоновых заданий, созданных из встроенного языка;
    • до 1 000 регламентных заданий;
    • до 1 000 системных фоновых заданий (формируемых самой системой).

    Для каждого задания (фонового, системного фонового и регламентного) будет предприниматься попытка хранить информацию минимум о трех последних запусках. Это количество (три запуска) будет уменьшаться в том случае, если превышен лимит в 1 000 записей на тот или иной вид заданий.

    Реализовано в версии 8.3.10.2168 в новое событие SCRIPTCIRCREFS режим автоматического поиска циклических ссылок

    Недопустимое имя объекта «#tt

    Ошибка вроде как у платформу версии 8.3.9.1818 (Сервер 1С Предприятия x86-64) при работе базы начала вываливаться ошибка у пользователей:

    Невосстановимая ошибка
    Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
    по причине:
    Ошибка СУБД:
    Microsoft SQL Server Native Client 10.0: Недопустимое имя объекта «#tt1».
    HRESULT=80040E37, SQLSrvr: SQLSTATE=42S02, state=1, Severity=10, native=208, line=1

    Читайте также:  samsung nexus сброс на заводские настройки

    имеет регистрацию на сайте 1С
    Код ошибки: 50010160
    Код(ы) обращения: CSR-12050 CSR-12078
    Зарегистрирована: 19.10.2016

    Также проблема проявляется при интенсивном использовании поиска по строке в динамических списках

    1. Исправлена и проверена на практике в релизе 8.3.9.2170. Не возникает на 8.3.8.2167.

    2. Проверьте также наличие сервиспаков MS SQL Server.

    3. Выключите Shared Memory

    Флаг трассировки 2335

    Флаг трассировки 2335 заставит SQL Server 2005 и 2008 генерировать более консервативный с точки зрения потребления памяти план исполняя запроса, не ограничивая при этом объём используемой SQL Server памяти для кэша данных, запросов и т.п. Необходимость в этом флаге может возникнуть, если после увеличения значения «max server memory» наблюдается замедление исполнения запросов. Подробности в статье KB2413549.

    Флаги трассировки

    В SQL Server существуют два типа флагов трассировки: для сеанса и глобальные. Флаги трассировки сеанса действуют во время данного соединения и доступны только для этого соединения. Глобальные флаги трассировки устанавливаются на уровне сервера и доступны для каждого соединения с этим сервером. Некоторые флаги могут быть включены только как глобальные, а некоторые и как глобальные, и как для сеанса.

    Применяются следующие правила.

    • Глобальный флаг трассировки должен быть включен глобально. В противном случае, флаг трассировки не повлияет на работу сервера. Рекомендуется включать глобальные флаги трассировки при запуске с помощью параметра командной строки -T.
    • Если флаг трассировки может иметь или глобальную область, или область сеанса, он может быть включен с соответствующей областью. Флаг трассировки, включенный на уровне сеанса, никогда не влияет на другой сеанс, и действие флага трассировки прекращается, если SPID, открывший сеанс, выполняет выход.

    Флаги трассировки устанавливаются и снимаются с помощью любого из следующих методов:

    • Использование команд DBCC TRACEON и DBCC TRACEOFF.Например, DBCC TRACEON 2371: Чтобы включить флаг трассировки глобально, используйте DBCC TRACEON с аргументом -1: DBCC TRACEON (2371, -1). Чтобы отключить глобальный флаг трассировки, используйте команду DBCC TRACEOFF с аргументом -1.
    • Использование параметра запуска -T для задания установки флага трассировки при запуске.Параметр запуска -T включает флаг трассировки глобально. Невозможно включить флаг трассировки уровня сеанса с помощью параметра запуска. Дополнительные сведения о параметрах запуска см. в разделе

    Использование команды DBCC TRACESTATUS для определения активных в данный момент флагов трассировки.

    Перечень флагов вы сможете посмотреть на msdb.

    Флаг трассировки 1117

    Флаг трассировки 1117

    При наличии типа ожидания pagelatch рекомендуется вспомнить про логическую конкуренцию ресурсов файлов.

    select session_id, wait_duration_ms, resource_description from sys.dm_os_waiting_tasks where wait_type like ‘PAGE%LATCH_%’ and resource_description like ‘2:%’
    В рамках одной файловой группы может быть создано несколько файлов. Например, для базы tempdb рекомендуется создавать несколько файлов, что может в некоторых сценариях увеличить производительность системы.

    Идея такая:
    Если логических ядер 8 то добавить еще 4 файла и посмотреть по факту. Надо, еще добавить, но при этом важно не переборщить, можно вместо логических ожиданий наплодить очередей к диску например.

    Теперь предположим ситуацию: все файлы, входящие в файловую группу, имеют одинаковый размер. Создается большая временная таблица. Места в файле #1 не достаточно и разумеется происходит AutoGrow. Через время такая же таблица пересоздается, но вставка происходит в файл #2, потому что #1 временно заблокирован. Что в таком случае будет?AutoGrow для #2… и повторная задержка при выполнении запросов. Для таких случаев, был предусмотрен TF 1117. Работал он глобально и при нехватке места в одном файле вызывал AutoGrow для всех файлов в рамках одной файловой группы.

    В MS SQL Server 2016 данный трейс-флаг включен по умолчанию для tempdb и может избирательно настраиваться для пользовательских баз:
    ALTER DATABASE test
    MODIFY FILEGROUP [PRIMARY] AUTOGROW_ALL_FILES
    GO
    ALTER DATABASE test
    MODIFY FILEGROUP [PRIMARY] AUTOGROW_SINGLE_FILE
    GO

    Посмотрим на размер файлов:
    USE tempdb
    GO

    SELECT
    name
    , physical_name
    , current_size_mb = ROUND(size * 8. / 1024, 0)
    , auto_grow =
    CASE WHEN is_percent_growth = 1
    THEN CAST(growth AS VARCHAR(10)) + ‘%’
    ELSE CAST(CAST(ROUND(growth * 8. / 1024, 0) AS INT) AS VARCHAR(10)) + ‘MB’
    END
    FROM sys.database_files
    WHERE [type] = 0

    name physical_name size_mb auto_grow
    ———- ————————————————— ——— ————
    tempdev D:\DATABASES\SQL_2016RC0\TEMP\tempdb.mdf 8.000000 64MB
    temp2 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_2.ndf 8.000000 64MB
    temp3 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_3.ndf 8.000000 64MB
    temp4 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_4.ndf 8.000000 64MB

    Создаем временную таблицу:
    IF OBJECT_ID(‘#t’) IS NOT NULL
    DROP TABLE #t
    GO

    CREATE TABLE #t (
    ID INT DEFAULT 1,
    Value CHAR(8000) DEFAULT ‘X’
    )
    GO

    INSERT INTO #t
    SELECT TOP(10000) 1, ‘X’
    FROM [master].dbo.spt_values c1
    CROSS APPLY [master].dbo.spt_values c2

    Места чтобы вставить данные не хватит и произойдет AutoGrow.

    AUTOGROW_SINGLE_FILE:
    name physical_name size_mb auto_grow
    ———- ————————————————— ———— ————
    tempdev D:\DATABASES\SQL_2016RC0\TEMP\tempdb.mdf 72.000000 64MB
    temp2 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_2.ndf 8.000000 64MB
    temp3 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_3.ndf 8.000000 64MB
    temp4 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_4.ndf 8.000000 64MB

    AUTOGROW_ALL_FILES:
    name physical_name size_mb auto_grow
    ———- ————————————————— ———— ————
    tempdev D:\DATABASES\SQL_2016RC0\TEMP\tempdb.mdf 72.000000 64MB
    temp2 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_2.ndf 72.000000 64MB
    temp3 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_3.ndf 72.000000 64MB
    temp4 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_4.ndf 72.000000 64MB

    Флаг трассировки 8048

    В случае, если в вашей системе более 8 логических процессоров и наблюдается большое число ожиданий CMEMTHREAD и кратковременных блокировок:
    SELECT waiting_tasks_count
    FROM sys.dm_os_wait_stats
    WHERE wait_type = ‘CMEMTHREAD’
    AND waiting_tasks_count > 0

    SELECT spins
    FROM sys.dm_os_spinlock_stats
    WHERE name = ‘SOS_SUSPEND_QUEUE’
    AND spins > 0

    то использование TF 8048 помогает избавиться от проблем с производительностью.

    В SQL Server 2016 данный трейс флаг включен по умолчанию.

    флаг трассировки -T1118

    -T1118

    SQL Server вычитывает данные с диска кусками по 64Кб (так называемыми экстентами). Экстент – это группа из восьми физически последовательных страниц (по 8Кб каждая) файлов базы данных.

    Имеются два типа экстентов: смешанные и однородные. На смешанном экстенте могут храниться страницы с разных объектов. Такое поведение позволяет очень маленьким таблицам занимать минимальное количество места. Но чаще всего таблицы не ограничиваются размером в 64Кб и когда требуется более 8 страниц для хранения данных по одному объекту, то происходит переключение на выделение однородных экстентов.

    Чтобы изначально выделять для объекта однородные экстенты предусмотрен флаг трассировки 1118, который рекомендуется включать:

    В 2016 версии такого уже не будет. Но для каждой пользовательской базы можно задать опцию MIXED_PAGE_ALLOCATION

    Возможности 8.3.4

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

    Реализована возможность использования общих реквизитов, не являющихся разделителями, в свойстве объекта конфигурации ПоляБлокировкиДанных.

    Общие реквизиты, которые являются разделителями в режиме Независимо и совместно, не могут быть выбраны в список реквизитов ПоляБлокировкиДанных. Реализована возможность указывать такие реквизиты в качестве имени пространства блокировок объекта БлокировкаДанных. Система вызовет исключение в том случае, если в объекте БлокировкаДанныхиспользуется значение разделителя, отличное от значения, используемого в сеансе.

    Изменения реализованы для следующих объектов:

    • Справочники;
    • Документы;
    • Планы видов характеристик;
    • Планы счетов;
    • Планы видов расчета;
    • Планы обмена;
    • Бизнес-процессы;
    • Задачи;
    • Константы.

    Исключена возможность устанавливать управляемые транзакционные блокировки (свойство ПоляБлокировкиДанных) по реквизитам объектов следующих типов: строка неограниченной длины, хранилище значений, тип значения характеристики, составные типы, включающие в себя какие-либо из вышеперечисленных типов.

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

    Для сервера «1С:Предприятия» реализованы лицензии с ограниченным количеством одновременно обслуживаемых сеансов клиентских приложений — МИНИ-СЕРВЕР на 5 подключений.

    Особенности 8.3.1

    При работе с Microsoft SQL Server версии 2005 и выше, используется режим управления версиями строк, если конфигурация использует режим управляемых блокировок. Используется уровень изоляции транзакций READ_COMMITED_SNAPSHOT. При чтении данных вне транзакций используется согласованное чтение.

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

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

    Ускорена работа при использовании СУБД PostgreSQL за счет изменения структуры индексов. Оптимизация действует для новых информационных баз и для существующих после выполнения реструктуризации базы данных.Стало возможно использовать отдельные табличные пространства для индексов (пространство v81c_index) и данных (пространство v81c_data) в СУБД PostrgeSQL.

    Табличные пространства не создаются автоматически и должны быть созданы администратором базы данных. Если дополнительных табличных пространств не создано — используется табличное пространство по умолчанию (pg_default).

    Расширен состав свойств для события технологического журнала в том случае, если событие генерируется для процесса rphost (свойство process равноrphost), а также в том случае, если процесс rphost выполняет обращение к виртуальным ресурсам системы.

    Добавлены свойства, отображающие:

    • Report — имя объекта метаданных выполняемого отчета;
    • Method — имя вызванного метода;
    • SessionID — номер сеанса;
    • Memory — объем памяти в байтах, занятой, но не освобожденной за вызов;
    • MemoryPeak — объем памяти в байтах, занятой, но не освобожденной за вызов. Пиковое значение;
    • InBytes — количество прочитанных за вызов данных с диска, в байтах;
    • OutBytes — количество записанных за вызов данных с диска, в байтах;
    • Context — контекст события.

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

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

    Особенности 8.3.8

    Файловая версия 8.3.8 работает существенно быстрее чем версии 8.3.6, 8.3.7

    Реализована поддержка веб-сервера Apache 2.4 для ОС Windows и Linux.

    Для динамического списка реализована поддержка работы с пакетным запросом.

    Оптимизирована работа с сеансовыми данными. Уменьшено место на диске, которое занимают сеансовые данные. Сеансовые данные хранятся в кластере серверов в сжатом виде. Сжатие/расжатие сеансовых данных происходит на стороне рабочего процесса.

    В языке запросов реализовано упрощение некоторых выражений вида ИЛИ ИСТИНА.

    Оптимизированы операции удаления записей из временных таблиц при выполнении некоторых операций в СУБД PostgreSQL и IBM DB2.

    Реализована возможность управлять сбором информации о блокировках СУБД в технологическом журнале (элемент ).Реализован сервис кластера серверов, выполняющий сбор информации о блокировках СУБД. Сервис называетсяAuxiliaryService (Сервис вспомогательныхфункций кластера).

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

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

    В режиме совместимости с версией 8.3.7 поведение не изменилось.

    Реализовано событие технологического журнала .

    При работе с СУБД Microsoft SQL Server изменены типы полей таблиц, используемые для хранения некоторых типов реквизитов конфигурации (дата и время, строковые данные неограниченной длины и двоичные данные неограниченной длины). Новые типы полей используются при отключенном режиме совместимости и после выполнения реструктуризации соответствующего объекта конфигурации.

    Для выполнения реструктуризации таблиц базы данных с изменением типов полей необходимо установить нужный режим режим совместимости и выполнить операцию реструктуризации информационной базы в конфигураторе (Главное меню — Администрирование — Тестирование и исправление).

    В режиме совместимости с версией 8.3.7 поведение не изменилось.

    При работе со всеми СУБД изменена структура индексов по полям составного типа. В результате уменьшено количество индексов. Такое построение индексов осуществляется при отключенном режиме совместимости и после выполнения реструктуризации соответствующего объекта конфигурации.
    Для выполнения реструктуризации таблиц базы данных с изменением индексов необходимо установить нужный режим режим совместимости и выполнить операцию реструктуризации информационной базы в конфигураторе (Главное меню — Администрирование — Тестирование и исправление).
    В режиме совместимости с версией 8.3.7 поведение не изменилось.

    Читайте также:  настройка материнской платы asrock h81 pro btc

    Ошибка 10161406 исправлена в 8.3.8.1747

    В процессе работы кластера серверов Предприятия при достижении ограничения на количество соединений или количество информационных баз на рабочий процесс возможен запуск нескольких рабочих процессов. Через некоторое время излишние рабочие процессы завершаются.

    Особенности 8.3.5

    Реализована официальная возможность работы с СУБД Microsoft SQL Server 2014.

    Реализована официальная поддержка работы «1С:Предприятия» под управлением ОС Microsoft Windows Server 2012 R2 (x86-64)

    Реализован новый «спорный» формат хранения журнала регистрации .Файл ЖР в новом формате (sqlite) после сокращения средствами платформы не уменьшается и все так же занимает много места на диске.
    Рекомендуют останавливать сервер 1С периодически и использовать утилиту и команду
    sqlite3 1Cv8.lgd «VACUUM;»
    Добавлен новый способ управления спящими сеансами

    Обновления для MS SQL Server 2012

    Обнаружение повышения области блокировки таблицы

    Определяем ID объекта — исследуемой таблицы в базе данных

    USE [trade_debug] Select * from Sys.objects WHERE Sys.objects.name = ‘_Reference82’

    где _Reference82 имя таблицы

    Далее настраиваем трассировку SQL server profiler:

    Отключение эскалации чревато дополнительной нагрузкой на сервер, это надо учитывать:

    USE [trade_debug] ALTER TABLE _Reference82 SET (LOCK_ESCALATION = DISABLE)

    Проверить режим эскалации блокировок можно с помощью скрипта:

    USE [trade_debug] SELECT lock_escalation, lock_escalation_desc, name FROM sys.tables WHERE lock_escalation_desc=’DISABLE’

    После отключения эскалации запускаем ранее настроенную трассировку в профайлере чтобы убедиться в ожидаемом результате.

    Настройка и изменение параметров сортировки сервера

    Параметры сортировки сервера применяются по умолчанию для всех установленных системных баз данных с экземпляром SQL Server, а также для новых пользовательских баз данных. Параметры сортировки сервера задаются во время установки SQL Server.

    • Проверьте наличие данных и сценариев, необходимых для повторного создания пользовательской базы данных и всех ее объектов.
    • Экспортируйте все данные с помощью такого средства, как Программа bcp. Дополнительные сведения см. в разделе Массовый импорт и экспорт данных.
    • Удалите все пользовательские базы данных.
    • Перестройте базу данных master, при этом в свойстве SQLCOLLATION команды setup задайте новые параметры сортировки. Например:

    Дополнительные сведения см. в Перестроение системных баз данных.

  • Создайте все базы данных и все их объекты.
  • Импортируйте все данные.
  • ЕСТЬ ВАРИАНТ недокументированного решения:

    Остановите сервис и запустите команду (из папки с екзешником).

    sqlservr -m -T4022 -T3659 -q»Cyrillic_General_CI_AS»

    MSSQL: как просмотреть информацию о бэкапах, хранящихся в файле .bak и .trn

    Получим информацию о хранящихся в файле .bak бэкапах с идентификаторами position, датами их создания BackupFinishDate начальным и конечным номерами LSN и всей прочей информацией.

    Если не уменьшается раз файла лога базы данных MS SQL Server

    DECLARE @subscriptionDB AS sysname
    SET @subscriptionDB = N’ИмяВашейБазы’

    USE master
    EXEC sp_removedbreplication @subscriptionDB
    GO

    Если вдруг это не поможет, то выполните диагностику с помощью

    найдите «открытую» транзакцию и удалите ее

    если она «системная», то проверьте наличие включенных механизмов типа «лог-шиппинг» и т.п.

    Could not continue scan with NOLOCK due to data movement

    Что говорит производитель MS SQL Server:

    http://msdn.microsoft.com/ru-ru/library/bb326281.aspx
    SQL Server Database Engine не удается продолжить выполнение запроса, поскольку приложение пытается считать данные, обновленные или удаленные другой транзакцией. Очередь использует подсказку блокировки NOLOCK или
    уровень изоляции транзакции READ UNCOMMITTED.
    Как правило, доступ к данным, которые изменяются другой операцией, запрещен из-за наложенной на них блокировки.
    Однако подсказка блокировки NOLOCK и уровень изоляции транзакции READ UNCOMMITTED позволили запросу считать данные, заблокированные другой транзакцией. Это называется «грязным» чтением, поскольку таким образом можно считать значения, которые еще не были зафиксированы и могут быть изменены.
    Эта ошибка отменяет запрос. Отправьте запрос повторно или удалите подсказку блокировки NOLOCK.

    Есть небольшая вероятность того, что дело в конфигурации.

    Но здесь есть ключевое НО: Обратите внимание, что речь идет о конфликте блокировок и запрос на чтение вне тразнакции.

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

    В ОСТАЛЬНЫХ СЛУЧАЯХ, применительно к 1С:Предприятие скорее дело не в этом.

    Проблемы с диском. Ошибка появляется при разрушении данных.

    Проверьте БД с помощью DBCC CHECKDB. Обязательно сделайте резервную копию!

    Попытайтесь с помощью все той же DBCC CHECKDB восстановить данные (если жесткий диск «не умирает»).

    ALTER DATABASE [Ваша база] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
    GO

    DBCC CHECKDB ([Ваша база],REPAIR_ALLOW_DATA_LOSS)
    GO

    ALTER DATABASE [Ваша база]SET MULTI_USER WITH ROLLBACK IMMEDIATE
    GO

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

    Или это ошибка платформы

    10036291 Ошибка СУБД: Microsoft OLE DB Provider for SQL Server: Could not continue scan with NOLOCK due to data movement.

    Проблема:
    В клиент-серверном варианте информационной базы с использованием MS SQL Server при возникновении ошибки

    происходит аварийное завершение работы программы.
    Дата публикации: 2009-11-16

    На момент написания статьи такой ошибки не было зарегистрировано, но это не 100% гарантия.

    Есть смысл при возникновении проблемы обратиться на v8@1c.ru

    Улучшения по производительности при отключении режима совместимости 8.2.13

    Почему мы рекомендуем отключать режим совместимости с 8.2.13

    • Оптимизировано выполнение запроса вида «ТипЗначения(Поле1) = ТипЗначения(Поле2)», если «Поле1» и «Поле2» содержат значения ссылочного типа.
    • Оптимизированы выборки, выполняемые порциями (используемые в методах «Выбрать()», а также при реструктуризации), для всех СУБД.
    • Оптимизирован ряд механизмов сервера 1С:Предприятия для повышения масштабируемости и производительности при большом количестве работающих пользователей.
    • Оптимизирована работа с файлами на диске (включая временные файлы) для следующих механизмов: полнотекстовый поиск, справка, объект «ИнтернетПочта».
    • Оптимизирована работа кластера серверов с данными сеанса.
    • Ускорена работа функций «ПолучитьСоединенияИнформационнойБазы()» и «ПолучитьСеансыИнформационнойБазы()» при большом количестве зарегистрированных пользователей.
    • Повышена производительность и масштабируемость модуля расширения веб-сервера.
    • В веб-клиенте оптимизировано обновление табличного документа после выполнения интерактивного редактирования, а также после программного изменения отдельных ячеек табличного документа.
    • Уменьшено количество серверных вызовов в части функциональности в веб-клиенте.
    • Ускорена работа механизма управляемых блокировок.
    • При отключенном режиме совместимости изменен режим хранения констант и настроек регистров накопления. Для каждого объекта используется своя таблица базы данных. Это означает улучшенную параллельность работы пользователей. При включении режима совместимости (в значение «Версия 8.2.13» или «Версия 8.1») выполняется обратная конвертация для обеспечения возможности запуска прикладного решения с помощью версии 8.2.13. Требуется реструктуризация!
    • Для полей управляемой формы, отображающих реквизит составного типа, ускорено открытие списка быстрого выбора в тех случаях, когда в составной тип входят ссылочные типы с разными настройками быстрого выбора.
    • Уменьшено влияние режима отладки на скорость работы в режиме «1С:Предприятие» для тонкого клиента, толстого клиента, сервера и внешнего соединения.
    • Увеличена производительность работы системы в случае использования двух и более разделителей или одного разделителя с типом «Строка».
    • Оптимизирован запуск клиентского приложения.
    • Оптимизировано открытие формы веб-клиента при использовании большого количества элементов в условном оформлении формы.
    • Оптимизировано открытие формы отчета в веб-клиенте, который содержит большое количество элементов условного оформления.
    • Для блокировочных СУБД (Microsoft SQL Server, IBM DB2) изменение пользователя информационной базы в транзакции более не конфликтует с процессом аутентификации, кроме случая, когда аутентификацию пытается выполнить пользователь, данные которого изменены, и транзакция, в рамках которой были выполнены изменения, не завершена.
    • Для нового независимого и непериодического регистра сведений, индекс по измерениям является кластерным. При создании первого регламентного задания, индекс по идентификатору задания также является кластерным. Требуется реструктуризация! Для создания необходимых индексов в существующей информационной базе можно выполнить одно из следующих действий:
      • Выполнить реструктуризацию базы данных.
      • Выполнить загрузку информационной базы из файла «.dt».
    • Реализована поддержка СУБД Microsoft SQL Server 2012.
    • Для работы с Microsoft SQL Server 2008 R2 возможно использование Native Client. При использовании Native Client возможно использование протокола SHARED MEMORY, если оба сервера находятся на одном компьютере. Использование протокола SHARED MEMORY (при использовании Native Client) возможно, начиная с версии Microsoft SQL Server 2005. Можно получить значительное ускорении при использовании SHARED MEMORY.
    • Реализована поддержка Native Client для СУБД Microsoft SQL Server 2005 и Microsoft SQL Server 2012.
    • Оптимизирован сервис нумерации кластера серверов «1С:Предприятия», в результате чего исключено снижение производительности сервера при длительной работе.
    • Оптимизирована работа тонкого и толстого клиентов, работающих с файловой информационной базой, расположенной на сетевом ресурсе, при многопользовательском доступе. Ускорены различные операции с информационной базой, включая открытие и редактирование форм объектов, просмотр форм списков, запись объектов, проведение документов и т.д.
    • Повышена масштабируемость сервера «1С:Предприятия» при работе с высокой нагрузкой и большим количеством одновременно работающих пользователей.
    • Ускорена работа функций СтрЧислоСтрок() и СтрПолучитьСтроку() при работе в тонком клиенте, толстом клиенте и на стороне сервера.
    • Оптимизировано получение писем с помощью объекта ИнтернетПочта.
    • Ускорена работа функции ЗначениеЗаполнено() в том случае, если параметром функции выступает выражение, состоящее из получения свойства какой-либо переменной (как «через точку» так и с помощью операторного способа ([])) любого уровня вложенности.
    • В таблицу журнала документов добавлен индекс по полю Ссылка. В результате повышается скорость работы динамического списка журнала документов, а также поиск по ссылке в журнале документов.
    • Оптимизирована генерация запросов для СУБД Microsoft SQL Server:
      • Сокращено количество повторяющихся планов запросов;
      • Сокращено количество компиляций запросов в Microsoft SQL Server;
      • Уменьшен размер кеша планов запросов Microsoft SQL Server;
      • Уменьшено время работы некоторых запросов;
      • Улучшились создаваемые планы запросов в некоторых случаях.
    • Оптимизирована работа динамического списка и динамической выборки из базы данных в случае наличия упорядочивания выборки по убыванию.Для Microsoft SQL Server эти операции оптимизированы дополнительно, а также оптимизирована операция реструктуризации.
    • При работе в клиент-серверном варианте в режиме управляемых блокировок, изменен механизм генерации новых ссылок для объектов информационной базы. Ссылки генерируются строго последовательно для всех соединений сервера «1С:Предприятие» с сервером СУБД. В результате сокращена фрагментация таблиц и индексов в базе данных, а также повышена скорость вставки и чтения записей таблиц базы данных.
    • Оптимизирован механизм балансировки нагрузки в кластере серверов.
    • Оптимизировано получение из базы данных прикладных объектов без табличных частей при вызове метода ПолучитьОбъект() и при обращении к свойствам «через точку» от ссылки.
    • Оптимизирована работа сервера «1С:Предприятия» при выполнении запросов к объектам, на которые наложены ограничения доступа к данным.
    • При работе с СУБД Microsoft SQL Server оптимизированы операции, использующие конструкцию IN (…) с одним значением в списке.
    • Оптимизирован запуск клиентских приложений, фоновых и регламентных заданий.
    • Ускорена работа системы при частом выполнении фоновых заданий и вызовов web-сервисов.
    • Ускорено открытие управляемых форм.Оптимизация наиболее заметна в случае многопользовательского доступа (с помощью тонкого клиента) в файловом варианте информационной базы, расположенной на сетевом ресурсе.
    • Ускорена работа некоторых видов запросов в файловом варианте информационной базы, например:
      • Запросы вида ВЫБРАТЬ ПЕРВЫЕ 1 …;
      • Сравнение двух списков с помощью оператора языка запросов В: … (Объект, СчетФактура) В (&СписокОбъектовИПартий) ….
    • Оптимизирована работа клиентских приложений с файловым вариантом информационной базы, расположенной на сетевом ресурсе.Рекомендуется выполнять операцию сжатия таблиц информационной базы после выполнения массовых операций изменения данных.
    • В веб-клиенте ускорены операции открытия и прокрутки табличного документа, содержащего большое количество колонок.
    • Оптимизирован запуск системы при большом количестве запусков, выполняемых с небольшими интервалами между запусками.
    • Проведена оптимизация внутренних механизмов платформы, улучшающая производительность и масштабируемость кластера серверов «1С:Предприятия».
    • Для независимых регистров сведений без измерений реализовано создание отдельных индексов по разделителям. Требуется реструктуризация!
    • Для разделителей с режимом разделения Независимый и совместный реализован дополнительный индекс в объектных таблицах, включающий значение разделителя, а также первичный ключ таблицы. Индекс позволит избежать эскалаций блокировок в СУБД при некоторых сценариях работы с таблицей.
    • При работе в веб-клиенте оптимизированы следующие операции с табличным документом: открытие, построчная прокрутка, постраничная прокрутка.

    источник

    Добавить комментарий

    Adblock
    detector