Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
MS SQL Server - дело тонкое...
Информационный Канал Subscribe.Ru |
#252<< #253 |
СОДЕРЖАНИЕ
Основы I/O в SQL Server 2000 (продолжение)
По материалам статьи Bob Dorr:
SQL Server 2000 I/O Basics Завершение работы и интервал регенерации
Штатная операция завершения работы сервера баз данных запускает процесс контрольной
точки для всех баз, закрывает все внутренние процессы проверки структур баз данных
и завершает процесс SQL Server. Работа в кластере может повлиять на время завершения работы сервера баз данных.
Корректировка интервала регенерации После корректировки интервал регенерации могут возникнуть несколько побочных эффектов. Обдумайте их тщательно перед тем, как корректировать интервала регенерации.
Время жизни "грязных" страниц - страница считается "грязной", когда имели
место изменения её данных. Грязная страница не может быть удалена из буферного
пула SQL Server, пока вначале связанные с ней записи журнала транзакций и затем
сама страница не будут записаны непосредственно на долговременный носитель.
Увеличение интервала прохождения контрольной точки (после увеличения интервала
регенерации) под высокой нагрузкой системы провоцирует вытеснение обработки грязных
страниц под управление кода программы отложенной записи. Это может привести к полной
деградации производительности, потому что отложенная запись не предназначена для
исполнения действий, подобных контрольной точке. Продолжительность контрольной точки - Увеличение интервала регенерации может привести к увеличению в оперативной памяти числа грязных страниц. Чем больше грязных страниц, тем дольше контрольная точка будет сбрасывать их на диск во время прохождения по буферному пулу SQL Server. Увеличение продолжительности контрольной точки не является проблемой, но потенциально может увеличить интервал регенерации и повысить нагрузку на дисковую подсистему во время этого интервала.
Продолжительность регенерации - Увеличение интервала регенерации может привести
к увеличению времени регенерации. Если SQL Server не штатно завершает свою работу
(неожиданное завершение процесса или, например, происходит падение напряжения),
во время следующего старта, менеджер регенерации обеспечивает правильность состояния
транзакций базы данных. Если контрольная точка запускается не часто, и это приводит
к значительному увеличению числа грязных страниц, не штатное завершение потребует
для менеджера регенерации исполнение большого числа откатов и проверки транзакций,
необходимых для возврата базы данных к непротиворечивому состоянию транзакций.
Основным фактором, влияющим на производительность этой операции, является то,
что буферный пул SQL Server будет "холодным" (в памяти не будет страниц) во время
регенерации. Процедура восстановления должна будет считать в память все соответствующие
страницы базы данных и сделать необходимые изменения. Это может увеличить время
ожидания регенерации, что является нежелательным для промышленных применений.
Увеличение интервала регенерации часто приводит к потерям в производительности и
к дискриминации требований к доступности приложений. Microsoft SQL Server 2000 использует несколько моделей резервирования баз данных: Full, Bulk-Logged и Simple. Рабочая нагрузка прикладной системы при разных моделях резервирования может получить разное поведение I/O. Приложение, аппаратное решение и модель резервирования должны выбираться из бизнес - требований к развертываемой системе по резервированию и восстановлению. ПРОДОЛЖЕНИЕ СЛЕДУЕТ Решение проблем, связанных с целостностью данных в Analysis Services 2005 (окончание)
По материалам статьи T.K. Anand, Microsoft Corporation:
Handling Data Integrity Issues in Analysis Services 2005 Март 2005 года О чем эта статья: В статье рассматриваются типичные проблемы, связанные с целостностью данных, и показывается, какие средства дает Analysis Services 2005 для решения этих проблем. (10 печатных страниц)
Относится к: Содержание
Вступление В этой главе мы рассмотрим разные сценарии, включающие в себя проблемы целостности данных, и рассмотрим, как элементы управления, представленные в предыдущей главе, могут быть использованы для решения этих проблем. Мы также продолжим использовать определенную ранее реляционную схему. Проблемы целостности данных в таблице фактов Таблица фактов sales имеет записи с product_id, которые не существуют в таблице измерений product. Сервер выдаст ошибку KeyNotFound во время обработки. По умолчанию ошибки KeyNotFound логирутся и ведется их подсчет до предела количества ошибок, который по умолчанию равен нулю. Поэтому обработка прервется на первой же ошибке. Решением является изменение ErrorConfiguration для группы измерений. Ниже показаны две альтернативы: - Установить KeyNotFound = IgnoreError. - Установить KeyErrorLimit равным достаточно большому числу. По умолчанию обработка ошибок KeyNotFound заключается в постановке записи из таблицы фактов в соответствие неизвестному элементу. Другой альтернативой является установка KeyErrorAction равным DiscardRecord, чтобы проигнорировать эту запись из таблицы фактов. Проблемы целостности данных в таблице измерений SnowFlaked Таблица измерений product имеет записи с product_class_id, которых не существует в таблице измерений product_class. Эта проблема обрабатывается таким же образом, как и в предыдущей главе, кроме необходимости модификации ErrorConfiguration для измерения. Внешние ключи со значением NULL в таблице фактов Таблица фактов sales имеет записи, в которых product_id равен NULL. По умолчанию все значения NULL конвертируются в ноль, и уже нулевое значение ищется в таблице product. Если существует product_id, равный нулю, то соответствующие данные таблицы фактов соотносятся с этим значением product (возможно, это не то, что Вы хотели). В противном случае выдается ошибка KeyNotFound. По умолчанию ошибки KeyNotFound логируются и производится подсчет количества таких ошибок до предела количества ошибок, который по умолчанию равен нулю. Поэтому обработка прервется после первой же ошибки. Решением является изменение NullProcessing в свойстве группы измерений. Ниже показаны две альтернативы: - Установить NullProcessing = ConvertToUnknown. Эта установка сообщает серверу, чтобы он поставил записи со значениями NULL в соответствие неизвестному элементу "Invalid Product". При этом также генерируются ошибки NullKeyConvertedToUnknown, которые по умолчанию игнорируются. - Установить NullProcessing = Error. Эта установка сообщает серверу, чтобы он игнорировал записи со значением NULL. При этом также генерируются ошибки NullKeyNotAllowed, которые по умолчанию логируются и их количество подсчитывается до достижения предела количества ошибок. Это можно регулировать с помощью изменения ErrorConfiguration в группе измерений.
![]() Рис.5. Диалоговое окно Edit Bindings Заметьте, что свойство NullProcessing должно быть установлено у KeyColumn свойства группы измерений. Во вкладке Dimension Usage дизайнера кубов отредактируйте отношение между измерением и группой измерений. Нажмите кнопку Advanced, выберите свойство масштабируемости и установите NullProcessing. NULL в таблице измерений Snowflaked Таблица измерений product имеет записи, в которых product_class_id имеет значение NULL. Эта проблема обрабатывается таким же образом, как и в предыдущей главе, кроме необходимости установки NullProcessing у KeyColumn в DimensionAttribute (в панели Properties дизайнера измерений). Несогласованные отношения в таблице измерений Как было описано ранее, несогласованные отношения в таблице измерений приводят к задвоению ключей. В примере, описанном ранее, brand_name со значением "Best Choice" появляется дважды с разными значениями product_class_id. Это приводит к ошибке KeyDuplicate, которая по умолчанию игнорируется, а сервер игнорирует задвоенную запись. В качестве альтернативы можно установить KeyDuplicate = ReportAndContinue/ReportAndStop, что приведет к логированию ошибок. Этот лог можно будет потом исследовать для определения потенциальных недостатков в дизайне измерений. Решение проблем целостности данных может оказаться нелегкой задачей для администраторов баз данных. SQL Server 2005 Analysis Services предоставляет сложные элементы управления, такие, как Unknown Member (неизвестный элемент), Null Processing (обработка Null) и Error Configuration (конфигурирование ошибок), которые сильно упрощают задачи управления кубами. Статьи на русском языке
Вышли новые бета-версии
Roman's Weekly SQL Server Tip - Enabling job status notifications with DB Maintenance plans Самые популярные темы недели
Кто на чем пишет клиентов под SQL Server?
зависает ЕМ при обращении к свойствам SQL server agent |
Вопросы, предложения, коментарии, замечания, критику и т.п. оставляйте Виталию Степаненко и Александру Гладченко в форуме: Обсуждение рассылки
|
http://subscribe.ru/
http://subscribe.ru/feedback/ |
Подписан адрес: Код этой рассылки: comp.soft.winsoft.sqlhelpyouself |
Отписаться |
В избранное | ||