Установка и настройка MS SQL 2008 R2. Конвертация базы данных ТЦУ3 (Видео). Настройка sql
Настройка SQL Server для производительной работы 1С::Журнал СА 04.2016
Рубрика: Базы данных / Изучаем «1С» | Мой мир Вконтакте Одноклассники Google+ |
ТИМУР ШАМИЛАДЗЕ, руководитель, ООО «БухКонсалтинг», [email protected]
Настройка SQL Serverдля производительной работы 1С
MS SQL Server – самая распространенная СУБД для клиент-серверного использования 1С. Какие настройки необходимо произвести в ней для обеспечения максимально производительной работы 1С?
Самый лучший вариант – если сервер СУБД расположен на отдельном компьютере, на котором другие серверные роли не установлены (контроллер домена, терминальный сервер и пр.). Но ничто не мешает установить сервер 1С и СУБД наодин компьютер, если нагрузка на систему будет небольшой.
При выборе версии MS SQL Server стоит использовать последние, т.к. в новых версиях исправляют ошибки и оптимизируют механизмы, что приводит к улучшению производительности. Рассмотрим основные настройки.
Использование памяти
Следует ограничивать максимальный объем оперативной памяти, используемой MS SQL Server, если на сервере, помимо СУБД, работают другие ресурсоемкие приложения, например сервер 1С. Если этого не сделать, то SQL Server может занять столько памяти, что это помешает другим приложениям полноценно работать. Для того чтобы вычислить, какой объем памяти необходим, нужно определить, сколько оставить ОС и серверу 1С.
Обычно для нормальной работы операционной системе достаточно 4 Гб. Для систем с большим объемом памяти рекомендуется для ОС оставлять еще 1 Гб памяти на каждые 16 Гб, установленной RAM.
Чтобы вычислить, какой объем памяти оставить для сервера 1С, необходимо посмотреть, сколько памяти занимают процессы кластера серверов 1С в пиковые нагрузки, и добавить к этому числу некоторый резерв. К процессам кластера серверов 1С относят rphost, ragent, rmngr.
Получаем следующую формулу:
Память для SQL Server = Всего память – Память для ОС – Память для сервера 1С
Максимальный объем памяти, выделяемый SQL Server, устанавливается параметром Max server memory (Максимальный размер памяти сервера). Для этого необходимо в Management Studio через контекстное меню открыть свойства сервера и на странице «Память» указать параметр «Максимальный размер памяти сервера» (см. рис. 1).
Рисунок 1. Настройка Max server memory
Статью целиком читайте в журнале «Системный администратор», №04 за 2016 г. на страницах 58-61.
PDF-версию данного номера можно приобрести в нашем магазине.
Мой мир
Вконтакте
Одноклассники
Google+
samag.ru
Настройка Microsoft SQL Server для 1С
Шаг 0. Перед установкой и настройкой MS SQL 2005 желательно иметь 3 физических диска. Один - для системы, второй - для файлов баз и третий - для журналов транзакций SQL. При этом, раздел для логов SQL и tempdb желательно чтобы был более производительным (например RAID 1+0).
Шаг 1. Установка сервера MS SQL
При установке SQL-сервера для работы с 1С достаточно следующих включенных компонентов (более подробно о компонентах Microsoft SQL тут, об установке серера тут):Остальные настройки при установке по Вашему вкусу. Единственный нюанс - необходимо правильно установить способ сортировки collate. Для автоматической и правильной работы необходимо в "Языке и региональных стандартах" операционной системы выбрать "Русский". В этом случае при установке SQL Server сам предложит правильную сортировкуCyrillic_General_CI_AS. Выбор режима проверки подлинности пользователей укажите смешанный (mixed). Остальные параметры всегда можно скорректировать после установки - 1С:Предприятие будет работать независимо от них.
Более подробно об установке (ахтунг - English).Желательно обновить сервер MS SQL до актуального релиза (на текущий момент - SP4 для 2005 SQL). Кроме того, на многопроцессорных системах сервер Microsoft SQL 2005 может отказаться устанавливаться с ошибкой 1053 (The error is (1053) The service did not respond to the start or control request in a timely fashion). Решение этой проблемы описано тут.
Шаг 2. Настройка сервера Microsoft SQL 2005
2.1. Настройка протоколов подключения
Для настройки протоколов взаимодействия сервера и клиента Microsoft SQL необходимо запустить "SQL Server Configuration Manager":
...и оставить для работы только протоколы TCP/IP и Shared Memory:
Если устанавливается версия MS SQL Express по-умолчанию выключен протокол TCP/IP, нужный для работы с 1С:Предприятие 8 - его необходимо включить. Протокол именнованных каналов (Named Pipe) выключите совсем (и для "клиента" тоже на сервере приложений).
2.2. Перенос tempdb на быстрый независимый массив/диски
Для переноса tempdb необходимо запустить sql-скрипт примерно следующего содержания:
USE master GO ALTER DATABASE tempdb modify file (NAME=tempdev, FILENAME='E:\Temp\tempdb_data.mdf') GO ALTER DATABASE tempdb modify file (NAME=templog, FILENAME='E:\Temp\tempdb_log.ldf') GO2.3. Настройка параметров сервера SQL
Для настройки сервера запускаем "SQL Server Management Studio", подключаемся к установленному серверу Database Engine'ом и открываем свойства (Server Properties). Тут нам нужно настроить 3 пункта:
Память (Memory)
Параметр "Maximum server memory (in MB)" задает максимально отведенное серверу количество памяти из расчета: [Общее количество оперативной памяти сервера] – [3ГБ под систему(1,5ГБ если Win2k3)] – [сколько_нужно ГБ * количество процессов работающих на данном сервере (если SQL еще какой-то важный сервис крутится на этом же сервере)]. Например, если у нас на сервере всего 24 ГБ оперативной памяти, стоит Windows 2003 и запущен сервер 1С Предприятия с 2мя процессами rphost (которым нужна память хотябы по 1,5Гб) то рассчет будет следующим: 24 - 1,5 - 1,5*2 = 19,5 ГБ ставит параметр "Maximum server memory (in MB)". Это необходимо для того, чтобы sql-сервер рассчитывал на заданный объем и освобождал память заблаговременно, т.к. если поставить неограниченный объем, и сервер попробует получить память, которой нет, он начинает лезть в файл подкачки, что сильно замедлит работу.Database Settings
В данном пункте можно настроить каталоги для файлов Данных и логов, чтобы новые базы данных создавались именно там.2.4. Дополнительные "приседания"
Шаг 3. Настройка рабочих баз данных Ms SQL
Если база еще не развернута из .dt файла, и вы знаете примерный ее размер, то первичному файлу размер инициализации лучше сразу указать больший или равный размеру базы, но это дело вкуса, он все равно вырастет при развертке до нужных размеров. А вот Автоувеличение (Autogrowth) размера надо обязательно указать примерно по 200 МБ на базу и по 50 МБ на лог (можно увеличить/уменьшить, в зависимости от размера конечной базы и наличия места на диске), т.к. значения по умолчанию – рост по 1МБ и по 10% очень сильно тормозят работу сервера, когда ему при каждой 3й транзакции надо файл увеличивать. В этом же параметре можно ограничить размер файла лога, чтоб сильно не разростался, хотя это очень спорный параметр...Шаг 4. Настройка Планов обслуживания (Maintenance Plans, Регламентных заданий)
Для работы регламентных заданий необходимо создать план обслуживания:Итак, приведу свой пример настроенного Maintenance Plans с комментариями. Мой план состоит из 5 подпланов:
Первый подплан (ежедневное еженочное обслуживание сервера и резервных копий):
Данный подплан состоит из нескольких шагов. Связи зеленого цвета задают переход к следующему заданию при удачном завершении (т.е. без ошибок), связи синего цвета задают переход к следующему заданию при любом результате выполнения текущего. Параметры шагов видны на размещенных в редакторе заданиях. Параметры некоторых заданий нужно описать отдельно. Первым шагом выполняется "Проверка целостности базы данных" (Check Database Integrity Task), которая выполняется для всех баз системы и следующие задания выполняются только при отсутствии ошибок при проверке баз. Следующим шагом выполняется "Перестроение индексов баз данных" (Rebuild Index Task) для всех баз данных сервера. Данная процедура довольно ресурсоемкая, но в последствии ускоряет работу базы, т.к. если фрагментированость индексов > 25%, это резко снижает производительность сервера. Если размер баз не позволяет выполнять данную задачу, т.к. она занимает много времени, то рекомендуется делать данное действие хотябы раз в неделю, при этом, на ночные задания заменить задачу Перестроение индексов баз данных (Rebuild Index Task) на Дефрагментацию индекса (Reorganize Index Task), которая менее ресурсоемка. Далее происходит "Обновление статистики базы данных" (Update Statistics Task) для всех баз данных, опять же для оптимизации. После этого задания рекомендуется выполнить "Очистку процедурного кэша":
После оптимизации работы желательно сделать резервную копию журналов транзакций. Этот шаг делать не обязательно, но желательно. Во время выполнения предыдущих шагов (Перестроение индексов баз данных (Rebuild Index Task) и Обновление статистики базы данных (Update Statistics Task)) файлы журналов вырастают примерно до размера базы данных, а то и более. В результате, в следующих подпланах при выполнении первого резервного копирования журнала транзакций, размер копии имеет довольно большой объем. Это может сильно увеличить вермя восстановления базы. Таким образом, делая копию логов до полной копии, мы избавляемся от данной проблемы. (спасибо за идею комментатору Kyoshiro)
Далее можно выполнить полный бэкап заданием Создание резервной копии базы данных (Back Up Database Task):
При выполнении данного задания копии складываются в сетевую папку на файловом сервере с расширением bak, при этом, для каждой базы создается своя папка: SAMBA ~ # ls -1 /backup/full/ database1 database2 ... SAMBA ~ # ls -1 /backup/full/satabase1/ database1_backup_201111210250.bak database1_backup_201111220251.bak ...Второй, третий, четвертый подплан (обновление статистики 3 раза в день):
Следующие 3 подплана одинаковы по содержимому и различаются лишь временем выполнения. Выполняются 3 раза в день - в 6, 13 и 19 часов:
Обновление статистики довольно ресурсоемкая задача, поэтому спланируйте ее выполнение в то время, когда база данных не сильно загружена.
Пятый подплан (резервное копирование журнала транзакций):
Данный план выполняет инкрементальное копирование транзакционного лога Microsoft SQL Server:
После настройки данного плана мы имеем регулярное резервное копирование с необходимым регламентным обслуживанием, с хранением копий базы данных за последние 7 дней с возможностью восстановления базы интервалом до 30 минут.
notanet.blogspot.com
Настройка сервера SQL Server для ведения журнала
Эта документация перемещена в архив и не поддерживается.
Опубликовано: Ноябрь 2009 г.
Обновлено: Февраль 2010 г.
Назначение: Forefront Threat Management Gateway (TMG)
В данном разделе описывается, как использовать удаленную базу данных SQL Server для ведения журнала Forefront TMG.
Настройка SQL-сервера для ведения журнала включает следующие процедуры:
Создание базы данных и таблиц для ведения журнала
Имеются примеры сценариев для создания баз данных журнала службы межсетевого экрана и журнала трафика веб-прокси. Эти сценарии находятся в каталоге папки установки Forefront TMG.
Чтобы настроить сервер SQL Server с базой данных, выполните следующие действия:
- Создайте базу данных на компьютере, на котором выполняется SQL Server.
- В командной строке введите следующую команду:
sqlcmd –E –S имя_экземпляра –i “Путь\файл_сценария" –d <имя_базы_данных>
Где:
- /E обозначает надежное соединение.
- /S обозначает сервер.
- имя_экземпляра — экземпляр базы данных.
- /i обозначает файл ввода.
- Путь — путь к установке Forefront TMG.
- файл_сценария — имя файла сценария базы данных, Fwsrv.sql для журнала службы межсетевого экрана или W3proxy.sql для журнала трафика веб-прокси.
- /d обозначает файл базы данных.
- имя_базы_данных — база данных журнала, в которой будут созданы таблицы.
Настройка сервера SQL Server на прием подключения к данным
Чтобы настроить сервер SQL Server на прием подключения к данным с компьютера Forefront TMG, выполните следующие действия:
- Запустите Microsoft SQL Server Management Studio и подключитесь к экземпляру SQL.
- Нажмите кнопку Безопасность.
- Чтобы добавить имя входа, щелкните правой кнопкой мыши узел Имена входа, выберите команду Создать имя входа и настройте проверку подлинности. Если компьютер с сервером SQL Server находится в том же домене, что и сервер Forefront TMG, входить на компьютер с SQL Server можно, используя либо проверку подлинности Windows, либо проверку подлинности SQL Server. Если сервер SQL Server находится в другом домене, необходимо использовать проверку подлинности SQL Server. Выполните настройку так, как указано ниже.
- Чтобы использовать Проверку подлинности Windows с учетными данными пользователя (это рекомендуемый способ использования Проверки подлинности Windows), создайте имя входа на основе существующего пользователя или используйте существующее имя входа. В поле Имя введите имя, определяющее метод входа. На вкладке Доступ к базе данных выберите базы данных, доступ к которым будет осуществляться на основании данного метода входа (базы данных, созданные в предыдущей процедуре).
- Чтобы использовать Проверку подлинности Windows без учетных данных пользователя (т.е. используя учетную запись компьютера), введите в поле Имя строку имя_домена\TMGname$, где "TMGname" — это имя NetBIOS сервера Forefront TMG. На вкладке Доступ к базе данных выберите базы данных, доступ к которым будет осуществляться с использованием данного метода входа (базы данных, созданные в предыдущей процедуре).
- Чтобы использовать проверку подлинности SQL Server, введите в поле Имя имя, определяющее метод входа, и пароль для данного метода. На вкладке Доступ к базе данных выберите базы данных, доступ к которым будет осуществляться на основании данного метода входа (базы данных, созданные в предыдущей процедуре).
- Чтобы использовать существующее имя входа, щелкните правой кнопкой мыши соответствующее имя и выберите команду Свойства. На странице Доступ к базе данных диалогового окна Свойства имени входа выберите строку, содержащую базу данных.
- В разделе Роли базы данных для <имя_базы_данных> установите флажки db_datareader (разрешения SELECT) и db_datawriter (INSERT). Кроме того, предоставьте службам Forefront TMG, подключенным к этой базе данных, права db_executor (права на выполнение) на процедуру sp_batch_insert.
Настройка шифрованного подключения
По умолчанию сервер Forefront TMG использует при подключении к компьютеру с сервером SQL Server протокол HTTPS для защиты конфиденциальных данных в файлах журнала. Чтобы воспользоваться шифрованным подключением, необходимо настроить сертификат на компьютере с сервером SQL Server и установить сертификат корневого центра сертификации на компьютер Forefront TMG. Дополнительные сведения см. в разделе Шифрование подключений к серверу SQL Server на веб-сайте Microsoft TechNet.
Настройка правил системной политики для ведения журнала на сервере SQL Server
Чтобы войти в базу данных SQL, необходимо включить группу настройки системной политики удаленного ведения журнала.
Чтобы включить группу настройки системной политики удаленного ведения журнала:
- В дереве консоли Forefront TMG щелкните правой кнопкой мыши узел Политика межсетевого экрана и выберите пункт Изменить системную политику.
- В узле Редактор системной политики в списке Группы настройки выберите пункт Ведение удаленного журнала (SQL).
- На вкладке Общие установите флажок Включить данную группу настройки.
- В данном правиле предполагается, что сервер SQL Server находится во внутренней сети по умолчанию. Чтобы изменить назначение правила, откройте вкладку Кому и измените назначение соответствующим образом. Изменять назначение рекомендуется только для того, чтобы включить в него компьютер с сервером SQL Server.
Связанные разделы
technet.microsoft.com
Запуск и первоначальная настройка MS SQL Server для клиент-серверной версии «1С: Предприятие 8»
Нет сомнения, что связка MS SQL Server + сервер «1С: Предприятие 8» — в своей нише самая востребованная и часто применяемая связка. Для её качественной поддержки желательно понимание обоих продуктов. В то же время, на практике, специалист поддержки обычно либо специализируется на администрировании MS SQL Server и не ориентируется в особенностях сервера «1С: Предприятие 8», либо, наоборот, специализируется на администрировании сервера «1С: Предприятие 8» и не ориентируется в особенностях MS SQL Server.
Настоящая статья написана в помощь и тем, и другим специалистам, призвана сэкономить Ваше время и обратить Ваше внимание на наиболее важные детали при совместном использовании данных программных продуктов.
Для облегчения восприятия информации приводятся случаи из практики, примечания и советы (выделены курсивом).
Трёхзвенная схема
Как, возможно, уже известно читателю, база данных в рассматриваемом случае имеет трёхзвенную архитектуру:
Звено 1: СУБД MS SQL Server. «Хранит» и обслуживает базу данных, в конечном счёте выполняет все виды операций с базой данных. Таким образом, производительность работы базы данных, скорость и параллельность чтения-записи данных – во многом определяются производительностью MS SQL Server.
Звено 2: Сервер «1С: Предприятие 8». Служит посредником во взаимодействии между клиентами (пользователями) и MS SQL Server. Все клиентские запросы направляются на сервер, который «переводит» их на язык запросов MS SQL Server, получает результаты выполнения этих запросов, отправляет результаты клиенту.
Есть лишь малая часть операций, которые выполняются на уровне сервера «1С: Предприятие 8», без обращения к MS SQL — это, в частности, отслеживание так называемых «управляемых блокировок», чтение-запись «параметров сеанса». Обращения к СУБД в таких случаях не требуется, так как эти операции производятся не с данными базы, а со вспомогательной информацией сервера.
Звено 3: Клиентская часть «1С: Предприятие 8». Обращается к серверу «1С: Предприятие 8», получает от него результаты (то есть, например, выборки данных), отвечает за пользовательский интерфейс.
«Хотел как лучше».
После переустановки сервера «1С: Предприятие 8» пользователи жалуются на резкое падение производительности. Специалист по внедрению ПП «1С: Предприятие», производивший переустановку – лишь удивляется – мол, хотел как лучше, система должна была начать работать быстрее… Анализ ситуации показал, что серверу «1С: предприятие 8» была выделено слишком много ресурсов: его процессы (см. пункт 3) rphost заняли 15.5 Гб из 16Гб оперативной памяти сервера, в результате для уступчивого MS SQL Server практически не осталось доступной оперативной памяти.
Как результат – постоянный «своп», ненужная нагрузка на дисковую подсистему, и крайне медленное выполнение операций с базой данных — вследствие того, что MS SQL Server не успевает обрабатывать запросы, поступающие от «разогнанного» сервера «1С: Предприятие 8».
Совместимость продуктов
Актуальные данные о версиях MS SQL Server, рекомендуемых к использованию в связке с «1С: Предприятие 8», следует выяснять по ссылке http://v8.1c.ru/requirements/.
На момент подготовки статьи разработчики фирмы «1С» рекомендуют следующие варианты:
- 2. SQL Server 2008, требуется установка пакета обновлений 1 (SP1).
- 3. SQL Server 2005, требуется установка пакета обновлений 3 (SP3).
Технически возможно, но не рекомендуется применение MS SQL Server 2000, для него требуется установка пакета обновлений 2 (SP2), и желательна установка пакета обновлений 4 (SP4).
Следует учитывать, что в настоящий момент эта версия снята с поддержки, а также не имеет 64-разрядной версии для архитектуры x86-64.
Обратите внимание:
Необходимо обращать внимание на настройки операционной системы: например, для эффективной работы M SQL Server 2008 под ОС Server 2008R2 требуется отключение сбалансированного режима энергоснабжения и перевод в режим максимальной производительности.
Установка клиент-серверной версии «1С: Предприятие 8»
«1C установил»
У одного из заказчиков установку «1С: Предприятия 8» произвёл системный администратор, не имеющий опыта в работе с «1С:Предприятием 8». И хотя, по его словам, он «установил 1С» — на пользовательских компьютерах отсутствовала клиентская часть, а на сервере — серверная. Разбор ситуации прояснил картину – в комплекте «1С: Предприятия 8» имелось 2 диска – установка платформы и установка шаблонов баз данных. Администратор не стал вникать в порядок установки – и установил шаблоны баз данных, а не исполняемые файлы, компоненты платформы.
Конечно же, это нетипичный пример исключительно невнимательного отношения к работе.
При установке «1С: Предприятия 8» следует учитывать, что отдельно устанавливаются:
- Платформа «1С: Предприятие 8» — исполняемое приложение, интегрированная среда разработки и эксплуатации баз данных. При его запуске выбирается один из двух режимов работы – «Предприятие» (пользовательская оболочка баз данных) либо «Конфигуратор» (интегрированная среда разработки). Более полное описание можно прочитать по ссылке
http://v8.1c.ru/overview/Platform.htm
- Шаблоны конфигураций «1С: Предприятие» — это файл внутреннего формата платформы, с помощью которого платформа может создать чистую или демонстрационную базу данных той структуры, которая заложена в шаблоне. Также с помощью шаблона обновления можно обновить структуру существующей базы данных, уже наполненной данными.
- При установке платформы следует уделить внимание выбору компонент:
Компонента «1С: Предприятие» может не устанавливаться на сервере (серверах).
В этом случае сервер будет предоставлять клиентским компьютерам доступ к базам данных «1С: Предприятие», но работа с БД в пользовательском режиме непосредственно с сервера будет невозможна.
Обратите внимание:
64-битная версия платформы не содержит клиентской части. Поэтому при установке на сервер отдельно устанавливаются 64-битные серверные компоненты, и отдельно – 32-битные компоненты клиентского приложения.
Компонента «Сервер 1C: Предприятия» нужна для подключения к MS SQL Server — это сервер приложений, связующее звено между платформой на клиентских рабочих местах и MS SQL Server.
Возможна установка компоненты в режиме простого приложения или системного сервиса, и рекомендуется, конечно — второй вариант.
При установке «как сервис» эта компонента будет запускаться и выполняться от имени выбранного пользователя:
После загрузки компонента порождает несколько процессов, как то: «агент сервера», «менеджер кластера серверов», «рабочие процессы сервера».
Запросы к базе данных исполняют рабочие процессы, а нагрузку между ними распределяет менеджер кластера серверов.
Рабочими процессами сервера можно будет управлять (добавлять, удалять, ставить ограничение на использование ОЗУ, объявлять основным или резервным), если будет установлена компонента «Администрирование сервера 1С: Предприятия».
Обратите внимание:
Для 32-битной версии сервера рекомендуется установка рабочих процессов в таком количестве, чтобы не оставлять оперативную память незадействованной — каждый из них имеет заметное ограничение на использование оперативной памяти, от 2 до 4Гб в зависимости от конфигурации системы.
Для 64-битной версии сервера теоретически достаточно двух рабочих процессов – одного рабочего и одного резервного. Однако на практике для обеспечения надёжности и стабильности подключений на существенном (несколько сотен) количестве пользователей требуется большее количество, оно зависит многих факторов — от количества пользователей, наполнения базы данных и объёма выполняемых запросов, поэтому авторы считают, что количество процессов в этом случае следует подбирать экспериментально.
«Уроборос»
После неудачной оптимизации настроек сервера «1С: Предприятие 8» пользователи просигнализировали о крайне медленной работе системы, а системный администратор отметил постоянную 100% загрузку процессора на сервере.
Анализ ситуации показал источник проблемы — при настройке было установлено слишком маленькое ограничение на использование оперативной памяти рабочими процессами.
А дело в том, что данное ограничение работает следующим образом:
Когда менеджер кластера серверов видит, что рабочий процесс превысил лимит оперативной памяти – работа этого процесса прекращается, он отключается, создаётся новый рабочий процесс, а подключения и запросы пользователей перераспределяются между рабочими процессами.
Установленное ограничение было настолько маленьким (300Мб), что рабочий процесс не мог полностью обслужить даже одного интенсивно работающего пользователя — в результате менеджер кластера серверов непрерывно перезапускал рабочие процессы и переподключал пользователей. Как только создавался новый процесс и пользователи к нему подключались – лимит оперативной памяти почти мгновенно достигался и вызывал следующий перезапуск. На это и уходило 100% загрузки процессора.
Компонента «Сервер 1C: Предприятия» не нужна на клиентских рабочих местах, да и не сможет там запуститься, так как требует физического наличия ключа защиты.
В случае, если количество подключаемых пользователей невелико (менее 50) – сервер приложений обычно устанавливают на том же компьютере, где работает MS SQL Server.
Для систем с большим количество пользователей и/или большим объёмом информационных потоков рекомендуется раздельная установка, а также применение кластера серверов.
Компонента «Администрирование сервера 1С: Предприятия» может быть полезной и на клиентах – например, с её помощью можно увидеть список информационных баз, подключённых к заданному серверу «1С: Предприятия».
На самом сервере её настоятельно рекомендуется установить.
Доступ
Обратите внимание:
Для проверки того, что доступ обеспечен, недостаточно использования утилиты администрирования серверов 1C: Предприятия, и тем более недостаточно присутствия сервера в «Сетевом окружении»!
Необходимо на каждом клиенте выполнить вход в базу данных, установленную на сервере – только это даст 100% уверенность, что доступ обеспечен.
1. В зависимости от политик безопасности, для MS SQL Server применяется аутентификация по учетной записи Windows либо аутентификация по учётной записи MS SQL Server.
В последнем случае при создании базы данных «1С: Предприятия» система будет запрашивать логин и пароль учётной записи MS SQL Server (например, sa), в первом случае логин и пароль следует оставлять пустыми:
и тому пользователю системы, от имени которого запущен сервер 1С: Предприятия, необходимо дать права в MS SQL Server, а именно:
- полные права на базу данных, в которой располагается информационная база
- доступ к базе данных master (роль public)
- рекомендуется – права на создание базы данных, в противном случае каждую новую базу данных нужно будет сначала создавать средствами MS SQL Sever, а уже затем подключать к серверу 1С: Предприятия
- рекомендуется — право на удаление своей базы данных
Например, можно назначить рассматриваемому пользователю предопределённую роль processadmin или sysadmin.
Совет.
Если у всех пользователей одновременно пропал доступ к рабочей базе данных – нужно перепроверить права и роли пользователя в MS SQL Server, в том числе установленные для конкретной базы данных, то есть User mapping:
2. Сервер 1С: Предприятия обращается к MS SQL Server через механизм Microsoft Data Access, поэтому его компоненты должны быть установлены, а у пользователя сервера 1С: Предприятия (см. предыдущий пункт) должны быть права на их запуск.
3. Связь между клиентами и сервером поддерживается по протоколу TCP, поэтому необходимо, чтобы этот протокол поддерживался обеими сторонами. Возможны проблемы с сопоставлением имени сервера и его IP адреса, например, если используется одноранговая сеть. В таком случае следует записать соответствие в файле [С:\WINDOWS\] system32\drivers\etc\hosts .
Совет.
В случае, если сеть одноранговая – для обеспечения постоянного подключения к серверу создайте сетевой диск, который обращается к какой-либо из папок этого сервера.
4. В случае использования протокола Named Pipes, и если MS SQL Server и сервер 1С: Предприятия установлены на разных компьютерах – пользователь, от имени которого работает сервер 1С: Предприятия, должен быть зарегистрирован в списке пользователей компьютера, на котором запущен MS SQL Server.
5. В некоторых случаях может потребоваться дополнительная настройка брэндмауэра Windows, то есть добавление исключений.
6. Некоторые антивирусы могут блокировать «нежелательный» сетевой трафик, так что может потребоваться дополнение их списков исключений.
7. Релиз платформы «1С: Предприятия 8» должен быть абсолютно одинаковым на клиенте и на сервере.
«Близнецы»
«У одного из заказчиков применялось два сервера баз данных, на каждом из которых располагалась одна рабочая база. Пользователи работали — каждый одновременно с обеими базами. Службы поддержки выполнила обновление платформы «1С: Предприятия 8» на серверах и клиентах…. И тут посыпались жалобы на невозможность подключения – то к одной, то к другой базе. Анализ ситуации показал – обновление на клиентах и серверах делали несколько человек, и устанавливающие специалисты не перепроверяли, что устанавливают один и тот же релиз. Поэтому на одном сервере был один релиз платформы, на втором – другой, на половине клиентов – первый из этих релизов, на другой половине – другой. Получилось, что каждый пользователь имеет доступ только к одной из баз данных.
Для быстрого решения проблемы пришлось устанавливать каждому пользователю оба релиза платформы и создавать отдельные ярлычки для входа в каждую базу данных.
Первоначальные настройки MS SQL Server и базы данных
“И так работает”
MS SQL Server отличается простотой начальной установки, поэтому не все администраторы озадачиваются его дополнительной настройкой – после выполнения установки по умолчанию база заработала, пользователи в неё вошли – работа выполнена. Такой подход почти всегда влечёт за собой возникновение проблем примерно через месяц или два – причём, конечно же, внезапно и в самый неудобный момент.
Например, в случае, если база предназначена для ведения учёта – перед сдачей налоговой отчётности зачастую возникает необходимость срочно пересчитать те или иные данные, причём пересчитать массово, скажем «все поступления основных средств с начала года». Причём – в течение рабочего дня, без остановки работы остальных пользователей базы данных.
И, конечно, именно в этот момент обнаружится, что база при таком пересчете «зависает», или «вылетает», или не даёт работать остальным пользователям.
Этот своего рода «закон Мэрфи» касается каждого из нижеперечисленных пунктов.
Перед началом использования MS SQL Server в качестве СУБД для «1С: Предприятие» рекомендуется:
1. Установить значение параметра max degree of parallelism равным 1.
То есть:
- зайти в MS SQL Management Studio
- после подсоединения к серверу войти в свойства сервера через контекстное меню, пункт Properties
- далее выбрать страницу Advanced и отредактировать параметр max degree of parallelism
В противном случае некоторые запросы, формируемые сервером 1С: Предприятия, могут вызвать ошибку «Intra-query parallelism caused your server command (process ID #XX) to deadlock. Rerun the query without intra-query parallelism by using the query hint option (maxdop 1)». После этой ошибки клиентская часть зачастую аварийно завершается.
Ошибка не будет проявляться стабильно, так как план запроса формируется по-разному в зависимости от накопленных статистик – она проявит себя на объёмных и сложных запросах, то есть в самый неудачный момент.
2. Создать План обслуживания (Maintance Plan), еженочно обрезающий (shrink) базу данных временных таблиц tempdb. Автоматически база временных таблиц сервером 1С: Предприятия очищается не всегда, а иногда, в результате неудачно написанного запроса, может быть сформирована и не очищена временная таблица размером, например, 50 Гб. Вследствие этого может закончиться место на диске, вследствие этого возможно аварийное завершение и клиентской, и серверной части, также присутствует небольшой риск нарушения целостности данных.
То есть нужно:
- зайти в MS SQL Management Studio
- после подсоединения к серверу раскрыть раздел «Maintance plans»
- создать новый (или дополнить имеющийся) План обслуживания,
- добавить в него пункт «Execute T-SQL Statement task» (так как в задании «Shrink database» нельзя выбрать базу tempdb) с кодом
1.USE [tempdb] 2. 3.GO 4. 5.DBCC SHRINKFILE (N’tempdev’ , 0, TRUNCATEONLY) 6. 7.GO 8. 9.DBCC SHRINKFILE (N’templog’ , 0, TRUNCATEONLY) 10. 11.GO
Следует учесть, что имя файла базы данных временных таблиц может не быть равным «tempdev». Для проверки этого имени можно использовать скрипт
1.USE tempdb 2. 3.GO 4. 5.EXEC sp_helpfile 6. 7.GO
“Горшочек, не вари”
Самый часто встречающийся на практике способ переполнить tempdb и тем самым «уронить» сервер – это забыть указать условие при соединении таблиц.
А именно, допустим, у нас в базе есть две таблицы, размером по 20 тысяч записей каждая. Допустим, между их записями можно установить однозначное соответствие, и мы пишем запрос, создающий временную таблицу, которая содержит 20 тысяч записей с полями обеих исходных таблиц. Но если мы забудем указать условие соединения – каждая запись первой таблицы соединится с каждой записью второй! То есть получится результирующая таблица из 20’000* 20’000=400 млн. записей. И так далее.
3. Ради снижения нагрузки на дисковую подсистему рекомендуется по возможности разносить по разным физическим дискам рабочую базу и tempdb , логи, файл подкачки системы.
Нужный путь для хранения файлов рабочей базы лучше задать при её создании, отредактировав колонку Path (Путь):
Для изменения физического расположения файлов базы временных таблиц используется команда ALTER DATABASE, то есть в MS SQL Management Studio нужно выполнить следующий скрипт (команда «New query»)
1.USE master 2. 3.GO 4. 5.ALTER DATABASE tempdb 6. 7.MODIFY FILE (NAME = tempdev, FILENAME = ‘Новый_Диск:\Новый_Каталог\tempdb.mdf’) 8. 9.GO 10. 11.ALTER DATABASE tempdb 12. 13.MODIFY FILE (NAME = templog, FILENAME = ‘Новый_Диск:\Новый_Каталог\templog.ldf’) 14. 15.GO
4. Не следует затруднять «рост» рабочей базы данных и её лога – ограничения на размер быть не должно, свойство «Autogrowth» должно быть установлено в процентах, рекомендуемое значение 10%. В противном случае добавление данных в базу, восстановление из архива и другие операции могут выполняться неоправданно долго.
Для установки этого свойства нужно через контекстное меню зайти в свойства базы, выбрать раздел Files, открыть редактирование свойств файла:
5. Рекомендуется включить в MS SQL Server поддержку сетевого протокола TCP/IP и выключить все остальные, в противном случае совместная работа MS SQL Server и сервера 1С: Предприятия будет менее стабильной.
6. Там же — очистить раздел Alias, т.к. её установка приводит к ошибкам взаимодействия MS SQL Server и сервера 1С: Предприятия.
Перед началом эксплуатации базы данных рекомендуется:
1. При создании базы данных из «1С: Предприятия» установить «смещение дат» 2000, в противном попытка записи даты ранее 01.01.1753 (что возможно в силу человеческого фактора) — будет вызывать сбои в работе базы данных.
Внимание! Смещение дат нельзя будет поменять у существующей базы данных!
2. Установить Режим восстановления (Recovery model) в значение Простой (Simple), либо создать План обслуживания (Maintance Plan), который будет ежедневно создавать резервную копию (backup) базы данных и обрезать журнал транзакций (log-файл). В противном случае при некоторых операциях журнал транзакций (log-файл) будет очень быстро расти: например, при реструктуризации базы данных рост размера log-файла может в несколько раз превысить размер самой базы данных.
3. Создать План обслуживания (Maintance Plan), выполняющий следующие регламентные задания как минимум раз в неделю:
- Создание резервной копии (backup) базы данных.
- Обновление статистик базы данных и очистка процедурного кэша (следует отметить, что свойство autoupdate statistics не подразумевает очистку процедурного кэша).
- Очистка процедурного КЭШа – не входит в стандартные операции Планов обслуживания, этот шаг нужно определять как выполнение скрипта (Execute T-SQL Statement) со следующим содержимым:
- Реиндексация таблиц базы данных.
Конечно же, при этом имеет смысл настроить автоматическую отправку электронных писем об успешном/неуспешном выполнении заданий.
Заключение
Рассмотрены вопросы, которые чаще всего вызывают затруднения у системных администраторов и внедренцев «1С: Предприятие 8», в связи с совместным использованием MS SQL Server и клиент-серверной версии «1С: Предприятие 8».
Автор надеется, что достаточно последовательно и доступно осветил «обе стороны медали».
P.S. Чаще делайте бэкапы!
Источник: http://technet.microsoft.com/ru-ru/sqlserver/hh282405
Источник: http://www.portal-yug.ru/blog/corp/34.php
iteron.ru
Основные настройки SQL Server | Windows IT Pro/RE
Когда вы, уважаемый читатель, участвуете в тех или иных проектах в качестве консультанта или обслуживаете целый ряд различных клиентов, сплошь и рядом возникают ситуации, не предполагающие какого-либо влияния со стороны исполнителя на то, как настраиваются системы, с которыми ему приходится иметь дело. Обычно при этом действует принцип: работаем с тем, что есть. Но в ряде случаев, когда вы собираетесь настраивать новую базу данных или переносить на новое место содержимое старой базы данных, у вас появляется возможность выполнить первоначальную настройку соответствующей системы. Конечно, в процессе первоначальной настройки экземпляра SQL Server в расчет приходится принимать множество соображений, но все же имеется ряд основополагающих настроек, рекомендованных для использования практически на всех новых экземплярах SQL Server.
1. Отключите параметр AUTO_SHRINK и установите параметр AUTO_GROW
Настройка AUTO_SHRINK предписывает базе данных автоматически уменьшаться в объеме. Казалось бы, идея правильная, но в большинстве случаев это не так. Чаще всего возникает следующая ситуация. Поскольку базы данных имеют обыкновение увеличиваться в объеме спорадически, использование команды AUTO_SHRINK приводит к сокращению объема базы данных, когда определенное количество данных стерто. В результате в процессе выполнения операции сокращения объема содержимое базы данных становится временно недоступным. В дальнейшем, если вновь будет возникать необходимость в увеличении объема базы данных с последующим сокращением, может образоваться порочный круг «рост-сокращение», что отрицательно скажется на производительности и приведет к фрагментированию файлов и индексов. В наше время лучше использовать другое решение: обзаведитесь дополнительным хранилищем и отключите функцию AUTO_SHRINK. Некоторые специалисты рекомендуют отключать параметр AUTO_GROW, но я полагаю, что лучше оставить его активированным из соображений безопасности. Если вы будете использовать это средство, лучше всего установить для него значение Megabytes option for File Growth; при этом значение должно быть достаточно большим для того, чтобы базе данных не приходилось увеличиваться в объеме слишком часто. С другой стороны, функция AUTO_GROW не должна заменять собою средства управления размером баз данных. Рекомендую использовать ALTER DATABASE MYDB SET AUTO_SHRINK OFF, а также ALTER DATABASE MyDB MODIFY FILE (NAME=MyDB_data, FILEGROWTH=1024 MB).
2. Отключите настройку AUTO_CLOSE
Настройка AUTO_CLOSE обеспечивает закрытие баз данных SQL Server и высвобождение ресурсов в тот момент, когда работу с базой данных завершает последний пользователь. В какой-то мере это правильное решение, однако дело в том, что в такой ситуации последующий запуск базы данных при обращении к ней пользователей влечет за собой значительные дополнительные расходы. Настройка AUTO_CLOSE не устанавливается по умолчанию, но она может быть артефактом для обновления с уровня SQL Server Express. Возможно также, что какой-либо другой администратор указал ее по ошибке. Используйте следующую настройку: ALTER DATABASE MyDB SET AUTO_CLOSE OFF.
3. Установите настройку AUTO_CREATE_ STATISTICS & AUTO_UPDATE_STATISTICS
Для выбора оптимального плана выполнения запроса оптимизатор запросов Query Optimizer использует статистические гистограммы. Для индексированных столбцов статистические показатели создаются автоматически, но, если вы хотите, чтобы SQL Server получал такие показатели и для других столбцов, следует установить настройку AUTO_CREATE_ STATISTICS. Планы использования оптимизатора запросов могут изменяться по мере того, как создаются и обновляются строки таблицы. При использовании настройки AUTO_UPDATE_STATISTICS оптимизатор запросов обновляет статистические данные перед выполнением компиляции запроса. Используйте настройки: ALTER DATABASE MyDB SET AUTO_CREATE_STATISTICS ON и ALTER DATABASE MyDB SET AUTO_UPDATE_STATISTICS ON.
4. Устанавливайте минимальные и максимальные значения для памяти SQL Server
Эти значения определяют верхнюю и нижнюю границы объемов памяти, используемой буферным пулом. Минимальное значение памяти позволяет сделать так, чтобы SQL Server не выделял объем памяти ниже установленного значения по достижении указанного порога. Ценность данного значения очевидна в случаях, когда SQL Server выполняется наряду с другими приложениями или в виртуальной машине с активированной динамической памятью. Максимальное значение серверной памяти отражает максимальный объем памяти, который SQL Server может выделять при запуске и выполнении. Задаваемые здесь значения определяются объемом памяти в главной системе. Рекомендуется ограничивать максимальный объем серверной памяти SQL Server значением, не достигающим уровня общего объема памяти главной системы. Задействуйте настройку sp_configure ‘max server memory’, 4096.
5. Используйте настройку Optimize for Ad Hoc Workloads
Эта настройка служит для оптимизации объемов памяти, применяемых однопользовательскими и созданными для конкретного случая планами запросов в кэше процедур. Она позволяет системе SQL Server при первом запуске хранимого в кэше процедур нерегламентированного плана запросов содержать в памяти только небольшую заглушку для этого плана. Таким образом объем памяти, необходимый для работы с кэшем процедур, сокращается. Используйте настройку sp_configure ‘optimize for ad hoc workloads’,1.
6. Разделяйте файлы данных и файлы журналов
Кому-то такая рекомендация, возможно, покажется излишней. Но мне так часто приходилось сталкиваться с системами, на которых файлы данных и журнальные файлы размещаются на одном и том же диске, что многим в это трудно поверить. Данная ситуация особенно часто встречается в виртуальных системах SQL Server. В сущности, такая организация подходит лишь для очень небольших установок — во всех прочих случаях быстро начинается конкурентная борьба за каналы ввода-вывода. Физические системы должны «привязываться» к различным накопителям. Виртуальные системы должны обеспечивать размещение файлов данных и журнальных файлов на виртуальных жестких дисках, причем каждый виртуальный диск обслуживается отдельными физическими накопителями.
7. Отделяйте файлы TEMPDB от других файлов данных
Файлы TEMPDB используются для размещения глобальных или локальных таблиц временного хранения, временных хранимых процедур, табличных переменных, а также внутренних объектов, созданных средствами процессора базы данных. Известно, что файлы данных рекомендуется хранить отдельно от журнальных файлов. Подобным же образом необходимо отделить испытывающую большую нагрузку из-за операций записи базу данных TEMPDB от производственных баз данных и журнальных файлов. В физических системах необходимо указывать особый накопитель для TEMPDB. В виртуальных системах базу данных TEMPDB следует размещать на отдельном виртуальном жестком диске, который обслуживается отдельным физическим накопителем, где не размещаются ни файлы данных, ни журнальные файлы.
Работа с унаследованным экземпляром SQL Server
Как составить контрольный список обязательных действий для подготовки к работе с унаследованным экземпляром SQL Server? Такую задачу, вероятно, приходилось решать каждому, кто работает с SQL Server. Может быть, вы только что приступили к новой работе или являетесь администратором Windows, на которого возложена обязанность управлять SQL Server, или вы консультант, приглашенный для решения определенной проблемы. Так или иначе, вы работаете с экземпляром SQL Server и одной либо несколькими базами данных, о которых ничего не знаете. Несмотря на неблагоприятные исходные условия, несколько ключевых моментов следует проверить немедленно. Ниже перечислены некоторые важнейшие свойства системы и базы данных SQL Server, заслуживающие внимания в первую очередь.
- Проверьте, сделаны ли резервные копии. Способность восстановить данные — самая важная обязанность администратора базы данных, и первый шаг к этому — резервное копирование баз данных.
- Проверьте модель восстановления. Большинство производственных баз данных должны быть настроены на использование полной модели восстановления, чтобы обеспечить восстановление данных на определенный момент времени. Необходимо проверить модель для понимания возможностей восстановления.
- Контролируйте дисковое пространство. При переходе на новую систему стоит убедиться, что на диске достаточно места для экземпляра SQL Server.
- Редакция SQL Server и пакет обновления. Для понимания возможностей и текущего состояния системы необходимо знать редакцию SQL Server и пакет обновления.
- Найдите файлы базы данных (.mdf) и файлы журналов (.ldf). В большинстве систем следует размещать эти файлы на различных накопителях или в пулах хранения.
- Найдите tempdb. Для интенсивно используемых систем tempdb также следует разместить на отдельном накопителе или в пуле хранения.
- Проверьте параметры AutoGrow и AutoShrink. Как правило, AutoShrink следует отключать, но рекомендуется назначить определенный размер AutoGrow, чтобы уменьшить возможность разрастания базы данных.
- Автоматически создавайте статистические данные и автоматически же обновляйте статистику. Чтобы помочь SQL Server оптимизировать запросы, обычно предпочтительно включить оба параметра.
Достижение целевых уровней производительности SQL Server
Производительность всегда была одной из основных характеристик, на которую обращали внимание администраторы баз данных, в основном из-за ее важности для пользователей. Если сервер работает медленно, об этом всегда становится известно администратору. Поддержание производительности на нужном уровне — необходимое условие эффективности работы сотрудников компании. Однако обеспечение успешного функционирования экземпляров SQL Server — не та задача, которую можно решить раз и навсегда. Базы данных постоянно растут. Рабочие нагрузки пользователей не всегда прогнозируемы и меняются со временем. Постоянно изменяются требования бизнеса и информационные условия. Кроме того, особенности доступа приложения к данным могут меняться при каждом обновлении приложения. Все эти факторы приводят к подвижности характеристик производительности SQL Server.
Важность эталонных тестов
Эталонное тестирование систем SQL Server поможет преодолеть негативные последствия изменчивости среды SQL Server. Не все администраторы проводят эталонное тестирование, а напрасно. Это незаменимый инструмент текущего мониторинга, а также поиска неисправностей и планирования ресурсов. Для регулярного проведения эталонных тестов ваших экземпляров SQL Server потребуются усилия и время, но в результате вы получите возможность записать типовые рабочие характеристики системы, что позволит быстро обнаруживать причину при снижении производительности.
Ключевые показатели производительности
Основной инструмент эталонного тестирования — системный монитор perfmon.exe. С его помощью можно отслеживать характеристики производительности как Windows Server, так и SQL Server.
Существует множество различных счетчиков производительности как для Windows Server, так и для SQL Server. Перечислим ключевые показатели производительности, которые полезно отслеживать для Windows Server.
- Процессор: %Processor Time — отслеживает время использования процессора сервера.
- Available Mbytes — отслеживает доступную память.
- Сетевой интерфейс: Bytes Total/sec — отслеживает общее использование сети.
И некоторые ключевые показатели производительности, которые полезно отслеживать для SQL Server:
- SQLServer: SQL Statistics: Batch Requests/sec — отслеживает, насколько занята система;
- SQLServer: Buffer Manager: Buffer Cache Hit Ratio — отслеживает процент запросов, обслуживаемых кэшем буферного пула;
- SQLServer: Access Methods: Full Scans/sec — отслеживает число выполненных полных просмотров таблиц.
www.osp.ru
Настройка MS SQL Две тыщи 5 для 1С Предприятия — Linux портал
Неплохого времени, гости и читатели блога k-max.name. На данный момент публикую небольшую мемори-записку о настройке Microsoft SQL Две тыщи 5 для 1С Предприятия. Думаю для других нужд использования MS SQL данная статья тоже даст некоторую информацию.
Итак, начнем...
Шаг 0. Перед установкой и настройкой MS SQL Две тыщи 5 лучше иметь Три физических диска. Один - для системы, 2-ой - для файлов баз и 3-ий - для журналов транзакций SQL. При всем этом, раздел для логов SQL и tempdb лучше чтобы был более производительным (например RAID 1+0).
Шаг 1. Установка сервера MS SQL
При установке SQL-сервера для работы с 1С достаточно следующих включенных компонент (более кропотливо о компонентах Microsoft SQL тут, об установке серера тут):
#image.jpg На данном изображении:- Integration services - не неотклонимый элемент - нужен для управления пакетами SSIS (планами обслуживания (экспорт/импорт)), позднее его можно будет отключить
- Database Servises - практически сам сервер СУБД - Client Component - Managment Tools - утилита управленияДругие функции при установке по Вашему вкусу. Единственный нюанс - необходимо правильно установить способ сортировки collate. Для автоматической и правильной работы необходимо в "Языке и региональных образцах" операционной системы выбрать "Русский".
В этом случае при установке SQL Server сам предложит правильную сортировку Cyrillic_General_CI_AS. Выбор режима проверки подлинности юзеров укажите смешанный (mixed). Другие свойства всегда можно скорректировать после установки - 1С:Предприятие будет работать независимо от их.
Более кропотливо об установке (ахтунг - English):
Лучше обновить сервер MS SQL до актуального релиза (на текущий момент - SP4 для Две тыщи 5 SQL). Не считая того, на многопроцессорных системах сервер Microsoft SQL Две тыщи 5 может отрешиться устанавливаться с ошибкой Одна тыща 50 три (The error is (1053) The service did not respond to the start or control request in a timely fashion). Решение этой трудности описано тут.
Шаг 2. Настройка сервера Microsoft SQL 2005
2.1. Настройка протоколов подключения
Для функции протоколов взаимодействия сервера и клиента Microsoft SQL необходимо запустить "SQL Server Configuration Manager":
#image.jpg
...и кинуть для работы только протоколы TCP/IP и Shared Memory:
#image.jpg
Если устанавливается версия MS SQL Express по-умолчанию выключен протокол TCP/IP, подходящий для работы с 1С:Предприятие Восемь - его необходимо включить. Протокол именнованных каналов (Named Pipe) выключите совсем (и для "клиента" тоже на сервере приложений).
2.2. Перенос tempdb на быстрый независимый массив/диски
Для переноса tempdb необходимо запустить sql-скрипт примерно следующего содержания:
USE master GO ALTER DATABASE tempdb modify file (NAME=tempdev, FILENAME='E:\Temp\tempdb_data.mdf') GO ALTER DATABASE tempdb modify file (NAME=templog, FILENAME='E:\Temp\tempdb_log.ldf') GOгде, E:\Temp\ - каталог, в каком будут лежать tempdb, а tempdb_data.mdf и tempdb_log.ldf имя файла базы данных и лога соответственно.
2.3. Настройка черт сервера SQL
Для функции сервера запускаем "SQL Server Management Studio", подключаемся к установленному серверу Database Engine'ом и открываем свойства (Server Properties). Тут нам нужно настроить Три пт:
Память (Memory)
#image.jpgПараметр "Maximum server memory (in MB)" задает очень отведенное серверу количество памяти из расчета: [Полное количество оперативки сервера] – [3ГБ под систему(1,5ГБ если Win2k3)] – [сколько_нужно ГБ * количество процессов работающих на данном сервере (если SQL еще некоторый принципный сервис крутится на этом же сервере)]. Например, если у нас на сервере всего 20 четыре ГБ оперативки, стоит Windows Две тыщи три и запущен сервер 1С Предприятия с 2мя процессами rphost (которым нужна память хотябы по 1,5Гб) то рассчет будет следующим: 20 четыре - 1,5 - 1,5*2 = 19,5 ГБ ставит параметр "Maximum server memory (in MB)". Это необходимо для того, чтобы sql-сервер рассчитывал на данный объем и вызволял память заблаговременно, т.к. если поставить неограниченный объем, и сервер попробует получить память, которой нет, он начинает лезть в файл подкачки, что очень замедлит работу.
Процессоры (Processors)
#image.jpgНаибольшее количество потоков (Maximum worker threads) стОит регулировать только при большом количестве клиентов (более 255) и для 1С это не актуально, поэтому оставим по-умолчанию. (хотя некоторые молвят обратное #image.jpg ). Также выставляем галку завышенного приоритета сервера (Boost SQL Server priority).
Database Settings
#image.jpgВ данном пт можно настроить сборники для файлов Данных и логов, чтобы новые базы данных создавались непосредственно там.
2.4. Дополнительные "приседания"
Лучше просканировать СКЛ утилитой SQL Server Две тыщи 5 Best Practices Analyzer и избавиться от ошибок и сообщений (как? и опять как?).
Шаг 3. Настройка рабочих баз данных Ms SQL
#image.jpgЕсли база еще не развернута из .dt файла, и вы осознаете примерный ее размер, то первичному файлу размер инициализации лучше слету указать больший или равный размеру базы, но это дело вкуса, он все равно вырастет при развертке до подходящих размеров. А вот Автоувеличение (Autogrowth) размера необходимо обязательно указать примерно по Двести МБ на базу и по 50 МБ на лог (можно прирастить/уменьшить, зависимо от размера конечной базы и наличия места на диске), т.к. значения по умолчанию – рост по 1МБ и по 10% очень очень тормозят работу сервера, когда ему при каждой 3й транзакции необходимо файл увеличивать. В этом же параметре можно ограничить размер файла лога, чтоб очень не разростался, хотя это очень спорный параметр...
Другие свойства можно кинуть по умолчанию, не считая некоторых:
#image.jpgНапример, параметр AutoShrink советуют отключить, ибо он приводит к постоянным скачкам размера лога. Лучше его держать в узде с помощью Планов обслуживания (они же Регламентные задания, они же Maintenance Plans).
Шаг 4. Настройка Планов обслуживания (Maintenance Plans, Регламентных заданий)
#image.jpgДля работы регламентных заданий необходимо сделать план обслуживания:
Итак, приведу свой пример настроенного Maintenance Plans с комментариями. Мой план состоит из 5 подпланов:
1-ый подплан (ежедневное еженочное сервис сервера и запасных копий):
#image.jpg
Данный подплан состоит из нескольких шагов. Связи зеленого цвета задают переход к следующему заданию при успешном окончании (т.е. без ошибок), связи голубого цвета задают переход к следующему заданию при любом итоге выполнения текущего.
Свойства шагов видны на размещенных в редакторе заданиях. Свойства некоторых заданий нужно описать раздельно.
Первым шагом делается "Проверка целостности базы данных" (Check Database Integrity Task), которая делается для всех баз системы и следующие задания выполняются только при отсутствии ошибок при проверке баз. Следующим шагом делается "Перестроение индексов баз данных" (Rebuild Index Task) для всех баз данных сервера.
Данная процедура довольно ресурсоемкая, но в последствии ускоряет работу базы, т.к. если фрагментированость индексов > 25%, это резко понижает производительность сервера. Если размер баз не позволяет делать данную задачу, т.к. она занимает много времени, то рекомендуется делать данное действие хотябы раз в неделю, при всем этом, на ночные задания поменять задачу Перестроение индексов баз данных (Rebuild Index Task) на Дефрагментацию индекса (Reorganize Index Task), которая менее ресурсоемка. Далее происходит "Обновление статистики базы данных" (Update Statistics Task) для всех баз данных, опять же для оптимизации. После этого задания рекомендуется выполнить "Очистку процедурного кэша":
#image.jpgПри всем этом, запускается процедура
DBCC FREEPROCCACHEПосле оптимизации работы лучше сделать запасную копию журналов транзакций. Этот шаг делать не обязательно, но лучше.
Во время выполнения прошедших шагов (Перестроение индексов баз данных (Rebuild Index Task) и Обновление статистики базы данных (Update Statistics Task)) файлы журналов вырастают примерно до размера базы данных, а то и более. В конечном итоге, в следующих подпланах при выполнении первого запасного копирования журнала транзакций, размер копии имеет довольно большой объем. Это может очень прирастить вермя восстановления базы. Таким образом, делая копию логов до полной копии, мы избавляемся от данной трудности. (спасибо за идею комментатору Kyoshiro)
#image.jpg
Далее можно выполнить полный бэкап заданием Создание запасной копии базы данных (Back Up Database Task):
#image.jpgПри выполнении данного задания копии складываются в сетевую папку на файловом сервере с расширением bak, при всем этом, для каждой базы создается своя папка:
SAMBA ~ # ls -1 /backup/full/ database1 database2 ... SAMBA ~ # ls -1 /backup/full/satabase1/ database1_backup_201111210250.bak database1_backup_201111220251.bak ...После заверешения сотворения запасной копии параллельно запускается Три задания: очистка запасных копий журналов транзакция (о разработке таких копий - ниже) старее 5 дней, очистка полных бэкапов старее Один недели и очистка истории старше Один месяца (сюда входит в основном - очистка служебной инфы MS SQL, такой как журнальчики):
#image.jpgДанный подплан у меня запускается каждую ночь в нерабочее время по будням:
#image.jpg
2-ой, 3-ий, 4-ый подплан (обновление статистики Трижды в день):
Следующие Три подплана идентичны по содержимому и различаются только временем выполнения. Выполняются Трижды в день - в 6, Тринадцать и Девятнадцать часов:
#image.jpg
Обновление статистики довольно ресурсоемкая задача, поэтому спланируйте ее выполнение в то время, когда база данных не очень загружена.
5-ый подплан (запасное копирование журнала транзакций):
Данный план делает инкрементальное копирование транзакционного лога Microsoft SQL Server:
#image.jpgКопирование делается каждые пол часа в рабочее время и сохраняется в сеть с расширением trn:
#image.jpg
После функции данного плана мы имеем неизменное запасное копирование с необходимым регламентным обслуживанием, с хранением копий базы данных за последние Семь дней с возможностью восстановления базы интервалом до 30 минут.
Более кропотливо о выборе и планировании плана обслуживания можно посмотреть данный подкаст:
Шаг 5. Траблешуттинг
Периодически необходимо рассматривать фрагментированность индекса для снижения нагрузки. Для большущих баз данных нужно уменьшать ненужные операции по дефрагментации тех индексов, для которых это не требуется.
Другими словами дефрагментацию делать не для всей базы, а для избранных таблиц, например. Если значение avg_fragmentation_in_percent в этом столбце превосходит 25%, то для восстановления исходных черт производительности рекомендуется выполнить дефрагментацию/реиндексацию этого индекса. Чтобы просмотреть текущую фрагментированность, можно воспользоваться отчетом:
#image.jpg
Для настроенного плана регламентных заданий периодически лучше просматривать историю на наличие ошибок и устранять их:
#image.jpg
FAQ MS SQL для 1С Предприятие
В связи с частыми похожими вопросами в комментах решил добавить FAQ.
Q: На данный момент настроил SQL и сделал план обслуживания. Все в точности по данной статье, но бэкапы не создаются. Почему? (ведь настроено создание бэкапов каждые 30 минут)A: Потому что бэкапы каждые 30 минут делают копии журналов транзакций. Данный вид копий может создаваться только от полной копии.
Соответственно, 5-ый подплан (бэкап лога транзакций) будет выполнен только после выполнения первого подплана и только после удачного выполнения шага полного бэкапа в первом подплане!!! Соответственно, выход из ситуации - дождаться выполнения первого подплана.
Q: Почему файл жарнала транзакций ростет? Как от этого избавиться? Что делать?A: Самый верный выход из ситуации - прирастить раздел жесткого диска, на котором размещен файл журнала. Уменьшать размер файла с помощью операции shrink только вызовет лишние обращения сервера к жесткому диску.
Сервер увеличивает размер этого файла до того размера, который ему нужен для выполнения транзакций. Соответственно, обрезав файл журнала мы заставляем SQL сервер снова насиловать жесткий диск - снова увеличивая размер журнала при очередной ресурсоемкой транзакции.
Данный нюанс я обсуждал в этой теме - советую перечитать ее. Есть еще выход - "если не очень сыкотно - можно перед ребилдом делать "финальный" бакап (можно только логов), ставить симпл модель, после ребилда - возвращать фулл рекавери и опять делать фулл бакап" отпять же отсюда (с).
Q: Почему не делается shrink для лога? многие советуют...A: см предыдущий вопрос\ответ
Дополнительно почитать:
- сервис базы данных MS SQL (регламентные задания и запасное копирование) от мекрософт тут и тут.- установка MS SQL 2005- Лучшие советы по действующему обслуживанию баз данных- Настройка почтовых уведомлений об ошибках выполнения плана MS SQL серера
Удачных Для вас бэкапов #image.jpg
upd 2012.12.09: добавлен FAQ
Похожие статьи
-
Установка и настройка DHCP сервера на Linux
Неплохого времени, уважаемые! На данный момент на блоге выкладываю мини-HOWTO функции DHCP-сервера на Linux. В статье желаю рассказать, как работает протокол DHCP? Как работает клиент DHCP?
А так же как фактиче...
-
Kerberos авторизация в SQUID на базе LDAP групп Active Directory
Приветствую, гости и читатели моего блога о Linux. Продолжаем расширять возможности squid. На данный момент попытаемся воплотить авторизацию доменных учеток Active Directory на базе их членства в группах.
В...
-
Samba инструмент для работы в сетях Windows
Статья написана в журнале ВзломщикОбычное видео для дочитавших до концаАдминистрирование даже сопоставимо небольшой сети настроенной как рабочая группа может замотать хоть какого даже самого тр...
-
Database Mail в MS SQL Две тыщи 5 уведомления об ошибках на email
Неплохого времени, читатели блога Любителя тестов! В продолжении статьи о Maintenance Plans для MS SQL Две тыщи 5 дополняю статьей о том, как настроить уведомление об ошибках Maintenance Plan MS SQL Две тыщи 5 п...
-
OpenVPN кроссплатформенный инструмент для сотворения виртуальных сетей
Статья написана в журнале ВзломщикДля терпеливых в конце видео. На данный момент время от времени когда все подразделения компании находятся в границах 1-го строения. Поэтому в некий момент перед системным администратором...
hpunix.org
Установка и настройка MS SQL 2008 R2. Конвертация базы данных ТЦУ3 (Видео)
Со времени публикации цикла статей по установке и настройке MS SQL Server 2005, разворачиванию на нем базы данных и подключению к ней ТЦУ-3 прошло почти 4 года. За это время ТЦУ приобрела возможность самостоятельно создавать базу данных на MS SQL Server, а также конвертировать в нее данные из базы данных формата MS Access. В статье "Организация работы с базой данных ТЦУ через Интернет" (настоятельно рекомендую ознакомиться с ней, особенно, если у вас в планах организовать работу с базой данных через Интернет) я обещал опубликовать свежую статью по конвертации базы данных ТЦУ в формат MS SQL Server. Выполняю обещание.
Пользователям, которые используют виртуальный хостинг MS SQL Server, конечно же, нет необходимости устанавливать и настраивать SQL Server, поэтому они могут сразу переходить к описанию конвертации базы данных.
Наш выбор версии сервера базы данных падает на надежную рабочую лошадку MS SQL Server 2008 R2. За долгое время своей эксплуатации он зарекомендовал себя с лучшей стороны, показав стабильность и надежность в работе и хранении данных. Также выбор в его пользу обусловлен поддержкой пока еще достаточно широко распространенных операционных систем Windows XP, Server 2003. К сожалению, новейшая версия MS SQL Server 2012 не поддерживает указанные ОС. Но те, кто захочет использовать на современных ОС (Windows 7, Server 2008 и новее) именно эту версию, могут также следовать данной статье, так как установка и настройка MS SQL Server 2012 практически ничем не отличается от установки и настройки MS SQL Server 2008 R2. В статье рассматривается установка MS SQL Server на Windows 7 SP1 x86. Клиентское рабочее место с ТЦУ, с которого будем конвертировать базу установлено на Windows 8. Полное видео вы найдете в конце статьи.
На сайте производителя загружаем нужный дистрибутив MS SQL Server 2008 R2 Express (бесплатная редакция) и на нужном языке. Обязательно обратите внимание на разрядность ОС, установленной на вашем сервере. Нельзя установить MS SQL Server для 64-х разрядных ОС на 32-х разрядные ОС, а MS SQL Server для 32-х разрядных систем не будет оптимальным выбором для 64-х разрядных ОС. Прямые ссылки дистрибутивов MS SQL Server 2008 R2 Express + MS SQL Management Studio 2008 Express на русском языке: для 64-х разрядных ОС, для 32-х разрядных ОС. Если у вас установлена Windows 7 SP1, то никаких дополнительных компонентов вам устанавливать не надо. Если же ваша версия Windows более старая, то необходимо дополнительно установить .NET Framework 3.5 SP1, установщик Windows 4.5 и Windows PowerShell 1.0. Полный перечень требуемых компонентов и ссылки на их загрузку смотрите на сайте производителя по ссылке, указанной выше.
Итак, вы выбрали компьютер, который будет сервером для MS SQL Server и загрузили нужный дистрибутив. Для начала рекомендуем убедиться, что сетевой интерфейс, через который будет осуществляться подключение к серверу БД, имеет статический IP адрес. Нужно это, прежде всего, для тех пользователей, кто планирует работать с базой данных через Интернет. В этом случае статический IP адрес используется для переадресации в маршрутизаторе.
"Панель управления" - "Центр управления сетями и общим доступом" - Изменение параметров адаптера" - Выберите нужный интерфейс и откройте его двойным щелчком. Кликните кнопку "Свойства" - "Протокол Интернета версии 4 (TCP/IP)":
Рис. 1. Настройки сетевого интерфейса
Запустите на выполнение ранее загруженный установочный дистрибутив SQLEXPRWT_x64_RUS.exe или SQLEXPRWT_x86_RUS.exe. Откроется Мастер установки. Выберите "Новая установка или добавление компонентов...":
Рис. 2. Центр установки SQL Server
Отметьте флажками нужные компоненты, как на рисунке:
Рис. 3. Выбор компонентов SQL Server
На шаге "Настройка экземпляра" рекомендуется установить выбор "Экземпляр по умолчанию". Такое решение подсказывает опыт, так как было установлено, что при организации доступа к базе данных через Интернет, при использованием некоторых типов маршрутизаторов и при "пробросе" в нем портов, доступ к базе данных MS SQL Server с именованной инстанцией становится невозможным. Виной тому некорректная работа маршрутизатора. Чтобы избежать таких проблем в будущем, мы не рекомендуем использовать именованные экземпляры MS SQL Server:
Рис. 4. Настройка экземпляра SQL Server
Установите для всех служб в списке тип запуска - АВТО. Установите использование одной и той же учетной записи для всех служб SQL Server, как показано на рисунке:
Рис. 5. Конфигурация сервера SQL Server
Режим проверки подлинности - Смешанный режим (проверка подлинности SQL Server и Windows). Укажите пароль для учетной записи системного администратора SQL Server. Настоятельно рекомендуется использовать в пароле цифры и символы в разных регистрах. Придумайте сложный пароль, отвечающий требованиям политики безопасности на вашем сервере:
Рис. 6. Настройка компонента Database Engine
При успешной установке SQL Server вы должны увидеть следующее сообщение:
Рис. 7. Завершение установки SQL Server
Откройте SQL Server Configuration Manager: "Пуск" - "Все программы" - "Microsoft SQL Server 2008 R2" - "Средства настройки" - "Диспетчер конфигурации SQL Server". Кликните ветку "Службы SQL Server". Проверьте, что режим запуска служб "SQL Server" и "Браузер SQL Server" установлен в "Авто", а состояние служб "Работает":
Рис. 8. Диспетчер конфигурации SQL Server - Службы SQL Server
Раскройте узел "Сетевая конфигурация SQL Server" и перейдите на ветку "Протоколы MSSQLSERVER". Для протокола TCP/IP установите состояние "Включено":
Рис. 9. Диспетчер конфигурации SQL Server - Протоколы MSSQLSERVER
После перевода состояния протокола TCP/IP в состояние "Включено" требуется перезапустить службу SQL Server:
Рис. 10. Диспетчер конфигурации SQL Server - Перезапуск службы SQL Server
Проверьте соответствие состояний для клиентских протоколов согласно картинке:
Рис. 11. Диспетчер конфигурации SQL Server - Клиентские протоколы
Для того, чтобы SQL Server мог принимать клиентские подключения из локальной сети и Интернета, необходимо разрешить в брандмауэре (файрволле) входящие подключения по портам 1433-1434 TCP/IP. Рассмотрим, как это сделать на примере брандмауэра Windows. Если же вы используете иной файрволл, то обратитесь к справке по продукту, чтобы узнать, как открыть в нем эти порты. "Панель управления" - "Брандмауэр Windows". В открывшемся окне кликните пункт "Дополнительные параметры":
Рис. 12. Брандмауэр Windows
"Правила для входящих подключений" - "Создать правило...":
Рис. 13. Брандмауэр Windows - Правила для входящих подключений
Тип правила - "Для порта":
Рис. 14. Брандмауэр Windows - Мастер создания правила для нового входящего подключения
Протокол - "Протокол TCP", порты - 1433 и 1434:
Рис. 15. Брандмауэр Windows - Мастер создания правила для нового входящего подключения
Действие - "Разрешить подключение":
Рис. 16. Брандмауэр Windows - Мастер создания правила для нового входящего подключения
Сохраните правило под именем "MSSQL 1433-1434 tcp". Повторите шаги, изображенные на рисунках 13-16, но на шаге выбора протокола укажите "Протокол UDP":
Рис. 17. Брандмауэр Windows - Мастер создания правила для нового входящего подключения
Сохраните и это правило под именем "MSSQL 1433-1434 udp". В результате в списке правил для входящих подключений брандмауэра Windows вы должны увидеть оба созданных правила:
Рис. 18. Брандмауэр Windows - Мастер создания правила для нового входящего подключения
Процесс конвертации очень прост. Запустите ТЦУ. Выберите в меню "Расширить возможности...", а затем кликните кнопку на ленте "SQL Server":
Рис. 19. ТЦУ-3. Конвертация данных
В мастере конвертации укажите IP адрес или имя компьютера-сервера с ранее установленным SQL Server. Если используется именованная инстанция SQL Server, не забудьте ее указать. Также укажите имя базы данных, которое будет использовано при создании базы. Если база данных с таким именем уже существует и уже при этом имеет необходимую структуру, конвертация данных будет невозможна. Тип аутентификации - "SQL Server Аутентификация". Укажите имя учетной записи системного администратора SQL Server "sa" и пароль, который был задан на шаге настройки компонента Database Engine мастера установки SQL Server 2008 (см. рис. 6). Если ТЦУ установлена на том же компьютере, что и SQL Server, то допустимо выбрать "Windows Аутентификация" без указания имени пользователя и пароля. Пользователям, которые используют виртуальный хостинг MS SQL Server, следует указать имя созданной базы, а также имя и пароль учетной записи SQL Server, полученными от провайдера. Нажмите кнопку ОК и дождитесь завершения конвертации. За ходом процесса можно наблюдать в статусной строке ТЦУ:
Рис. 20. ТЦУ-3. Конвертация данных
Дождитесь сообщения об успешной конвертации данных и закройте ТЦУ:
Рис. 21. Конвертация данных успешно завершена
Учетная запись системного администратора SQL Server использовалась нами только для создании базы данных. В дальнейшем из соображений безопасности ее следует отключить, а для возможности подключения к базе данных использовать другую учетную запись с ограниченными правами. Покажем, как ее создать. Пользователям, которые используют виртуальный хостинг MS SQL Server этот шаг можно пропустить, так как учетная запись SQL Server для них уже создана провайдером. Выполните на сервере SQL Server: "Пуск" - "Все программы" - "Microsoft SQL Server 2008 R2" - "Среда SQL Server Management Studio". В окне "Соединение с сервером" введите имя и пароль учетной записи системного администратора. Если вы выберите "Проверку подлинности Windows", то имя и пароль вводить не нужно:
Рис. 22. SQL Server Management Studio - Соединение с сервером
Раскройте узел "Безопасность" и кликните правой кнопкой на узле "Имена входа". В выпавшем контекстном меню выберите "Создать имя входа...":
Рис. 23. SQL Server Management Studio - Создание имени входа
Имя пользователя придумайте своё. В пароле используйте цифры, буквы в разном регистре, спецсимволы. Не используйте простые пароли, так как в данном случае безопасность очень важна:
Рис. 24. SQL Server Management Studio - Создание имени входа
На этом шаге происходит сопоставление созданной учетной записи с вашей базой данных, а также назначаются необходимые права на базу данных:
Рис. 25. SQL Server Management Studio - Сопоставление пользователей
А теперь отключите учетную запись системного администратора. Для этого раскройте узел "Имена входа" и кликните дважды на ветке "sa":
Рис. 26. SQL Server Management Studio - Имена входа
В разделе "Состояние" установите "Отключено" и кликните кнопку ОК. После этого следует завершить работу с SQL Server Management Studio:
Рис. 27. SQL Server Management Studio - Свойства имени входа
Запустите ТЦУ. Выполните "Справочники" - "Настройки":
Рис. 28. ТЦУ-3
Выполните последовательно шаги, как указано на рисунке. После выполнения шага №5 вы должны увидеть сообщение об успешной проверке подключения. Сохраните настройки. Поздравляем, вы подключили ТЦУ к базе данных MS SQL Server!
Рис. 29. ТЦУ-3. Подключение к базе данных SQL Server
Видеоинструкция по статье:
andriy.co