MS SQL Server

  Все выпуски  

MS SQL Server - дело тонкое...


Информационный Канал Subscribe.Ru

#268<<  #269

СОДЕРЖАНИЕ

1.СТАТЬИ
1.1.Секционированные таблицы и индексы SQL Server 2005 (продолжение)
1.2.Использование статистики оптимизатором запросов Microsoft SQL Server 2005 (продолжение)
1.3.Описание технологии работы Log Shipping SQL Server 2000 (окончание)
1.4.Руководство по работе с Microsoft SQL Server 2000 Analysis Services (продолжение)
2.ССЫЛКИ НА СТАТЬИ
2.1.Англоязычные статьи
3.ФОРУМ SQL.RU
3.1.Самые популярные темы недели
3.2.Вопросы остались без ответа
4.КНИГИ
4.1.Хранилища данных

СТАТЬИ

Секционированные таблицы и индексы SQL Server 2005 (продолжение)

По материалам статьи Kimberly L. Tripp: SQL Server 2005. Partitioned Tables and Indexes
Перевод Алексея Сафонова

Соберем все воедино: конкретные примеры

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

Секционирование диапазона - сведения о продажах

Характер использования сведений о продажах зачастую изменчив. Как правило, данные текущего месяца - это оперативные данные; данные предшествующих месяцев - это в большой степени данные, предназначенные для анализа. Чаще всего анализ производится ежемесячно, ежеквартально, либо ежегодно. Поскольку разным аналитикам могут потребоваться значительные объемы различных аналитических данных одновременно, то секционирование лучше всего позволит изолировать их деятельность. В рассматриваемом далее сценарии данные стекаются из 283 узлов и поставляются в виде двух файлов стандартного формата ASCII. Все файлы отправляются на центральный файл-сервер не позднее 3.00 am первого дня каждого месяца. Размеры файлов колеблются, но в среднем составляют примерно 86.000 заказов в месяц. Каждый заказ в среднем составляет 2.63 позиции, поэтому файлы OrderDetails составляют в среднем по 226180 строк. Каждый месяц добавляется примерно 25 миллионов новых заказов и 64 миллиона строк номенклатуры заказов. Сервер анализа истории поддерживает данные за 2 последних года. Данные за два года - это чуть меньше 600 миллионов заказов и более 1.5 миллиардов строк в таблице OrderDetails. Поскольку данные часто анализируются путем сравнения показателей месяцев одного и того же квартала, либо одних и тех же месяцев за предыдущие годы, то выбрано диапазонное секционирование. В качестве размера диапазона выбран месяц.
На основе схемы 11 ("Шаги по созданию секционированной таблицы") мы решили секционировать таблицу, используя диапазонное секционирование по столбцу OrderDate. Наши аналитики в основном объединяют и анализируют данные последних 6 месяцев, либо последних 3 месяцев текущего и прошлого годов (например, январь-март 2003 плюс январь-март 2004). Чтобы максимально усилить расслоение дисков, а заодно изолировать большинство группировок данных, на одном физическом диске будет располагаться по несколько файловых групп, но они будут смещены на шесть месяцев за тем, чтобы уменьшить количество конфликтов при разделении ресурсов. Текущий месяц - октябрь 2004, и все 283 обособленных офисов управляют своими текущими продажами локально. Сервер хранит данные с октября 2002 по сентябрь 2004 включительно. Для того чтобы воспользоваться преимуществом новой 16-процессорной системы и SAN (Storage Area Network - высокоскоростная сеть, связывающая хранилища данных), данные каждого месяца будут находиться в своем собственном файле файловой группы, и располагаться на наборе чередующихся зеркал (RAID 1+0). Рисунок 12 иллюстрирует размещение данных на логических дисках.


Рисунок 12: Секционированная таблица Orders

Каждый из 12 логических дисков использует конфигурацию RAID 1+0, поэтому общее количество дисков, необходимое для таблиц Orders и OrderDetails, равно 48. Не смотря на это, SAN поддерживает до 78 дисков, так что остальные 30 дисков используются для transaction log, TempDB, системных баз данных и прочих небольших таблиц, таких как Customers (9 миллионов записей) и Products (386 750 записей), и т.д. Таблицы Orders и OrderDetails будут использовать одни и те же граничные условия и одно и то же размещение на диске; фактически, они будут использовать одну и ту же схему секционирования. В результате (взгляните на два логических диска E:\ и F:\ на Рисунке 13) данные таблиц Orders и OrderDetails за одни и те же месяцы будут располагаться на одних и тех же дисках:


Рисунок 13: Размещение экстентов диапазонных секций на дисковых массивах

Хотя это и выглядит запутанным, все это весьма просто реализовать. Самое сложное в создании нашей секционированной таблицы - это доставка данных из большого количества источников - 283 хранилища должны иметь стандартный механизм доставки. Тем не менее, на центральном сервере есть только одна таблица Orders и одна таблица OrderDetails. Чтобы превратить обе таблицы в секционированные, мы должны сначала создать функцию и схему секционирования. Схема секционирования определяет физическое расположение секций на дисках, таким образом, файловые группы также должны существовать. Поскольку для наших таблиц необходимы файловые группы, то следующим шагом является их создание. Синтаксис операторов создания каждой файловой группы идентичен приведенному ниже, тем не менее, данным образом должны быть созданы все двадцать четыре файловые группы. Разберите самостоятельно пример кода на T-SQL, приведенного в приложении RangeCaseStudyFilegroups.sql в качестве полного сценария для создания всех двадцати четырех файловых групп (примечание: Вы не сможете выполнить этот сценарий, не имея соответствующих логических дисков; однако, сценарий включает таблицу "установки", которая может быть изменена для упрощенного тестирования). Вы можете поменять названия/расположения дисков на один-единственный диск, для того чтобы протестировать и изучить синтаксис. Убедитесь, что Вы исправили размеры файла на MB вместо GB, и выбрали меньший начальный размер файлов, исходя из доступного вам дискового пространства. Двадцать четыре файла и файловые группы будут созданы в базе данных SalesDB. Все будут иметь схожий синтаксис, за исключением местоположения, имени файла и имени файловой группы:

ALTER DATABASE SalesDB ADD FILE (NAME = N'SalesDBFG1File1', FILENAME = N'E:\SalesDB\SalesDBFG1File1.ndf', SIZE = 20GB, MAXSIZE = 35GB, FILEGROWTH = 5GB) TO FILEGROUP [FG1] GO

Как только все двадцать четыре файла и файловые группы будут созданы, Вы сможете определить функцию и схему секционирования. Убедиться в том, что ваши файлы и файловые группы созданы, вы можете при помощи системных хранимых процедур sp_helpfile и sp_helpfilegroup.
Функция секции будет определена по столбцу OrderDate с типом данных datetime. Для того чтобы обе таблицы можно было секционировать по столбцу OrderDate, этот столбец должен присутствовать в обеих таблицах. В действительности, значения ключей секционирования обоих таблиц (если обе таблицы будут секционированы по одному и тому же ключу) будут дублировать друг друга; однако это необходимо для получения преимуществ выравнивания, к тому же в большинстве случаев размер ключевых столбцов будет относительно небольшим (размер поля datetime всего 8 байт). Как уже описывалось в Главе "CREATE PARTITION FUNCTION для диапазонных секций", наша функция будет диапазонной функцией секционирования, у которой первое граничное условие будет в первой (LEFT) секции.

CREATE PARTITION FUNCTION TwoYearDateRangePFN(datetime) AS RANGE LEFT FOR VALUES ('20021031 23:59:59.997', -- Oct 2002 '20021130 23:59:59.997', -- Nov 2002 '20021231 23:59:59.997', -- Dec 2002 '20030131 23:59:59.997', -- Jan 2003 '20030228 23:59:59.997', -- Feb 2003 '20030331 23:59:59.997', -- Mar 2003 '20030430 23:59:59.997', -- Apr 2003 '20030531 23:59:59.997', -- May 2003 '20030630 23:59:59.997', -- Jun 2003 '20030731 23:59:59.997', -- Jul 2003 '20030831 23:59:59.997', -- Aug 2003 '20030930 23:59:59.997', -- Sep 2003 '20031031 23:59:59.997', -- Oct 2003 '20031130 23:59:59.997', -- Nov 2003 '20031231 23:59:59.997', -- Dec 2003 '20040131 23:59:59.997', -- Jan 2004 '20040229 23:59:59.997', -- Feb 2004 '20040331 23:59:59.997', -- Mar 2004 '20040430 23:59:59.997', -- Apr 2004 '20040531 23:59:59.997', -- May 2004 '20040630 23:59:59.997', -- Jun 2004 '20040731 23:59:59.997', -- Jul 2004 '20040831 23:59:59.997', -- Aug 2004 '20040930 23:59:59.997') -- Sep 2004 GO

Поскольку и крайне левый, и крайне правый граничные случаи охвачены, эта функция секционирования фактически создает 25 секции. Таблица будет поддерживать 25-ую секцию, которая останется пустой. Для этой пустой секции не требуется никакой специальной файловой группы, поскольку никакие данные не должны когда-либо в нее попасть. Для того чтобы гарантировать, что никакие данные в нее не попадут, constraint ограничит диапазон данных этой таблицы. Для того чтобы направить данные на соответствующие диски используется схема секционирования, отображающая секции на файловые группы. Схема секционирования будет использовать явное определение файловых групп для каждой из 24 файловых групп, содержащих данные, и PRIMARY - для 25-ой пустой секции.

CREATE PARTITION SCHEME [TwoYearDateRangePScheme] AS PARTITION TwoYearDateRangePFN TO ( [FG1], [FG2], [FG3], [FG4], [FG5], [FG6], [FG7], [FG8], [FG9], [FG10],[FG11],[FG12], [FG13],[FG14],[FG15],[FG16],[FG17],[FG18], [FG19],[FG20],[FG21],[FG22],[FG23],[FG24], [PRIMARY] ) GO

Таблица может быть создана с тем же синтаксисом, который поддерживали предыдущие релизы SQL Server - используя предложенную по умолчанию, либо определенную пользователем файловую группу (для создания НЕ секционированной таблицы) - либо используя схему (для создания секционированной таблицы). Что касается того, какой из вариантов предпочтительнее (даже если эта таблица в будущем станет секционированной), то все зависит от того, как таблица будет заполняться и сколькими секциями вы собираетесь манипулировать. Наполнение кучи (heap) и последующее создание в ней кластерного индекса, вероятно, обеспечит лучшую производительность, чем загрузка в таблицу, содержащую кластерный индекс. Кроме того, в мультипроцессорных системах вы можете загружать данные в таблицу параллельно, и затем тоже параллельно строить индексы. В качестве примера создадим таблицу Orders и загрузим в нее данные, используя операторы INSERT … SELECT. Чтобы создать таблицу Orders в качестве секционированной, определите схему секционирования в выражении ON оператора CREATE TABLE.

CREATE TABLE SalesDB.[dbo].[Orders] ( [PurchaseOrderID] [int] NOT NULL, [EmployeeID] [int] NULL, [VendorID] [int] NULL, [TaxAmt] [money] NULL, [Freight] [money] NULL, [SubTotal] [money] NULL, [Status] [tinyint] NOT NULL, [RevisionNumber] [tinyint] NULL, [ModifiedDate] [datetime] NULL, [ShipMethodID] [tinyint] NULL, [ShipDate] [datetime] NOT NULL, [OrderDate] [datetime] NULL CONSTRAINT OrdersRangeYear CHECK ([OrderDate] >= '20021001' AND [OrderDate] < '20041001'), [TotalDue] [money] NULL ) ON TwoYearDateRangePScheme(OrderDate) GO

Поскольку таблица OrderDetails собирается использовать ту же схему, она должна включать в себя столбец OrderDate.

CREATE TABLE [dbo].[OrderDetails]( [OrderID] [int] NOT NULL, [LineNumber] [smallint] NOT NULL, [ProductID] [int] NULL, [UnitPrice] [money] NULL, [OrderQty] [smallint] NULL, [ReceivedQty] [float] NULL, [RejectedQty] [float] NULL, [OrderDate] [datetime] NOT NULL CONSTRAINT OrderDetailsRangeYearCK CHECK ([OrderDate] >= '20021001' AND [OrderDate] < '20041001'), [DueDate] [datetime] NULL, [ModifiedDate] [datetime] NOT NULL CONSTRAINT [OrderDetailsModifiedDateDFLT] DEFAULT (getdate()), [LineTotal] AS (([UnitPrice]*[OrderQty])), [StockedQty] AS (([ReceivedQty]-[RejectedQty])) ) ON TwoYearDateRangePScheme(OrderDate) GO

На следующем шаге в таблицы загружаются данные из новой учебной базы данных AdventureWorks. Убедитесь, что вы установили базу данных AdventureWorks.

INSERT dbo.[Orders] SELECT o.[PurchaseOrderID] , o.[EmployeeID] , o.[VendorID] , o.[TaxAmt] , o.[Freight] , o.[SubTotal] , o.[Status] , o.[RevisionNumber] , o.[ModifiedDate] , o.[ShipMethodID] , o.[ShipDate] , o.[OrderDate] , o.[TotalDue] FROM AdventureWorks.Purchasing.PurchaseOrderHeader AS o WHERE ([OrderDate] >= '20021001' AND [OrderDate] < '20041001') GO INSERT dbo.[OrderDetails] SELECT od.PurchaseOrderID , od.LineNumber , od.ProductID , od.UnitPrice , od.OrderQty , od.ReceivedQty , od.RejectedQty , o.OrderDate , od.DueDate , od.ModifiedDate FROM AdventureWorks.Purchasing.PurchaseOrderDetail AS od JOIN AdventureWorks.Purchasing.PurchaseOrderHeader AS o ON o.PurchaseOrderID = od.PurchaseOrderID WHERE (o.[OrderDate] >= '20021001' AND o.[OrderDate] < '20041001') GO

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

SELECT $partition.TwoYearDateRangePFN(o.OrderDate) AS [Partition Number] , min(o.OrderDate) AS [Min Order Date] , max(o.OrderDate) AS [Max Order Date] , count(*) AS [Rows In Partition] FROM dbo.Orders AS o GROUP BY $partition.TwoYearDateRangePFN(o.OrderDate) ORDER BY [Partition Number] GO SELECT $partition.TwoYearDateRangePFN(od.OrderDate) AS [Partition Number] , min(od.OrderDate) AS [Min Order Date] , max(od.OrderDate) AS [Max Order Date] , count(*) AS [Rows In Partition] FROM dbo.OrderDetails AS od GROUP BY $partition.TwoYearDateRangePFN(od.OrderDate) ORDER BY [Partition Number] GO

И наконец теперь, после того как вы загрузили данные, Вы можете создать кластерный индекс и внешний ключ (Foreign key) между таблицами OrderDetails и Orders. В данном случае кластерный индекс будет построен на первичном ключе (Primary Key) точно так же, как вы идентифицируете обе эти таблицы по их ключу секционирования (для OrderDetails к индексу Вы добавите столбец LineNumber для уникальности). По умолчанию при построении индексов на секционированной таблице происходит их выравнивание по отношению к секционированной таблице согласно той же самой схеме секционирования; явно задавать схему не обязательно.

ALTER TABLE Orders ADD CONSTRAINT OrdersPK PRIMARY KEY CLUSTERED (OrderDate, OrderID) GO ALTER TABLE dbo.OrderDetails ADD CONSTRAINT OrderDetailsPK PRIMARY KEY CLUSTERED (OrderDate, OrderID, LineNumber) GO

Полный синтаксис, определяющий схему секционирования, выглядел бы так:

ALTER TABLE Orders ADD CONSTRAINT OrdersPK PRIMARY KEY CLUSTERED (OrderDate, OrderID) ON TwoYearDateRangePScheme(OrderDate) GO ALTER TABLE dbo.OrderDetails ADD CONSTRAINT OrderDetailsPK PRIMARY KEY CLUSTERED (OrderDate, OrderID, LineNumber) ON TwoYearDateRangePScheme(OrderDate) GO

ПРОДОЛЖЕНИЕ СЛЕДУЕТ

[В начало]

Использование статистики оптимизатором запросов Microsoft SQL Server 2005 (продолжение)

По материалам статьи Eric N. Hanso: Statistics Used by the Query Optimizer in Microsoft SQL Server 2005

Поддержка статистики в SQL Server 2005

После череды операций INSERT, DELETE и/или UPDATE, выполненных с таблицей, статистика уже не будет отражать действительное распределение по затронутому полю или индексу. Если оптимизатору запросов SQL Server потребуется статистика для какого - нибудь поля таблицы, которая была перед этим подвержена значительным модификациям, причём, уже после того, как статистические данные были созданы или обновлены; в таком случае SQL Server автоматически обновит статистику по пробной выборке значений этого поля (как при auto update statistics). Автоматическое обновление статистики будет спровоцировано оптимизацией запроса или компиляцией плана исполнения, и затронет только участвующие в запросе поля. Статистика будет обновлена перед компиляцией запроса, если опция AUTO_UPDATE_STATISTCS_ASYNC принимает значение OFF, а если значение ON, то обновление статистики будет выполнено асинхронно.
Если запрос компилируется первый раз, и оптимизатору нужен соответствующий объект статистики, и при этом этот объект существует, тогда, в случае, если необходимый объект статистики устарел, он будет обновлён. После исполнения запроса и попадания его плана в кэш, его статистика проверяется, чтобы определить, не является ли она устаревшей. Если она устарела, план удаляется из кэша, и во время компиляции запроса статистика будет обновлена. План также удаляется из кэша, если изменяются какие - либо статистические данные, от которых он зависит.
SQL Server 2005 принимает решение по обновлению статистики, основываясь на изменениях в счётчике column modification counters (colmodctrs).
Объекты статистики считаются устаревшими в следующих случаях:

  • Когда статистика собирается для постоянной таблицы, она устаревает если:

    1. Размер таблицы в диапазоне от 0 до > 0 строк.

    2. Число строк в таблице после сбора статистических данных было не более 500, и colmodctr для первого поля объекта статистики изменился с тех пор более чем на 500.

    3. Таблица, в момент сбора статистических данных, имела более 500 строк, и colmodctr первого поля объекта статистики изменился более чем на 500 + 20 % от числа строк в таблице на момент сбора статистических данных.

  • Если объект статистики относится к временной таблице, он будет считаться устаревшим по описанным выше причинам, за исключением того, что вводиться более строгий порог для повторного обновления, равный 6 строкам, вместо 500, как это было указано в пункте 2 предыдущего варианта.

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

  • На уровне базы данных, отключите использование auto update statistics командой:

    ALTER DATABASE dbname SET AUTO_UPDATE_STATISTICS OFF

  • На уровне таблицы, отключить auto update statistics можно используя опцию NORECOMPUTE команды UPDATE STATISTICS или команды CREATE STATISTICS.

  • Используйте sp_autostats, которая показывает изменения установок auto update statistics для таблиц, индексов или объектов статистики.

Повторное включение механизма автоматического обновления статистики может быть сделано подобно тому, как это осуществляется в ALTER DATABASE, UPDATE STATISTICS или sp_autostats.
SQL Server 2005 может автоматически обновлять статистику по всем базам, потаблично, поиндексно или на уровне объектов статистики. Не смотря на то, что можно изменить эту установку с помощью всего одной команды sp_autostats для всей статистики у одной таблицы, поведение статистики будет изменено индивидуально для каждого объекта статистики и индекса этой таблицы. Не существует метаданных, которые бы явно хранили информацию о том, что auto update statistics принимает значение ON или OFF для отдельной таблицы.
В представленной ниже таблице показан суммарный эффект от разных установок для базы данных, таблицы и её индексов на возможности установок для объекта:

Установка для
базы данных

Установка для индекса
или объекта статистики

Auto Update Statistic
на уровне объекта

ON

ON

ON

ON

OFF

OFF

OFF

ON

OFF

OFF

OFF

OFF

Не возможно отменить установленное базе данных для auto update statistics значение OFF, устанавливая его в ON для статистики более низкого уровня объектов.
Автоматическое обновление статистики всегда выполняется по пробной выборке индекса или таблицы, с заданной по умолчанию частотой. Чтобы явно установить эту частоту, выполните команду CREATE или UPDATE STATISTICS.
Обновление статистики регистрируется с помощью тех же сообщений в SQL Profiler, как и при создании статистики.

ПРОДОЛЖЕНИЕ СЛЕДУЕТ

[В начало]

Описание технологии работы Log Shipping SQL Server 2000

Автор: Ирина Наумова

3 Мониторинг передачи журналов (окончание)

После того, как передача журналов настроена, на сервере мониторинга, в папке "Management", появляется новая вкладка "Log Shipping Monitor". Некоторые возможности, доступные с помощью этой утилиты, мы уже рассмотрели в предыдущем разделе.
Помимо того, что уже было сказано, она дает возможность посмотреть историю создания резервных копий, их копирования и восстановления.
Для этого нужно выбрать <Имя сервера мониторинга> -> Management -> Log Shipping Monitor. В окне детализации выбрать нужную пару серверов, участвующий в передаче журналов и из контекстного меню выбрать пункт View Backup History или View Copy / Load history.
При разрешении проблем, необходимо помнить, что Log Shipping создает задания и поэтому необходимо также посмотреть историю выполнения этих заданий для получения дополнительной информации об ошибках. Для этого нужно в Enterprise Manager выбрать <Имя сервера> -> Management -> SQL Server Agent -> Jobs, в окне детализации выбрать нужное задание и из контекстного меню выбрать пункт "View Job History". Появится окно "Job History", в нем необходимо установить флаг "Show step details" и перейти на нужный шаг задания, чтобы в окне детализации увидеть более подробную информацию.

[В начало]

4 Где хранится информация о Log Shipping

Информация о передаче журналов хранится в базе данных msdb в следующих таблицах:

  • log_shipping_databases

  • log_shipping_monitor

  • log_shipping_plan_databases

  • log_shipping_plan_history

  • log_shipping_plans

  • log_shipping_primaries

  • log_shipping_secondaries

Эти таблицы присутствуют на всех серверах, участвующих в передаче журналов. При этом на каждом из серверов данными заполняется только часть таблиц, в зависимости от того, какую функцию выполняет сервер в процессе передачи журналов: является ли он первичным, вторичным или сервером мониторинга.
Также не нужно забывать о том, что поскольку при передаче журналов создаются задания и план обслуживания, то задействуется также еще ряд других таблиц из базы msdb, таких как sysjobs, sysjobssteps и т.д.

[В начало]

5 Синхронизация передачи журналов c репликацией транзакций

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

5.1 Синхронный режим:

    Для перехода в этот режим для базы данных устанавливается опция sync with backup.
    В этом режиме Log Reader Agent не отбирает транзакции для передачи подписчикам до тех пор, пока они не будут помещены в копию журнала транзакций, которые создает Log Shipping.
    Этот метод гарантирует, что в случае отказа основного сервера – издателя, информация на всех серверах, участвующей в репликации и передаче журналов, будет синхронизирована, что упрощает процесс переключения на резервный сервер в случае сбоя.
    Но в то же время замедляется процесс репликации, поскольку он теперь становится зависимым от интервала, с которым Log Shipping выполняет резервные копии журнала.

5.2 Полусинхронный режим:

    Этот режим используется, когда недопустимы задержки в работе репликации. Работа Log Reader Agent уже не зависит от создания резервных копий журнала. При этом резервный сервер также можно ввести в качестве издателя в случае сбоя первичного, несмотря на то, что данные не синхронны.
    Подробнее об этом можно прочитать в следующей статье MSDN: Transactional Replication and Log Shipping

[В начало]

6 Заключение

Для того чтобы процесс передачи журналов функционировал без сбоев, администратору необходимо хорошо обдумывать свои действия и их последствия.
Например, необходимо помнить, что нельзя применять к базе данных, участвующей в передаче журналов, команду "Backup Log" с опцией "No_Log" (Truncate_only), поскольку это приведет к тому, что последовательная цепочка строк (LSN) журнала транзакций будет разорвана и процесс передачи журналов перестанет функционировать. После этого необходимо будет предпринимать некоторые дополнительные по восстановлению передачи журналов.
Нельзя использовать переключения между разными моделями восстановления базы данных, это также может нарушить работу Log Shipping.
Среди положительных особенностей можно отметить, что при определенных условиях вторичный сервер может быть настроен для получения отчетности. Для этого при настройке Log Shipping следует учесть, что база данных на резервном сервере после восстановления должна находиться в состоянии "Read-Only", и также учесть тот факт, что если в настройках передачи журналов выбрана опция "Terminate users in database", то когда начнется восстановление очередной копии журнала соединения пользователей будут отключены и на тот период времени, пока восстановление проходит, пользователи не смогут подключаться к БД. Если же эта опция не выбрана, то восстановление не сможет начаться, если к БД есть подключения и задания будут завершаться с ошибкой до тех пор, пока пользователи не отключатся и процесс восстановления не возобновится.
Также, несомненно - положительной особенностью является и то, что настройка Log Shipping не требует предварительного изменения схемы данных и не вносит изменений в их схему, как например некоторые виды репликации. А также переносятся все пользователи, роли и разрешения для базы данных.
Но следует также отметить, что если необходимо реализовать переход на резервный сервер, а затем снова ввести в работу основной, то этот обратный переход может стать достаточно трудоемкой и продолжительной операцией, если в базу данных вносится много изменений, копии журнала для обратного перехода выполняются часто или период работы с резервным сервером достаточно продолжителен, поскольку накапливается большое количество копий журналов транзакций, которые потом нужно восстановить на основном сервере для ввода его в работу. В некоторых случаях легче сделать полную копию базы данных и восстановить ее на основном сервере, что для больших баз данных также может занимать достаточно продолжительное время. К тому же при использовании стандартной процедуры перехода на резервный сервер, описанной в статье MSDN: How to set up and perform a log shipping role change, после перехода на основной сервер передачу журналов нужно пересоздавать.

[В начало]

7 Статьи MSDN, в которых описывается, как решать некоторые проблемы, возникающие при настройке и работе Log Shipping

Часто повторная настройка Log shipping вызывает ошибку, поскольку остается информация в таблицах от предыдущей настройки. Эта ошибка и методы ее устранения описаны в статье MSDN:

Разрешение причин возникновения ошибок в работе заданий Log Shipping Alert Job - Backup и Log Shipping Alert Job – Restore:

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

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

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

Ошибка, возникающая если имя БД содержит имя устройства (AUX, PRN, COM1, COM2, COM3, COM4):

Ошибка, возникающая после обновления версии SQL Server Standard Edition до Enterprise Edition:

Ошибка при вызове процедуры sp_resolve_logins, при смене ролей серверов:

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

Если при конфигурации Log Shipping используется опция No Recovery, а база данных на вторичном сервере в состоянии Standby:

Ошибка, возникающая при смене ролей серверов на именованных экземплярах SQL Server:

Возросло количество используемого места в журнале после восстановления копий журналов транзакций на вторичном сервере:

Ошибка может возникнуть, если на сервере существует DTS пакет, в котором используется Copy Objects Task:

Ошибка 3101, возникающая в работе процедуры sp_change_secondary_role:

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

Ошибка 3456, возникающая при попытке применить копию журнала транзакций:

В редких случаях, процесс передачи журналов может вызвать проблему подключения к SQL Server. Это связано с тем, что процессы, которые запущены в рабочем пространстве SQL Server, могут блокировать ресурсы, что препятствует подключению к TCP/IP порту. Это описано в следующей статье:

[В начало]

8 Другие полезные ресурсы в Интернет, затрагивающие передачу журналов и помогающие в разрешении проблем, возникающий в работе Log Shipping

[В начало]

9 Приложение - Схема работы Log Shipping

[В начало]

Руководство по работе с Microsoft SQL Server 2000 Analysis Services (продолжение)

По материалам статьи Carl Rabeler и Dave Wickert, Microsoft Corporation: Microsoft SQL Server 2000 Analysis Services Operations Guide
Перевод Виталия Степаненко

Содержание

Введение
Управление конфигурацией
Управление выпуском
Управление изменениями
Администрирование безопасности
Управление сервисом и доступностью
Управление свободным пространством и производительностью
Управление разрешением проблем и ошибок

Миграция репозитория

Метаданные для объектов, создаваемых в экземпляре Analysis Services (кубов, измерений и т.д.), хранятся в репозитории Analysis Services. По умолчанию репозиторий - это база данных Microsoft Access msmdrep.mdb, которая хранится в папке ..\Microsoft Analysis Services\Bin на компьютере с Analysis Services. Формат Access используется для того, чтобы пользователи, которые не используют SQL Server для хранения реляционных данных, могли использовать Analysis Services. Но если Вы используете SQL Server, миграция репозитория в базу данных SQL Server добавляет масштабируемость, поддержку и безопасность уровня предприятия. Миграция репозитория также позволяет Вам выполнять скоординированное резервное копирование базы данных репозитория и файлов из папки Data. Для дополнительной информации смотрите главу "Резервное копирование и восстановление" далее в этой статье.

Перед миграцией репозитория создайте специально выделенную для этого базу данных (например, OLAPRepository), используя регистро-независимую сортировку (case-insensitive collation). Выделенная база данных позволяет Вам делать резервные копии базы данных репозитория по собственному расписанию. Вы можете создать эту выделенную базу данных в экземпляре SQL Server на удаленном компьютере, но для лучшей производительности Вам следует создать базу данных на локальном экземпляре SQL Server. Чтобы произвести миграцию репозитория в SQL Server, используйте Migrate Repository Wizard, выбрав формат Analysis Services.

Важно: В большинстве случаев не выполняйте миграцию репозитория в базу данных msbd, которая стоит по умолчанию в Migrate Repository Wizard. В то время как база данных msbd подходит для одиночного экземпляра SQL Server, выделенного под репозиторий, обычно ее лучше не использовать. Если Вы выберете базу данных msbd, то репозиторий Analysis Services будет доступен всем другим системным ресурсам SQL Server на этом экземпляре, например, задачам по поддержке базы данных, определениям репликации, пакетам DTS и логам выполнения всех типов. Используя выделенную базу данных, Вы можете выполнять резервное копирование и восстановление по собственному расписанию и независимо от других объектов, хранящихся в базе данных msbd.

После миграции репозитория в базу данных SQL Server, Вы не сможете выгрузить его обратно в базу данных Microsoft Access. Миграция не удаляет базу данных msmdrep.mdb. Для дополнительной безопасности Вам следует удалить базу данных msmdrep.mdb (определив путь к файлу через Windows Explorer) после успешного завершения миграции. Если миграция прерывается по какой-либо причине, Analysis Services откатывает любые изменения и продолжает использовать базу данных msmdrep.mdb.

Совет: Чтобы определить местонахождение репозитория на незнакомом экземпляре Analysis Services, щелкните правой кнопкой мыши на сервере в Analysis Manager и выберите Edit Repository Connection String. Эта опция была добавлена в SP3. До SP3 Вы могли просматривать строку соединения в реестре. Однако, после SP3 эта строка соединения в реестре зашифрована и использование команды Edit Repository Connection String в Analysis Manager - это единственный способ увидеть местонахождение текущего репозитория.

Логирование и отправка сообщений об ошибках

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

Лог запросов

Чтобы позволить Usage Based Optimization Wizard создавать агрегаты, основанные на шаблонах предыдущего использования, и чтобы Usage Analysis Wizard мог генерировать отчеты с анализом использования запросов, Analysis Services сохраняет уровни, к которым обращался каждый N-й запрос, в логе запросов, который хранится в базе данных Microsoft Access. По умолчанию логируется каждый десятый запрос. По умолчанию местонахождение лога установлено как C:\Program Files\Microsoft Analysis Services\Bin\msmdqlog.mdb. Этот файл, как любой файл лога, должен быть защищен от неавторизованного доступа.

Вы можете изменять интервал логирования (каждый N-й запрос), останавливать любое логирование или очищать лог. Установка слишком маленького интервала логирования может сильно повлиять на производительность. Увеличение интервала логирования до значений больше десяти может повысить производительность, особенно если Вы работаете с системой, где одновременно сотни пользователей генерируют множество запросов в секунду. В такой системе Analysis Services пытается быстро логировать множество запросов, а Access не может записать такое количество информации настолько же быстро, как высокопроизводительная система базы данных.

Если обнаружится, что лог запросов активно используется, то для дополнительной стабильности и восстанавливаемости рассмотрите миграцию лога на выделенную базу данных SQL Server. Просто экспортируйте таблицу QueryLog из базы данных Access msmdqlog.mdb в базу данных SQL Server, измените запись реестра QueryLogConnectionString и перезапустите Analysis Services. Если Вы будете производить миграцию лога таким методом, не забудьте соответственно изменить Ваши процедуры резервного копирования и восстановления.

Также надо очищать лог запросов после последовательного запуска Usage-Based Optimization Wizard на всех кубах сервера. Чтобы изменить свойства лога запросов, щелкните правой кнопкой мыши на сервере в Analysis Manager, выберите Properties и перейдите на вкладку Logging.

Замечание: Лог запросов сохраняет запросы всего сервера, а не определенного куба.

ПРОДОЛЖЕНИЕ СЛЕДУЕТ

[В начало]

ССЫЛКИ НА СТАТЬИ

Англоязычные статьи

Oracle-on-Microsoft Shops Face Double Patching Delight
Lisa Vaas
Patching systems is always painful, but Tuesday's scenario of two major cumulative patch sets on the same day—from Oracle and Microsoft—is downright sadistic

Reporting Services: Two New (Free) Report Packs Released for Sharepoint and Axapta
Mat Stephen's SQL Server WebLog
Good news for the chap I met on the 'Ask the Experts' desk at TechEd, who was contemplating jumping through all sorts of hurdles to create reports form Sharepoint data. I couldn't really get my head round the (Sharepoint) problems he foresaw, but I was able to tell him that a report pack was in the pipeline to do just what he wanted, without any agro. So here it is, along with a report pack for Axapta (about which I know almost nothing)

Adding a row to an ASP.NET DataGrid
balazs_hideghety
This article describes an easy and ellegantly way to insert a row to a DataGrid

Sorting and paging with a custom DataGrid class
Sangra
A reusable DataGrid class with automatic sorting and paging features

SQL Management Studio--It ain't Visual Studio
William (Bill) Vaughn's Blog
I just spent the last couple of hours writing and debugging about 40 lines of TSQL code in SQL Server 2005 Management Studio—it should have taken far less time. What a PITA. Once you’ve worked with Visual Studio for years on end, having to write code in a stone-age editor/debugger is the pits. When you get a syntax error, the line number it gives you might (if you’re really lucky) point in the general vicinity of the problem. The compiler gets really confused at the slightest mistake (missing paren or stray END statement). It also has no intellisense so as you work through the archaic T-SQL code, we make more mistakes than ever because the way CHARINDEX and some other functions accept their arguments just seems backwards—and I’ve been using T-SQL since…well, the dawn of time in SQL Server years. That’s what I get for trying to be multi-lingual.

Richard Hundhausen presenting SQL Server 2005 Reporting Services Report Builder
GrokTalks
Richard Hundhausen from Boise presenting SQL Server 2005 Reporting Services Report Builder. The streaming version is here, and the downloadable version is here, or available via podcasting our RSS Feed

Testing dataset queries which utilize multi-value parameters in SQL Server 2005 Reporting Services
Russell Christopher
Normally, when you have a dataset query which is filtered by a parameter (like the one below), it's easy to test it in the query design tool

SSIS syntax in a derived column expression
SimonS' SQL Blog
Ok So in the picture of my last post I had a Derived Column. This was to see if having a single field with the address in changed the fuzzy lookup. So I add a derived lookup to concatenate the field

Interviewing a DBA
SQL Musings
Andy and I had an interesting question on this today. He's trying to hire a DBA and he had his first phone interview with a guy that supposedly had 10 years of experience. One of the first questions was asking about a table with 3 columns, two of which were in the clustered index. A particular query that referenced all 3 columns had a bookmark lookup. He asked how to make it run faster

RunAs
SQL Musings
When I started working at JD Edwards, I was a corporate administrator on the windows network. Since the DBAs were a part of this group, we had domain admin privleges to accomplish all work necessary. But we didn't just get domain admins rights on our accounts, we had a separate "sa" account that we were supposed to log into when we needed the rights to do work

Running Out of Space
Andy Warren
How many times have you run out of space in a database? What about on a file system? Andy Warren has had this happen a few times, especially when large imports take place. He brings us an article that describes some of the precautions he has taken to prevent this from happening

SQL Server 2005 Tip: Management views
The SQL Doctor is In
Old habits die hard. I have been at this for over ten years and am programmed to type

SSIS: Practical perf debugging - baselining
Ashvini Sharma
We had a lot of interest in SSIS at TechEd. One of our fervent users, Thomas from Denmark, asked how to further optimize his ~500K rows/second package. This is a commonly asked question and one of the first thing we need to have a discussion around getting a baseline perf for your environment

Converting a string date in the form YYYYMMDD to a date
Kirk Haselden
This question comes up a lot. How to convert a date in string format to a date type

SQL Server 2000 to SQL Server 2005 - checking for compatibility
Eric Nelson
My colleagues in the USA have been running some great application compatibility labs with our early adopters - and part of that lab has involved using a new tool which has now been made available for all. The SQL Server 2005 Upgrade Advisor can be used by database developers and administrators to analyze SQL Server 7.0 and SQL Server 2000 database servers in preparation for upgrading to SQL Server 2005. You can download the tool from http://www.microsoft.com/downloads/details.aspx?FamilyID=CF28DAF9-182E-4AC2-8E88-F2E936558BF2&displaylang=en

Static typing and substitution groups
Typed XML in SQL Server 2005
Since I’ve recently talked about both static typing and substitution groups maybe it’s time to see what happens when they meet

[В начало]

ФОРУМ SQL.RU

Самые популярные темы недели

Ваше мнение об упражнениях SELECT на http://sql.ipps.ru
Префиксы типов таблиц(t_), хр. процедур(p_), функций(f_), вьюшек(v_)... Нафик они нужны?
SP4 - делитесь опытом
запрос для тренда типа "а вчера в это же время"
Прокомментируйте - ошибка при многопольз. работе возможна?
Каскадное удаление (выводы)
Помогите построить сложный SELECT
Удаление записей из большой таблицы
Стоит ли заводить префикс для таблиц, обозначающий что таблица - справочник?
Проблемы с размером tempdb.mdf
Help me, please! По поводу UDT
Подскажите с репликацией
Хотим сделать историю изменений в нашей базе по каждой записи в каждой таблице. Зацените.
ошибка на триггере с курсором
Восстановление базы и бэкапа, лежащего в RAR архиве
Compare SQLOLEDB with DB-Library connection
Job failed
Производительность дисков в сервере. Счетчики производительности.
Operation is not allowed when the object is closed
Хранение периодических значений

[В начало]

Вопросы остались без ответа

Установка SQL 2000 sp1
Чем отличается ограничение доменов от ограничения логических обьъектов?
How a Resource Manager Can Get XA Compliance Using MS DTC
Перенос реплицированной DB на другой сервер (+)
переключение QA на русскую раскладку если резалтсет в руск.кодировке
Как узнать сколько осталось места на ленте стримера?
Появление ошибки "The server could not load DCOM"
Extended Stored Proc: типа параметра??
В окне EM исчезла информация о базах данных

[В начало]

КНИГИ

Хранилища данных

С. Я. Архипенков, Д. В. Голубев, О. Б. Максименко

Издательство: Диалог-МИФИ, 2002 г., Мягкая обложка, 528 стр., ISBN 5-86404-167-X

В книге дано описание технологий хранилищ данных и OLAP. Рассмотрены методические основы организации работ и выполнения проекта построения корпоративной информационно-аналитической системы. Представлено подробное описание практических приемов работы по созданию, загрузке и администрированию многомерных баз, по разработке OLAP-приложений конечного пользователя. Большое внимание уделено актуальному направлению расширения аналитических систем до масштабов World Wide Web в сетях интранет/Интернет.Книга адресована специалистам и менеджерам отделов информационных технологий, работающим над проектами построения корпоративных хранилищ данных и информационно-аналитических систем. Авторы книги, Сергей Архипенков (Введение, части 1, 2, 4, 6–9, общая редакция), менеджер проектов компании Luxoft, имеет двадцатилетний опыт применения информационных технологий при решении задач анализа сложных систем, Дмитрий Голубев (части 3, 5), ведущий специалист, и Оксана Максименко (часть 10), консультант компании IBS, в течение пяти последних лет активно занимаются проектированием и разработкой корпоративных информационно-аналитических систем на базе программных продуктов компании Oracle.

[В начало]


Вопросы, предложения, коментарии, замечания, критику и т.п. оставляйте Виталию Степаненко и Александру Гладченко в форуме: Обсуждение рассылки

СЕМИНАРЫ  КОНФЕРЕНЦИИ

МИНИФОРМА
ПОДПИСКИ



ПУБЛИКАЦИИ  АРХИВ


Subscribe.Ru
Поддержка подписчиков
Другие рассылки этой тематики
Другие рассылки этого автора
Подписан адрес:
Код этой рассылки: comp.soft.winsoft.sqlhelpyouself
Отписаться
Вспомнить пароль

В избранное