Тонкая настройка ежедневного резервного копирования базы данных 1с средствами sql ver. 2014 (sp3)

Экспертный кейс. Расследование фатального замедления времени расчета себестоимости в 1С:ERP 2

При выполнении нагрузочного тестирования информационной системы на базе 1С:ERP для одного из клиентов с целью оценки возможности миграции системы на PostgreSQL и Astra Linux мы столкнулись с неприемлемым увеличением времени выполнения расчета себестоимости.

Строго говоря, сценарий тестирования закрытия месяца не был выполнен вообще – он не укладывался в таймаут выполнения теста, 24 часа. По прошествии 18 часов всё ещё шло выполнение операции «Распределение затрат и расчет себестоимости». Более 16 часов выполнялся подэтап “Расчет партий и себестоимости. Этап. Расчет себестоимости: РассчитатьСтоимость”. Всё это время выполнялся запрос, который в текущей инфраструктуре клиента (СУБД MS SQL Server) выполняется чуть более 3 минут на аналогичных данных.

Excluding Development Servers from SQL Monitoring

The requirement was to prevent specific servers from being monitored by the SQL Server management pack. These were development servers where the DBAs weren’t concerned in what was going on in terms of SQL Server.

Given there was a requirement to monitor the OS and other areas, its not as easy as to just exclude these servers from monitoring by removing the agent (and using a TCP port monitor to notify if the server was up or down). Solving this challenge required diving into how the SQL Server management pack determines what systems to monitor and how to exclude specific systems. Here’s what you can do:

Create a Group to Exclude

Start by creating a group for excluded development servers. Call this group Development SQL Servers (store it in a custom management pack other than Default). The criteria used to add members to the group can be on naming standards for development database servers. Add members to this group as shown in these two screenshots:

Exclude the Group from Discoveries

Exclude this group from discoveries using an override.

Find the discovery under

Authoring -> Management Pack Objects -> Object Discoveries –> Discover SQL 2005 Database Engines (Windows Server)

Right-click, select Properties, select the Overrides tab, and select Override to create an override For a group.

Now select the new group name you just created from the list.

Override the Enabled setting, setting it to false, then save your changes to the management pack you created earlier.

Perform the same action for the Discover SQL 2000 Database Engines (Windows Server) and for the Discover SQL 2008 Database Engines (Windows Server) discoveries.

Exclude the Group from the SQL Computers Group

The next step is to exclude the group from the SQL Computers group. Perform the following steps:

Find the group under Authoring –> Groups -> SQL Computers. Right click, and select Properties.

Select Overrides and create an override For a group. Choose the new group name from the list. Now, override the Enabled setting and set it to false, and save your changes to a non-default management pack.

Check Discoveries

In the Monitoring space node under Discovered Inventory, choose the Change Target Type option from the Actions pane. Set the Discovered Inventory to show SQL DB Engine. Find the number of discovered SQL DB Engines that are part of the group you created.

Do this for each of the SQL DB engines:

In the monitoring space under Discovered Inventory, choose the Change Target Type option from the Actions pane and set the Discovered Inventory to show SQL 2000 DB Engine. Find the number of discovered SQL 2000 DB that are part of the group you created.
In the monitoring space under Discovered Inventory, choose the Change Target Type option from the Actions pane and set the Discovered Inventory to show SQL 2005 DB Engine. Find the number of discovered SQL 2005 DB Engines that are part of the group you created.
In the monitoring space under Discovered Inventory, choose the Change Target Type option from the Actions pane and set the Discovered Inventory to show SQL 2008 DB Engine. Find the number of discovered SQL 2008 DB Engines that are part of the group you created.

Remove the Disabled Monitoring Objects

Run the following PowerShell command (without parameters)

Remove-DisabledMonitoringObject cmdlet

Now re–check each of the discoveries to verify that the excluded systems are no longer in any of these discoveries. You will also want to verify under Monitoring -> Microsoft SQL Server -> Computers that the excluded systems are no longer listed.

Summary

To summarize, if you want to remove your development SQL servers from being monitored by the SQL MP, try this:

Create a group with the systems to no longer monitor with the SQL MP.
Exclude the group from the relevant discoveries and computer group.
Remove the disabled objects.
Verify that the systems excluded are no longer monitored by the SQL MP.

Additional reference information

The following items may be helpful:

http://blogs.technet.com/jonathanalmquist/archive/2008/09/14/remove-disabledmonitoringobject.aspx
http://social.technet.microsoft.com/Forums/en-US/operationsmanagermgmtpacks/thread/226be1d4-ef44-4216-975b-7b9b202540c9

Права на импорт компьютера для OSD

27.10.2009

Задача:

Дать минимальные права сотрудникам, чтобы они могли импортировать новые компьютеры для OSD (OS Deployment) в определённую коллекцию.

Н-р коллекция «Computer Managment -> Collections -> Windows 7 Deployment». на которую назначена установка соответствующей операционной системы.

Решение:

1. В свойствах сайта (в консоли — Site Database (%COD% — %SERVER%, %NAME% -> Site Management -> %COD% — %NAME%, правой кнопкой мыши — > Свойства))

2. Перейти во вкладку Security

3. В секции instance security rights нажать кнопку Add

4. Ввести имя группы (или пользователя) и выбрать право “Import computer entry” (также автоматически будет отмечено право Read)

5а. Если у вас SCCM 2007 SP1 и ниже, вам надо дать права этой же группе:

- Read на Computer Managment –> Collections (т.е. данная группа будет видеть все компьютеры во всех коллекциях)
- Modify на Computer Managment -> Collections -> Windows 7 Deployment

5б. Если у вас SCCM 2007 SP2 и выше, вам надо дать права этой же группе:

Read и Modify на Computer Managment -> Collections -> Windows 7 Deployment

PS Есть ли у вас R2 или R3 – не важно, главное версия SP

Базовые параметры, эталон, монитор

Давайте начнем с определения нескольких терминов. Базовые параметры (baseline) — это набор параметров, отображающих поведение сервера и приложения в обычных условиях. Базовые параметры получены как средние по результатам нескольких замеров, выполненных в одинаковых условиях; они являются ориентирами для сравнения.

Эталон (Benchmark) показывает производительность системы при определенном уровне загрузки сервера, что позволяет сравнить производительность промышленного сервера при таком уровне и определить показатели сервера, насколько они выше или ниже нормы (т.е. когда сервер работает плохо). Как и у базовых параметров, значения эталонов снимаются в контролируемом окружении, ключевые значения определяются в отношении предопределенных показателей. Если нужно посмотреть, как ведет себя сервер и приложение на нескольких уровнях или типах загрузки, то обычно получают несколько эталонных значений (по отношению к базовым параметрам)

Мониторинг (Monitoring) — это плановое наблюдение в режиме реального времени за сервером на предопределенных условиях (совокупностях условий, определенных для дальнейшего исследования или предупреждений)

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

Теперь займемся упреждающим мониторингом. Можно использовать продукты третьих фирм или бесплатное решение, которое задействует System Monitor. Решения третьих фирм могут упростить процесс наладки упреждающего мониторинга и иметь функции, отличные от тех, которые может обеспечить бесплатное встроенное решение. Но прежде чем начать, я покажу, как приступить к выполнению упреждающего мониторинга при помощи System Monitor.

Автоматическое удаление спящих сеансов на сервере 1С

При нештатном завершении клиентской части программы 1С (конфигурации), а также если клиент долгое время не активен, то сеанс на сервере переходит в спящий режим. Далее он должен завершиться через указанное в настройках информационной базы количество времени.
Но, к сожалению, это не так. Я столкнулся с проблемой, когда спящие сеансы никогда не завершаются. Настраивал засыпание пассивных сеансов через 600 секунд, а их завершение через 900 секунд. Несмотря на это спящие сеансы висят часами. Это побудило к написанию программы, которая запускается по расписанию планировщиком Windows и удаляет спящие сеансы на всех указанных администратором серверах 1С.

1 стартмани

Шаг 1. Установка сервера MS SQL

При установке SQL-сервера для работы с 1С достаточно следующих включенных компонентов (более подробно о компонентах Microsoft SQL , об установке серера ):

На данном изображении:
— Integration services — не обязательный элемент — необходим для управления пакетами SSIS (планами обслуживания (экспорт/импорт)), потом его можно будет отключить
— Database Servises — собственно сам сервер СУБД
— Client Component — Managment Tools — утилита управления

Остальные настройки при установке по Вашему вкусу. Единственный нюанс — необходимо правильно установить способ сортировки 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). Решение этой проблемы описано .

Взаимодействие с другими правилами брандмауэра

Настройка брандмауэра Windows производится на основе правил и групп правил. Каждое правило или группа правил связывается с определенной программой или службой, которая может изменять или удалять это правило без вашего ведома. Например, группы правил Службы Интернета (HTTP) и Защищенные службы Интернета (HTTPS) связаны со службами IIS. При включении этих правил будут открыты порты 80 и 443 и разрешены функции SQL Server , зависящие от этих портов. Однако администратор в процессе настройки служб IIS может изменить или отключить эти правила. Если вы используете для SQL Server порт 80 или 443, создайте собственное правило или группу правил для поддержки необходимой конфигурации портов независимо от других правил IIS.

разрешает любой трафик, соответствующий любому применимому правилу разрешения. Таким образом, если существуют два правила для порта 80 (с разными параметрами), то будет пропускаться трафик, соответствующий любому из них. Например, если одно правило разрешает трафик по порту 80 из локальной подсети, а другое разрешает трафик с любого адреса, то в итоге на порту 80 будет разрешен любой трафик независимо от источника. Чтобы обеспечить эффективное управление доступом к SQL Server, администратор должен периодически проверять все правила брандмауэра, разрешенные на сервере.

Особые рекомендации для порта 135

При использовании RPC с транспортным протоколом TCP/IP или UDP/IP входящие порты динамически назначаются системным службам по мере надобности. Используются порты TCP/IP и UDP/IP с номерами выше 1024. Эти порты называются «случайными RPC-портами». В этом случае RPC-клиент определяет порт, назначенный серверу, через сопоставитель конечных точек RPC. Для некоторых служб, работающих через протокол RPC, можно настроить использование определенного фиксированного порта. Можно также ограничить диапазон портов, динамически назначаемых RPC и не зависящих от службы. Поскольку порт 135 используется для многих служб, он часто подвергается атакам злоумышленников. В случае открытия порта 135 рекомендуется ограничить область действия правила брандмауэра.

Дополнительные сведения о порте 135 см. в следующих ресурсах.

Общие сведения о службе и требования к сетевым портам в системе Windows Server
Удаленный вызов процедур (RPC)
Настройка динамического выделения портов RPC для работы с брандмауэром

Реиндексация таблиц базы данных

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

sp_msforeachtable N’DBCC DBREINDEX (»?»)’

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

После выполнения реиндексации нет необходимости делать дефрагментацию индексов.

Настройка реиндексации таблиц (MS SQL 2005)

В ранее созданном плане обслуживания создайте новый субплан с именем «Реиндексация». Добавьте в него задачу Rebuild Index Task:

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

Настройте задачу, указав базу данных (или несколько баз данных) и выбрав необходимые таблицы. Если точно неизвестно, какие таблицы следует указать, то устанавливайте значение All.

Ошибка при создании Service Level Tracking

08.07.2009

При попытке создать объект Service Level Tracking в OpsMgr R2 вы можете получить “информативную” ошибку после нажатия кнопки Finish:

The client has been disconnected from the server. Please call ManagementGroup.Reconnect() to reestablish the connection

Такая ошибка может появится в том случае, если в одном из SLO стоит не целое значение в поле Goal, н-р 99,999%. Несмотря на наличие 3х знаков после запятой, допускается использовать только целые значения.

Временное решение: для учетной записи OpsMgr SDK Config изменить локаль на Английскую (США) или просто сделать разделителем целой и дробной части точку (.) В этом случае SLO сохраняется корректно. Очередной «превед» программистам.

ЗЫ. Алексей, всё-таки я считаю это просто пренебрежением к конечному пользователю. Такие ошибки есть ни что иное, как расхлябанность.

Шаг 4. Настройка Планов обслуживания (Maintenance Plans, Регламентных заданий)

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

Итак, приведу свой пример настроенного Maintenance Plans с комментариями. Мой план состоит из 5 подпланов:

Первый подплан (ежедневное еженочное обслуживание сервера и резервных копий):

Данный подплан состоит из нескольких шагов. Связи зеленого цвета задают переход к следующему заданию при удачном завершении (т.е. без ошибок), связи синего цвета задают переход к следующему заданию при любом результате выполнения текущего. Параметры шагов видны на размещенных в редакторе заданиях. Параметры некоторых заданий нужно описать отдельно. Первым шагом выполняется «Проверка целостности базы данных» (Check Database Integrity Task), которая выполняется для всех баз системы и следующие задания выполняются только при отсутствии ошибок при проверке баз. Следующим шагом выполняется «Перестроение индексов баз данных» (Rebuild Index Task) для всех баз данных сервера. Данная процедура довольно ресурсоемкая, но в последствии ускоряет работу базы, т.к. если фрагментированость индексов > 25%, это резко снижает производительность сервера. Если размер баз не позволяет выполнять данную задачу, т.к. она занимает много времени, то рекомендуется делать данное действие хотябы раз в неделю, при этом, на ночные задания заменить задачу Перестроение индексов баз данных (Rebuild Index Task) на Дефрагментацию индекса (Reorganize Index Task), которая менее ресурсоемка. Далее происходит «Обновление статистики базы данных» (Update Statistics Task) для всех баз данных, опять же для оптимизации. После этого задания рекомендуется выполнить «Очистку процедурного кэша»:

При этом, запускается процедура

DBCC FREEPROCCACHE

После оптимизации работы желательно сделать резервную копию журналов транзакций. Этот шаг делать не обязательно, но желательно. Во время выполнения предыдущих шагов (Перестроение индексов баз данных (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 задания: очистка резервных копий журналов транзакция (о создании таких копий — ниже) старее 5 дней, очистка полных бэкапов старее 1 недели и очистка истории старше 1 месяца (сюда входит в основном — очистка служебной информации MS SQL, такой как журналы):

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

Второй, третий, четвертый подплан (обновление статистики 3 раза в день):

Следующие 3 подплана одинаковы по содержимому и различаются лишь временем выполнения. Выполняются 3 раза в день — в 6, 13 и 19 часов:

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

Пятый подплан (резервное копирование журнала транзакций):

Данный план выполняет инкрементальное копирование транзакционного лога Microsoft SQL Server:

Копирование выполняется каждые пол часа в рабочее время и сохраняется в сеть с расширением trn:

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

Более подробно о выборе и планировании плана обслуживания можно посмотреть данный подкаст(временно убран по причине заражения сайта s.rpod.ru):

Дефрагментация индексов

При интенсивной работе с таблицами базы данных возникает эффект фрагментации индексов, который может привести к снижению эффективности работы запросов.

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

sp_msforeachtable N’DBCC INDEXDEFRAG (<имя базы данных>, »?»)’

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

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

Важно! Начиная с версии платформы 8.3.22 необходимо выполнять дефрагментацию индексов по следующему алгоритму:

До дефрагментации индекса необходимо включить страничные блокировки. Пример команды: ALTER INDEX index_name ON table_name SET (ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON);
Выполнить дефрагментацию.
Обратно выключить страничные блокировки. Пример команды: ALTER INDEX index_name ON table_name SET (ALLOW_PAGE_LOCKS = OFF, ALLOW_ROW_LOCKS = ON);

Настройка дефрагментации индексов (MS SQL 2005)

В ранее созданном плане обслуживания создайте новый субплан с именем «Дефрагментация индексов».Добавьте в него задачу Reorganize Index Task:

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

Шаг 5. Траблешуттинг

Периодически необходимо анализировать фрагментированность индекса для снижения нагрузки. Для больших баз данных нужно уменьшать ненужные операции по дефрагментации тех индексов, для которых это не требуется. То есть дефрагментацию выполнять не для всей базы, а для избранных таблиц, например. Если значение avg_fragmentation_in_percent в этом столбце превышает 25%, то для восстановления исходных параметров производительности рекомендуется выполнить дефрагментацию/реиндексацию этого индекса. Чтобы просмотреть текущую фрагментированность, можно воспользоваться отчетом:

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

Выбор подходящего средства

Определив цели мониторинга, следует выбрать соответствующие средства для этого типа мониторинга: В состав SQL Server и операционной системы Windows входит полный набор средств мониторинга серверов в средах с большим количеством транзакций. Эти средства подробно описывают состояние экземпляра компонента SQL Server Database Engine или экземпляра служб SQL Server Analysis Services.

Windows предоставляет следующие средства мониторинга приложений, запущенных на сервере.

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

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

SQL Server предоставляет следующие средства мониторинга компонентов SQL Server:

Расширенные события
Трассировка SQL
Приложение SQL Server Profiler
Программа распределенного воспроизведения
Монитор активности
SQL Server Management Studio Графическое отображение инструкции Showplan
Системные хранимые процедуры
Консольные команды базы данных (DBCC)
Динамические административные представления и функции
Функции
Флаги трассировки

Важно!

Трассировка SQL и Приложение SQL Server Profiler являются устаревшими. Пространство имен Microsoft.SqlServer.Management.Trace, которое содержит объекты трассировки Microsoft SQL Server и Replay, также устаревшее.

В будущей версии Microsoft SQL Server этот компонент будет удален. Избегайте использования этого компонента в новых разработках и запланируйте изменение существующих приложений, в которых он применяется.

Вместо этого используйте расширенные события. Дополнительные сведения о расширенных событиях см. в разделе Быстрое начало. Расширенные события в SQL Server и SSMS XEvent Profiler.

Примечание

Приложение SQL Server Profiler для рабочей нагрузки служб Analysis Services не устарел и будет по-прежнему поддерживаться.

Дополнительные сведения о средствах наблюдения SQL Server см. в статье Средства контроля и настройки производительности.

Автоматическое отключение пользователя из системы 1С:Предприятие в случае, когда пользователь не работает в запущенном сеансе

Доработка сделана через расширение, платформа 8.3.12.1529 (8.3.11.2867), работает на конфигурациях 1С: ЗУП, БП, КА, ERP и т.д. в общем на всех основных конфигурациях 1С: Предприятие.
Часто бывает, что в организации пользователь с утра запускает 1С и уходит на весь день по своим делам, а лицензия израсходована. Для оптимизации использования лицензий на предприятии и сделана данная доработка. Доработка позволяет в автоматическом режиме выбрасывать пользователей из системы 1С если пользователь не работает в системе. По умолчанию проверка активности пользователя происходит через 2 часа после запуска системы, но данный параметр можно настраивать отдельно для каждого пользователя. Если пользователь не активен его сессия закрывается.
Расширение работает как в клиент — серверном так и в файловом варианте работы 1С

1 стартмани

Обновления MP для AD и Exchange 2007

15.10.2009

Последние несколько дней получились жаркими для администраторов opsMgr. Вышли сразу несколько крупных обновлений, не последними в этом списке стоят MP для Active Directory и для Exchange /

Основным (и собственно единственным) нововведением в MP для Active Directory является полная поддержка Windows Server 2008 R2 и Windows 7:

Support for monitoring Windows Server 2008 R2 server operating systems as well as Windows 7 client operating systems
Support for monitoring the Active Directory Web Service (ADWS) in Windows Server 2008 R2 as well as the Active Directory Management Gateway Service in Windows Server 2008 and Windows Server 2003

В MP для Exchange 2007 исправлены некоторые ошибки.

Добавлено
Собственно, не обошлось без правила «исправили старые баги и добавили чуть-чуть новых». В MP для Active Directory присутствует баг:
Правило «AD Processor Overload (lsass) Monitor» с Target «Active Directory Domain Controller Server 2003 Computer Role» выполняет скрипт AD_LSASS_CPU.vbs
Скрипт пытается выполинть код:

Однако свойство NumberOfCores под Windows 2003 не поддерживается

Временное решение — отключить этот монитор.

Спасибо Александру за то, что обратил внимание на этот баг.

Добавлено 16.10.2009
На 12:00 ссылка на закачку MP для Active Directory убрана из каталога и с сайта download.microsoft.com

Добавлено 05.11.2009
MP для Active Directory за версией 6.0.7065.0 вновь добавлен в каталог
http://www.microsoft.com/downloads/details.aspx?FamilyId=008F58A6-DC67-4E59-95C6-D7C7C34A1447&displaylang=en&displaylang=en

Ошибка со скриптом исправлена

Обновления кросс-платформенных компонентов в OpsMgr 2007 R2

15.10.2009

Вышел хот-фикс KB973583 для Operations Manager 2007 R2 Cross Platform. Основные изменения:

Маленький хинт. Уставнока состоит из 2х частей — сначала запускается скачаный MSI-пакет, который разархивирует MSP-пакет и инсталятор (причем последние два — x86, соответственно скопируются в папку C:\Program Files (x86)) и запускает установку собственно апдейта.

Так вот если вы запустите MSI-пакет в Windows Server 2008 с включенным UAC без повышения привелегий, то апдейт разархивируется, но не запуститься. При попытке запустить руками «C:\Program Files (x86)\System Center 2007 Hotfix Utility\SetupUpdateOM.exe» вы получите ошибку: «Software update failled, either patch file is not provided ot it does not exists».

Решение: запускать cmd с повышенными привелегиями (пунтк Run as administrator…) и уже из командной строки запустить SystemCenterOperationsManager2007-R2-KB973583-X64-ENU.MSI. Об этом честно написано в Readme, но увидите вы его только после запуска MSI-пакета

Ссылка на апдейт: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=4a41a8be-0a37-4bd2-b5b1-026468b317fb

Статистики ожиданий

В этом запросе исключены незначимые типы ожиданий:

SELECT TOP 10
        wait_type ,
        max_wait_time_ms wait_time_ms ,
        signal_wait_time_ms ,
        wait_time_ms - signal_wait_time_ms AS resource_wait_time_ms ,
        100.0 * wait_time_ms / SUM(wait_time_ms) OVER ( )
                                    AS percent_total_waits ,
        100.0 * signal_wait_time_ms / SUM(signal_wait_time_ms) OVER ( )
                                    AS percent_total_signal_waits ,
        100.0 * ( wait_time_ms - signal_wait_time_ms )
        / SUM(wait_time_ms) OVER ( ) AS percent_total_resource_waits
FROM    sys.dm_os_wait_stats 
WHERE   wait_time_ms > 0 -- уберем нулевые задержки 
        AND wait_type NOT IN 
( 'SLEEP_TASK', 'BROKER_TASK_STOP', 'BROKER_TO_FLUSH',
  'SQLTRACE_BUFFER_FLUSH','CLR_AUTO_EVENT', 'CLR_MANUAL_EVENT',
  'LAZYWRITER_SLEEP', 'SLEEP_SYSTEMTASK', 'SLEEP_BPOOL_FLUSH',
  'BROKER_EVENTHANDLER', 'XE_DISPATCHER_WAIT', 'FT_IFTSHC_MUTEX',
  'CHECKPOINT_QUEUE', 'FT_IFTS_SCHEDULER_IDLE_WAIT',
  'BROKER_TRANSMITTER', 'FT_IFTSHC_MUTEX', 'KSOURCE_WAKEUP',
  'LAZYWRITER_SLEEP', 'LOGMGR_QUEUE', 'ONDEMAND_TASK_QUEUE',
  'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'BAD_PAGE_PROCESS',
  'DBMIRROR_EVENTS_QUEUE', 'BROKER_RECEIVE_WAITFOR',
  'PREEMPTIVE_OS_GETPROCADDRESS', 'PREEMPTIVE_OS_AUTHENTICATIONOPS',
  'WAITFOR', 'DISPATCHER_QUEUE_SEMAPHORE', 'XE_DISPATCHER_JOIN',
  'RESOURCE_QUEUE' )
ORDER BY wait_time_ms DESC

Пример результата:

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

Очистка статистик ожидания:

DBCC SQLPERF(waitstats, CLEAR)
GO