Установка и обновление «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.