Posts Tagged "MS SQL Server"

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

Ниже мы приведём один из испытанных временем планов обслуживания баз MS SQL Server, обеспечивающий функционирование программ С:Предприятие в ежедневном режиме, когда выделяется 20 часов на работу и 4 часа на обслуживание.

Для начала поясним, что при установке SQL Server Management Studio версии 20 и старше для того, чтобы этот мощный и удобный инструмент поддерживал работу с планами обслуживания, нужно на предварительном этапе не забыть установить компоненту Microsoft Visual Studio под названием Бизнес-аналитика:

Если этого не сделать, то мы не увидим при нажатии правой кнопкой мыши по Меню “Maintenance Plans (Планы обслуживания)” следующего контекстного всплывающего подменю:

Кроме того, важно отметить, что даже если вы сможете создать планы обслуживания, вы не сможете их запустить на выполнение, если при установке самого MS SQL Server не устанавливали SSIS (SQL Server Integration Services), ибо все планы обслуживания работают через этот компонент:

Прежде чем создавать планы обслуживания дадим некоторые определения. План обслуживания – это цепочка некоторых действий, осуществляемых при помощи скриптов на языке Transact-SQL (T-SQL), которые нужно выполнять регулярно в строго определённой последовательности. Вообще говоря, все необходимые действия можно определить в рамках одного общего плана обслуживания, так как SSMS (SQl Server Management Studio) это позволяет сделать, но в этом случае он будет представлять из себя довольно сложную конструкцию, фактически некоторую большую программу с набором условных операторов. В этой ситуации, если по какой-то причине не отработала какая-то часть плана, то выполнить быстро только эту часть будет сложно. Посему один план с логическими ветвлениями  – худшая практика. Не мудрствуя лукаво, приведём ниже сравнительную таблицу подходов к созданию планов обслуживания, исходя из которой примем решение создавать несколько отдельных планов:

Итак, выбираем из нашего меню пункт “Maintenance Plan Wizard (Мастер Планов обслуживания)”. Появляется окно приветствия мастера создания планов обслуживания SSMS. Изучаем, что там написано. Оно нам в будущем не понадобится, поэтому ставим птичку и нажимаем на кнопку Next (Далее):

В следующем окне нам нужно будет дать имя нашему плану, например “MaintenancePlan-1”, которое будет отражать тот факт, что этот план должен будет выполняться первым в нашей цепочке. Далее крайне желательно ввести описание (Description) плана, например DBCC CheckDB.  Оно будет отражать суть действия плана, ибо первое, что нам нужно будет непременно делать регулярно, так это проверять целостность баз данных (команда “DBCC CheckDB” T-SQL). Точку оставляем на радиокнопке “Single Schedule for entire plan or no schedule (Единое расписание выполнения на весь план или без расписания)”:

Если нужно задать расписание, то нажимаем на кнопку Change (изменить):

Здесь в нашем случае в поле Recurs every выбираем Daily (ежедневно), ставим в поле Occurs once at ровно в 2:00, при условии, что обслуживание выполняем в период с 2 ночи до 6 утра, и нажимаем на кнопку “ОК”, более никаких полей не исправляя. Система возвратится к предыдущему окну, где нужно просто нажать на кнопку Next (далее), что приступить к выбору действий:

Тут нам нужно выбрать только первое действие “Check Database Integrity (Проверить целостность базы данных)”, однако если для каких-то планов обслуживания нужно будет выбрать несколько действий, то данный интерфейс это позволяет, ибо здесь представлен список с множественным выбором.

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

После того, как вы проставите птички напротив нужных баз данных, у вас загорится кнопка “ОК”, которую нужно будет нажать. Отметим, что обычной и лучшей практикой является выбор всех баз данных (All databases), имея ввиду то, что системные базы данных тоже нужно регулярно проверять! При этом, как правило, имеет смысл пометить и пункт “Ignore databases whose state is not online (Игнорировать базы данных, находящиеся в автономном режиме)” Далее происходит как бы возврат к предыдущему окну, где стоит обратить внимание на возможность выбора пунктов Tablock (Блокировка Таблицы) и Max Degree of Parallelism. Если ваш сервер не испытывает недостатка в ресурсах, то просто опять нажимаем на кнопку Next (Далее), что приводит нас к предпоследнему окну выбора места, куда будет писаться отчёт о работе данного плана обслуживания:

Здесь можно оставить всё по умолчанию, либо выбрать другой каталог в файловой системе. Можно также воспользоваться возможностью отправки отчёта на e-mail. Нажатие на кнопку Next (Далее) приведёт к появлению завершающего процесс создания плана обслуживания окна, в котором остаётся просто нажать кнопку Finish (Завершить), либо Cancel (Отмена):

В результате в списке планов обслуживания появится новая строка с заданным нами названием “MaintenancePlan-1”. Если дважды щёлкнуть мышью по ней, то можно увидеть следующее окно:

В нём видно расписание запуска, название, описание плана, а также выбранное нами действие. Если нажать правой кнопкой мыши по нижней части, где приведено действие, то в ниспадающем контекстном меню можно выбрать пункт Edit (Редактировать), открывающий окно, дающее возможность изменить перечень баз, к которым нужно применить данное действие. Кроме того, в новом окне есть кнопка “T_SQL”, благодаря которой можно увидеть скрипт tranact-sql, который создала  система для осуществления выбранного действия:

Важно заметить, что регулярная проверка целостности базы данных, которая планируется к осуществлению в созданном выше плане обслуживания, является едва ли самым важным делом любого администратора баз данных. Она может помочь предотвратить катастрофу, ибо база данных обычно рушится не сразу, могут происходить так называемые “Тихие повреждения (Silent Corruption”, происходящие когда диски, RAID-контроллеры или оперативная память сбоят и искажают данные при записи или чтении. DBCC CheckDB – чисто информационная процедура, подразумевающая три исхода:

• всё хорошо, можно не беспокоиться;
• базе данных не хватает дискового пространиства для расширения (alloc error);
• ошибки согласованности данных (consistency error)

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

Однако, если это не так, то нужно срочно принимать меры в следующем приоритетном порядке:

На этом мы заканчиваем повествование по созданию плана обслуживания, предназначенного для регулярной проверки целостности базы данных и приступаем к описанию процесса создания плана обслуживания, который тоже должен выполняться регулярно и называется “Обновление статистики (Update Statistics)”.

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

Дальнейшие ваши действия зависят от того, какой тип лицензии у вас есть. Если куплен и аппаратный клиентский ключ и установлен драйвер к нему, то нужно, как указано снизу на приведённом снимке с экрана, проверить, воткнут ли он в usb-разъём. Если да, то попробуйте вынуть его и вставить заново, обычно это помогает. Если и это не помогло, то нужно скачивать и устанавливать утилиту Aladdin Hasp Monitor от компании “Аладдин Р.Д.” и проверить, видит ли он ключ.

Если есть купленная программная лицензия, то снова нажимаем на кнопку (синюю надпись) “Получить лицензию”:

и вводим имеющийся пин-код для активации соответствующего числа лицензий.

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

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

Для завершения активации нужно нажать на синюю надпись, фиксирующую привязку.

Если всё было введено верно (обращаем ваше внимание, что номер комплекта должен соответствовать пин-коду, и что по умолчанию вам может вывестись не тот номер комплекта, и его вам нужно будет заменить!), то 1С без конфигурации запустится и появится пустое окно программы.

Важно заметить, что если у вас не один набор лицензий (пин-кодов), то второй набор активируется уже через меню «Сервис-Получение лицензии» системы программ 1С:Предприятие:

На прошлом шаге нам удалось создать пустую информационную базу. Однако, когда вы попытаетесь теперь запустить клиент 1С даже без конфигурации, то неизбежно натолкнётесь на следующий подводный камень – система потребует лицензию на сервер 1С:

Здесь вам нужно будет найти лист с пинкодами, который вам был предоставлен после приобретения сервера.

После этого нажимаем на кнопку, “Получить лицензию”, вводим данные в поля для регистрационного номера продукта (номер комплекта) и пин-кода, далее заполняем все данные лицензиата (владельца лицензии) на следующем экране:

Здесь очень важно перед тем, как продолжить, нажать на кнопку «Сохранить данные», чтобы запомнить заполненную информацию в файле с расширением .lic, который пригодится в случае необходимости повторной активации лицензии, например, если будет произведена модернизация аппаратного обеспечения сервера. Без этой информации, где важен каждый символ, восстановление лицензии будет невозможно через Интернет.

После нажатия на кнопку «Далее», которая активируется после заполнения всех необходимых данных, система вроде как должна запуститься.

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

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

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

Важно заметить, что мы рассматриваем здесь случай, когда сервер MS SQL находится на другой машине и там Microsoft SQL Server Native Client установлен, но  … для работы 1С он требуется там, где установлен сервер 1С, так как он может связываться с сервером MS SQL только через него.

Найти и скачать Microsoft SQL Server Native Client можно на официальном сайте Microsoft. При установке обязательно нужно установить SDK, ибо иначе будут проблемы с национальными настройками (в нашем случае с русским языком).

Отметим, что файл имеет имя sqlncli.msi, входил в состав дистрибутива SQL Server 2012 и с тех пор не обновлялся:

Нам нужен именно он. Причём важным является то, что пакет должен быть 64-битым, иначе система откажется его устанавливать. К сожалению, оба файла скачиваются с одним именем, и их легко перепутать. Как дополнительный ориентир, можете использовать размер. Для 64-битного это 5+ Кбайт, в то время как для 32-битного 3+. Ещё раз подчеркнём, что также важно при установке не забыть поставить птичку напротив SDK.

После того, как вы скачаете и установите соответствующую версию Microsoft SQL Server Native Client, у вас получится создать пустую информационную базу.

При установке сервера 1С в самом сложном варианте, оговоренном в первой статье цикла “Муки сисадмина 1С”, вам придётся преодолеть очень много подводных камней.

Казалось бы, что тут сложного, запустил дистрибутив, выбрал необходимые компоненты, как правило, почти все, кроме конвертера с 1С версии 7.7 и модулей Liberica, и ждёшь окончания установки. Далее устанавливаешь все драйверы защиты, подтверждаешь отсутствие необходимости использования компонент для аппаратных ключей (если таковых нет) и всё. Однако, зачастую при запуске консоли администрирования серверов 1С Предприятия сразу же возникает первый казус:

Документация говорит, что в таком случае нужно выбрать меню Windows: Пуск – Все программы – 1С Предприятие 8 – Дополнительно – 8.х.х.х – Регистрация утилиты администрирования серверов 1С Предприятия.

Заметим, что проще ввести в окне поиска слово “регистр” и увидеть сразу ссылку:

На всякий случай запоминаем, что за утилита кроется за этой ссылкой:

Запускать её нужно от имени администратора, иначе получите сообщение об ошибке. Если всё сделать верно, то выйдет окно, сообщающее о том, что dll зарегистрирована. Теперь сервер 1С запустится и можно приступать к следующему шагу.

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

Казалось бы, что может быть проще, не нужно никакого сисадмина, покупаешь систему, берёшь дистрибутивный пакет и устанавливаешь всё по инструкции. В принципе, так оно и есть, когда речь идёт об однопользовательском варианте.

Чуть сложнее будет при сетевом использовании с количеством пользователей не более 5. В этом случае можно даже обойтись без базы данных, как таковой, а использовать файловый вариант системы. Однако, нужно понимать, что здесь речь идёт об одноранговой локальной сети, то есть все компьютеры должны быть достаточно мощны для того, чтобы переваривать работу нужной версии программы 1С:Предприятие так, как будто бы работа идёт вообще без сервера. При этом на сервер возлагается только задача предоставления в общий сетевой доступ одного файла, и он, этот сервер, собственно говоря, не должен быть выделенным и может быть ровно такой же машиной, как и клиентские компьютеры, и на нём может даже не стоять серверной операционной системы. Отметим также, что этот вариант не стоит использовать, если размер файла с данными превышает превышает 2 ГБ.

В остальных случаях нужно будет использовать серьёзные СУБД, такие как MS SQL Server, IBM DB2, Oracle Database, PostgreSQL или основанные на ней. Но это ещё не всё. Известны законы, гласящие о том, что затраты на аппаратное и программное обеспечение сложной системы, а следовательно и на работу системного администратора, растут экспоненциально, в зависимости от количества её пользователей. Если для того, чтобы нормально работали 25 пользователей достаточно одного более менее мощного сервера, то для работы 50 пользователей потребуется уже самый мощный сервер, который только можно найти в данный момент. А когда мы говорим о работе 50+ пользователей, да и ещё и работающих не только в локальной сети, а и в удалённом терминальном режиме, например по протоколу RDP, то впору говорить о трёх физических серверах: RDP-сервере, SQL-сервере и 1С-сервере. Но и это опять-таки не всё. Иногда приходится иметь два 1С-сервера. Это становится особенно актуальным, когда в работе компании используются разные конфигурации приложений системы «1С:Предприятие», которые имеют разные требования к ядру системы (или, как её называют, платформе). Также в случае необходимости использования веб-клиента, лучше всего поднять ещё и Linux-машину с Apache. И это мы ещё не говорим о вопросах безопасности, которые неизбежно возникают при работе удалённо и которые требуют отдельных специалистов и отдельного рассмотрения.

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