Установка и обновление «1С Предприятие v8″ с помощью групповых политик (GPO)

17.04.2009 автора kvazar

При установке или обновлении программы 1С Предприятие многие администраторы сталкиваются с невозможностью корректного выполнения этих заданий с помощью групповых политик. Наиболее распространена ошибка 1720:
Product: 1C:Enterprise 8.1 — Error 1720.There is a problem with this Windows Installer package. A script required for this install to complete could not be run. Contact your support personnel or package vendor. Custom action customDetectPrevVersion script error -2147467259, Msi API Error: ProductInfo,Product,Attribute Line 7, Column 5
Данная ошибка вызвана некорректной работой механизма обновления программы, то есть мы не можем выполнить установку свежего билда поверх установленной предыдущей версии.
Для выполнения обновления необходимо вручную отредактировать установочный файл msi до создания групповой политики. Для этого мы используем бесплатный инструмент компании Microsoft для редактирования файлов msi под названием Orca. Эта утилита входит в состав  Microsoft Windows Software Development Kit (SDK), а такжe её можно скачать отдельно здесь.
Итак:

1. Скачиваем и устанавливаем Orca;
2. Открываем программой файл 1CEnterprise 8.1.msi
3. Находим раздел «CustomAction» и в нем параметр «customDetectPrevVersion«. Удаляем этот параметр, сохраняем изменения;
4. Копируем в общедоступную сетевую папку дистрибутив, который установлен на текущий момент (если мы обновляем билд) и новую версию 1С с измененным нами файлом msi. Копируем, естественно, в разные папки

Теперь нам необходимо создать групповую политику и создать в разделе «Установка программм» два пакета установки – старой (например 8.1.11)и новой (8.1.13) версий (рис.2).

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

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

Лучшие методы: оптимизация индексов в SQL Server 2005

Stefano Demiliani (оригинал: Best practice when optimizing indexes on SQL Server 2005)
Перевод Моисеенко С.И.

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

Я вижу каждый день, как многие администраторы баз данных планируют оптимизацию индексов посредством написанных скриптов T-SQL или через стандартный SQL Maintenance Plan, но они не подозревают, что фактически сам SQL Server 2005 позволяет Вам "настраивать" этот процесс.

SQL Server 2005 предлагает опцию (ONLINE = ON or OFF), чтобы помочь настроить производительность и требования параллелизма при создании или перестройке индекса. С новой возможностью Online Indexing (ONLINE=ON) Вы можете продолжать выполнять запросы и операции с таблицей, индекс которой перестраивается, в то время как автономная индексация (ONLINE=OFF) блокирует таблицу.

Важно помнить: онлайновое создание или перестройка индекса (ONLINE=ON), обеспечивая максимальный параллелизм, потребляет больше ресурсов и требует больше времени на выполнение!!

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

Когда опция SORT_IN_TEMP оператора CREATE INDEX или ALTER INDEX установлена в значение OFF (принимается по умолчанию), для временного хранилища используется пользовательская база данных. Когда опция SORT_IN_TEMP включена (ON), временное хранилище будет находиться в базе данных TEMPDB.

Вот рекомендации для лучшей стратегии создания/перестройки индекса (непосредственно от Microsoft). Я рекомендую распечатать ее:

Убедитесь, что TEMPDB находится на дисковой подсистеме, которая обеспечивает достаточную пропускную способность ввода/вывода, и что TEMPDB является достаточно большой, чтобы предоставить временное пространство, которое потребуется для операции создания или восстановления индекса. По умолчанию TEMPDB создается в каталоге Data в папке, куда установлен SQL Server (например, C:\SQL2005\MSSQL.1\MSSQL\Data). При такой конфигурации в TEMPDB может не оказаться достаточно места для обеспечения адекватной пропускной способности ввода/вывода. Поэтому лучшим методом является перемещение TEMPDB на носитель с достаточным количеством свободного пространства и производительностью после установки SQL Server. Кроме того, имейте в виду, что база данных TEMPDB - это общий ресурс для всего экземпляра SQL Server. Вам следует учитывать активность всех пользовательских баз данных, которые могут использовать TEMPDB, при планировании действий с TEMPDB.

Чтобы достичь наименьшего времени на создание или перестройку индекса, используйте автономный режим (ONLINE=OFF). Однако это предотвращает любой доступ пользователей к данной таблице на все время создания или перестройки индекса.

Чтобы достичь наименьшего влияния на доступ пользователей к таблице, используйте опцию онлайн (ONLINE=ON). Однако такая операция онлайн занимает больше времени и использует большее пространство в TEMPDB по сравнению с автономной операцией.

Чтобы использовать наименьший объем памяти в TEMPDB во время перестройки кластерного индекса, используйте автономный вариант (ONLINE=OFF). Однако это повлияет на параллелизм, поскольку доступ к таблице предотвращается на все время перестройки индекса.

Чтобы использовать наименьшее количество памяти в TEMPDB во время перестройки некластерного индекса, используйте онлайновый режим (ONLINE=ON). Онлайновая перестройка также обеспечивает лучший параллелизм, но потребует большего времени на выполнение.

Если для таблицы имеются транзакции, которые выполняются параллельно с онлайновым созданием или перестройкой индекса, Вы должны планировать дополнительное место в TEMPDB для хранения версий.

Включение режима AWE на SQL Server 2005

По умолчанию, сразу после установки, этот режим не включен.
Целесообразно включение данного режима, если у вас операционка 32-х битная и оперативной памяти на сервере более 4 Гб. В моем случае это MS Server 2003 Enterprise и 8Гб ОЗУ.
При этом, сервер выполняет роль одновременно и сервера баз данных (MS SQL 2005), и сервера приложений (1C Предприятие 8.1, 4 рабочих процесса).
Методика следующая:
- редактируем boot.ini - в строке загрузки добавляем опцию /PAE
- меняем в Properties SQL Server настройки минимум и максимум используемой памяти. В моем случае это 1Гб и 4Гб соответственно. Цифры мин и макс расчитаны с помощью методики, любезно предложенной г-ном Вячеславом Гилевым (http://gilev.blogspot.com)
- перезапускаем службу, в running values SQL Server видим, что значения мин и макс изменились
- включаем AWE
- перезапускаем сервер (reboot, а не просто перезапуск службы)
Примерно так.
Далее наблюдаем следующее:
- в диспетчере задач процесс sqlsrvr занимает намного меньше памяти, чем до включения AWE (в моем случае - 200Мб против 1,7Гб до того)
- с помощью Performance Monitor, значения из группы SQL Memory manager, счетчики Target Server Memory и  Total Server Memory отражают реальную картину: сколько памяти выделено и используется SQL-сервером.
Вместе с тем наблюдаю эффект увеличения размера свап-файла MS Server 2003. Вероятно, этот эффект как-то связан c использованием AWE.

Оперативный бэкап средствами SQL 2005 (продолжение)

Коллеги, требуется внести небольшую ремарку к пункту 1.2

"1.2. Непосредственно подключение логического диска (T-SQL):




EXEC xp_cmdshell 'net use N: \\SRV-nas\1c_backup'

GO"

Дело в том, что описываемую команду нужно выполнять каждый раз после рестарта сервера или службы SQL Server. Иначе SQL "забывает", куда именно нужно складывать наши бэкапы и, как следствие, выдает ошибку при выполнении Maintenance Plan.

Оперативный бэкап средствами SQL 2005

Пошаговая инструкция по настройке оперативного бэкапа SQL 2005 и Maintenance Plan, как примапить сетевой диск из SQL. Процедура восстановления после сбоя.


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

Имеется: рабочий сервер БД с СУБД SQL 2005 (9.0), с несколькими БД 1C 8;

1 раз в сутки выполняется резервное копирование полного бэкапа на ленту;



Задача:

Обеспечить оперативное резервное копирование в течение дня, а именно:

- иметь полную копию на начало дня , хранится 1 сутки, затем перезаписывается;

- иметь копии Transaction Log (TL) через каждые 20 минут;

- актуальность копий Transaction Log 1 сутки, по прошествии - должны удаляться;

- оперативные бэкапы хранятся на сетевом диске (NAS);



Решение:

Необходимое условие: пользователь, под которым запускается SQL Server agent (ну и SQL Server, на всякий случай), должен иметь права на сетевой ресурс NAS сервера, куда будут складываться бэкапы. Кроме того, Recovery Model базы, которую планируется бэкапить должна быть Full.

1. Обеспечить возможность поключения SQL сервера к сетевому диску N:.

1.1. Предварительная операция, требуется для включения расширенных опций SQL 2005 (Т-SQL):



-- To allow advanced options to be changed.

EXEC sp_configure 'show advanced options', 1

GO

-- To update the currently configured value for advanced options.

RECONFIGURE

GO

-- To enable the feature.

EXEC sp_configure 'xp_cmdshell', 1

GO

-- To update the currently configured value for this feature.

RECONFIGURE

GO



1.2. Непосредственно подключение логического диска (T-SQL):



EXEC xp_cmdshell 'net use N: \\SRV-nas\1c_backup'

GO



2. Настраиваем Maintenance Plan (MP) из 2-х подпланов:

- subplan_1 - полный бэкап по расписанию;

- subplan_2 - бэкап Transaction log и удаление бэкапов Transaction log с датой ранее 1 дня, по расписанию ;

2.1. Полный бэкап (Full) будет перезаписываться поверх предыдущего, поэтому создаем Backup Device на сетевом диске (T-SQL)*:



USE master

EXEC sp_addumpdevice 'disk', 'FULLBAK', '\\SRV-nas\1c_backup\FullBak.bak'

GO

Таким образом, в Server Objects\Backup device появляется новое устройство FULLBAK.

2.2. Запускаем мастер Мaintenance Рlan Wizard.

2.3. Указываем Separate shedules for each task (отдельные расписания для каждой задачи)

2.4. В задачах выбираем: – Back up Database (FULL); - Back up Database (Transaction Log),

т.о. получаем 2 подплана;

2.5.Настраиваем subplan_1: выбираем базы для копирования, выбираем Back up databases across one or more files, кнопкой ADD выбираем подключенное устройство FULLBAK, в If backup files exist выбираем “owerwrite”, настраиваем расписание для выполнения задачи Shedule кнопкой change - выполнение каждый день в определенное время (в моем случае до начала рабочего дня, в 7:00).

2.6. Настраиваем subplan_2:

- выбираем базы для копирования;

- выбираем create a backup file for every database

- указываем путь к папке на диске N:, куда будут складываться бэкапы TL;

- настраиваем расписание Shedule - каждые двадцать минут в интервале, например, с 07:20 до 23:00;

2.7. Сохраняем, открываем на редактирование (Modify в дереве Management\Maintenance plans) наш сохраненный Maintenance Plan.

2.8. В subplan_2 drag-and-drop мышью добавляем из Toolbox задачу Maintenance Cleanup Task.

2.9. Щелкаем Edit по этой задаче, в пункте Search folder and delete files based on an extension, поле Folder выбираем папку, куда складываются файлы бэкапа Transaction Log. В поле File extension (расширение файлов) ставим trn. В Delete files older than following, согласно задаче, ставим 1 сутки. Соединяем стрелкой обе подзадачи (бэкап и удаление), чтобы они выполнялись по одному расписанию.



3.0. Сохраняем наш Maintenance Plan, он готов к выполнению.



4. Теперь о процедуре восстановления в случае сбоя в течение рабочего дня.

4.1. Сделать вручную выгрузку бэкап Transaction Log, чтобы зафиксировать последние данные на момент сбоя.

4.2. Восстановить утренний Полный бэкап

4.3. Восстановить последовательно все бэкапы Transaction Log, включая сохраненный п. 4.1.

4.4. Т.о. база находится в состоянии "до сбоя".





Источники:

http://www.itcommunity.ru/blogs/rsug/archive/2009/02/27/55814.aspx

http://dev.net.ua/blogs/kosinsky/archive/2009/02/27/7810.aspx

http://msdn.microsoft.com/en-us/library/ms190693.aspx

http://www.sql-server-performance.com/articles/dba/creating_backup_jobs_p1.aspx

http://www.sql.ru/

http://razbezhkin.rpod.ru/all/

http://www.gilev.ru/1c/mssql/backup.htm

и т.д.


* Есть альтернативный вариант, при котором так же, как и для бэкапа Transaction Log, можно обойтись без создания Backup Device , воспользовавшись Create a backup file for every database. Это несколько упростит процедуру, но не расширит ваши знания. )