СОДЕРЖАНИЕ

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

Хотя это и выглядит запутанным, все это весьма просто реализовать. Самое сложное в создании нашей секционированной таблицы - это доставка данных из большого количества источников - 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

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

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

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

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

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

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 для таблиц, индексов или объектов статистики.

Не возможно отменить установленное базе данных для 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:

• BUG: All changes May Not be Rolled Back when Log Shipping Maintenance Wizard Fails

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

• INF: Troubleshooting SQL Server 2000 Log Shipping "Out of Sync" Errors

• FIX: Log Shipping with SQL Server Authentication Generates Backup and "Out of Sync" Threshold Alerts

• PRB: Backup, Copy, and Load Job Information Is Not Updated on the Log Shipping Monitor

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

• BUG: Error 3154 Reported in Log Shipping Restore Job Sporadically

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

• Добавление и удаление файла базы данных между резервированиями журнала

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

• FIX:Log Shipping: Cannot Change Role From Secondary to Primary When Database Names Are Different

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

• INF: Avoid Using Device Names as Database Names

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

• BUG: Log Shipping Elements are Missing After You Upgrade from Standard to Enterprise Edition

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

• BUG: sp_resolve_logins Stored Procedure Fails If Executed During Log Shipping Role Change

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

• PRB: Error Message: "Unable to copy the initialization file..." Occurs When You Set Log Shipping Between Two Clustered SQL Server Servers

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

• PRB: Database Loaded in Standby Mode if No Recovery Mode is Selected from Destination Database Window When You Configure Log Shipping

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

• FIX: Sp_change_primary_role May Store Transaction Log Backup in the Wrong Location

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

• INF: Transaction Log Grows Unexpectedly or Becomes Full on SQL Server

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

• FIX: DTS Copy Objects Task (DMO) Breaks Transaction Log Backup Chain By Switching Recovery Mode to Simple During Transfer

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

• BUG: sp_change_secondary_role Fails with Error 3101 if There Are Outstanding Transaction Log Backups

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

• PRB: Cannot Modify Backup Network Share After You Change the Transaction Log Backup Folder

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

• FIX: You receive error message 3456 when you try to apply a transaction log to a server

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

• FIX: SQL Server fails to bind TCP/IP port at startup

[В начало]

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

• Передача журналов в SQL Server, Часть 1 (Автор Рон Телмейдж)

• Передача журналов в SQL Server, Часть 2 (Автор Рон Телмейдж)

• MSDN: FAQ SQL Server 2000 - Log Shipping

• MSDN:HOW TO: Configure Security for Log Shipping

• MSDN: Transactional replication and Log Shipping

• MSDN: How to set up and perform a log shipping role change

• Проблемы резервного копирования и восстановления баз данных SQL Server

• Сравнение передачи журналов и репликации

[В начало]

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.

[В начало]