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

#14

СОВЕТ

Восстановление ключей реестра, относящихся к  Microsoft SQL Server
(По материалам статьи  Paul E. Matthews "Registry Problems")

Пауль предлагает варианты восстановления значений ключей реестра
Windows NT, в случае их нарушения или удаления. Эти ключи хранятся в:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer
для  SQL Server 7.0 и 6.5
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server
для SQL Server 2000

Восстановить эти ключи можно следующим образом:

Для 6.5: Запустите установку сервера баз данных из каталога MSSQL\BINN
со следующими параметрами:

setup /t RegistryRebuild = On

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

Для 7.0: После того, как вы инсталлировали сервер баз данных, была
выполнена утилита regrebld.exe, которая сохранила все используемые
SQL сервером ключи в резервный файл (*.rbk) в каталоге MSSQL\BINN.
Это позволяет Вам в последствии использовать указанную утилиту,
как для создания резервных копий ключей реестра, так и для
восстановления их значений. Помните только, что MS SQL Server не
будет делать это автоматически при внесении Вами изменений в
конфигурацию. Вам будет необходимо запустить утилиту regrebld.exe с
одним из соответствующих параметров: -Backup или -Restore.

Для 2000: SQL Server 2000 действует аналогично SQL Server 6.5. Вам
необходимо запустить установку и в Advanced Options выполнить
Registry Rebuild.

ГОТОВИМСЯ К ТЕСТУ ПО 1139А

ВОПРОСЫ ДЛЯ ПОВТОРЕНИЯ
(К шпаргалке #3: Управление безопасностью)

ВОПРОС
Какой режим проверки подлинности следует реализовать в среде, в
которой пользователи подключаются из операционных систем UNIX
и Windows NT? Почему?
ОТВЕТ
Следует использовать смешанный режим, поскольку он поддерживает
как проверку подлинности с участием операционной системы
Windows NT, так и проверку подлинности сервером SQL Server.
ВОПРОС
Когда назначать разрешения учетной записи пользователя следует
непосредственно?
ОТВЕТ
Назначать разрешения непосредственно учетной записи пользователя
следует в случаях, когда она отображается в группу Windows NT, для
которой требуются стандартные разрешения.
ВОПРОС
Когда следует использовать учетную запись подключения sa?
ОТВЕТ
Учетная запись подключения sa применяется только при установке
сервера SQL Server и для совместимости с предыдущими версиями.
ВОПРОС
Если пользователю предоставлено разрешение на обновление таблицы,
однако эти разрешения запрещены для роли, членом которой является
пользователь, сохранит ли он для себя право обновления таблицы?
ОТВЕТ
Нет. Отказ в разрешении, безусловно, отменяет предоставление прав.


ШПАРГАЛКА #4 (обзор официального курса Microsoft)

(Архив шпаргалок Вы найдёте в предыдущих номерах на
http://subscribe.ru/archive/comp.soft.winsoft.sqlhelpyouself)

Расчёт выделяемого дискового пространства для новой базы данных

Для того, что бы Вы могли верно, и на долго рассчитать тот объём
дискового пространства, который потребуется вновь создаваемой
базе данных (БД) в отведённые сроки её работы, потребуется уяснить
некоторые принципы организации хранения данных и журналирования
транзакций.
Новая БД, с точки зрения операционной системы, представляет
собой набор файлов: *.mdf - главные файлы данных; *.ndf -
вспомогательные файлы данных; *.ldf - файлы журналов транзакций.
Именам файлов SQL Server сопоставляет свои логические имена.
Разумеется, по своей природе данные и журналы транзакций
отличаются по типу доступа/записи (первые - случайный доступ,
вторые - последовательный доступ) и поэтому располагаются у Вас
на разных дисковых массивах. Следовательно, расчёт занимаемого
места БД и журналов должен выполняться с учётом наличия
свободного дискового пространства на этих массивах. Опасность
того, что сервер исчерпает выделенное для него пространство на
диске, остаётся, не смотря на динамическое управление размером
файлов баз данных. Фундаментального изменения по сравнению
с версией сервера 6.5 не произошло, там тоже можно было растянуть
размер файла на всё доступное дисковое пространство. Зато всё
сильно усложняется, если на одном дисковом массиве у Вас "живут"
несколько файлов баз данных. Если Вы не можете точно
прогнозировать возможное увеличение объёма каждой из этих баз,
прогнозирование момента добавления/приобретения дискового
пространства превращается в задачу с несколькими неизвестными.
Кроме того, появятся неприятные факторы снижения эффективности
дисковых операций связанные с фрагментацией файлов. Может быть,
удачным выходом, при таком раскладе, станет возврат к испытанному
в предыдущих версиях методу фиксации размера файлов баз данных.
Последовательное создание файлов БД позволит избежать их
фрагментации, а периодическая перестройка индексов позволит
упорядочить данные внутри.
БД содержит в себе копию базы данных model, которая включает в
себя системные таблицы, а также таблицы данных и индексы к ним.
Отсюда вытекает первое правило: хорошая БД не может быть меньше,
чем model.
Таблицы и индексы БД располагаются в т.н. экстентах (экстент - 8
смежных страниц, страница - 8 КБ последовательно расположенных
блоков диска, в 1 МБ помещается 16 экстентов или 128 страниц).
Если таблица меньше размера экстента, то он может разделяться
между несколькими таблицами. Таблицы состоят из строк, которые
не могут превышать размер страницы и даже немного меньше.
Из 8 КБ на строку отводится не более 8060 байт, остальное -
накладные расходы на её хранение.
Любое изменение данных, которое осуществляется через исполнение
соответствующих операторов T-SQL, должно быть защищено от
всякого рода неожиданностей (например, веерное отключение
электричества местными энергетиками) и исполняться только в
том виде, в каком оно представлено логикой приложения и сервера
баз данных. Иначе нарушится целостность и согласованность данных,
а восстановление окажется невозможным. Т.о. нам необходимо
зафиксировать состояние данных до внесения изменений, провести
необходимые операции и  убедиться, что всё получилось. Иначе,
первоначальное состояние должно быть восстановлено. SQL сервер
предоставляет нам такой механизм, а цепочки логически связанных
блоков операторов T-SQL, которые могут быть выполнены только
целиком или не выполняться вообще, называются транзакциями.
Разумеется, транзакций происходит в каждый момент очень много и
параллельно, поэтому их приходится журналировать. Существует,
правда, опасность того, что не спасёт даже этот замечательный
механизм. Например, не верная конфигурация RAID контроллера
(когда не отключено его собственное кэширование) может привести
к тому, что изменения в журнале транзакций не успеют записаться на
диск, поскольку застрянут в кэше контроллера. Изменения данных, не
отражённые в журнале, откатить не получится. Есть операторы,
которые неявно (для нас) составляют сами целую транзакцию.
Естественно это: DELETE, UPDATE и INSERT. Обычные же
транзакции обрамляются операторами BEGIN TRNSACTION и
COMMIT  TRNSACTION. Следовательно, если Вы или Ваши
разработчики напичкаете между ними очень много всякого "действа",
то и получите соответствующую утилизацию журнала транзакций.
Уж тогда позаботьтесь, что бы на диске было достаточно места
для его "разбухания". В обычном случае, как это предустановленно
по умолчанию, хватает 25% от размера основной базы. Но нельзя
забывать и про индексы, они (в зависимости от фантазии создателя)
могут включать в себя разнообразные наборы полей и, как правило,
имеют тенденцию плодиться. С другой стороны, большинство
прикладных применений не создаёт чрезмерной утилизации журналов.
Большая нагрузка на них может случаться во время массовых операций
(например, подгрузка данных или нечто подобное), которые
осуществляются не часто. Измерение размеров журналов во время
"спокойной" работы сервера может быть чревато неприятностями,
когда на Вас обрушится лавина инсёртов.
Ещё одним фактором, косвенно влияющим на размер журнала
транзакций, является интервал появления контрольной точки. Для
понимания этого влияния, углубимся немного в транзакционный
механизм. Прежде, чем данные изменятся, сервер вытаскивает их в
буферный кэш. Все операторы и их параметры/значения в режиме
опережающей записи записываются вначале в журнал, а уже потом
происходит изменение данных. Данные записываются не сразу и не
при первой возможности сервера предоставить для этого
соответствующие ресурсы, а только когда сервером, в соответствии с
заданной в конфигурации установкой, инициализируется процесс
контрольной точки. До этого момента данные не изменяются, хотя
транзакция уже выполнила COMMIT  TRNSACTION. В случае
неприятностей, Вы такую транзакцию не потеряете. Механизм
автоматической регенерации выполнит её после восстановления
нормальной работы сервера. Откату в исходное состояние подлежат
только те транзакции, у которых не зафиксирован маркер
COMMIT  TRNSACTION. Теперь, можем себе представить типовую
российскую фирму, старающуюся изо всех сил сэкономить на "железе"
для сервера баз данных. DBA (как правило, "гуру" в своём деле),
стараясь сбалансировать загрузку "камня" и I/O, вполне может сделать
время появления контрольной точки достаточно большим. Далее,
вспомним, какие меры принимаются для того, что бы до следующей
перегрузки сервера вы не заполнили свой журнал до конца.
Естественно, транзакции резервируются на соответствующее
устройство, и это происходит с предусмотренной тем же DBA
периодичностью. Получается вилка, чем дольше не появляется
контрольная точка, тем больше данных мы не можем забрать из
журнала на резервную копию. В наших, особых условиях не
исключено, что Вы в такую вилку попадёте.

Продолжение следует

ВОПРОСЫ ПОДПИСЧИКОВ

(Если Вы знаете, чем помочь, отправьте "рецепт" на
MSSQLHelp@pisem.net Ваши соображения
могут быть
опубликованы в очередном выпуске рассылки, так что
укажите, как на Вас ссылаться... Адреса публиковаться
не будут.)

Вопрос #1. Как при построении отношения "один - ко - многим"
создать автоматическое заполнение внешнего ключа зависимой
таблицы значением первичного ключа главной, средствами
MS SQL Server?

Замечание подписчика:
Мы разработали БД, в нескольких таблицах которой использовалось
полнотекстовое индексирование. Было замечено, что такие БД
удалять просто командой "drop database" нельзя. Для удаления
необходимо сначала удалить все полнотекстовые индексы для этой
БД. В противном случае, служба Full Text Search может зависнуть.

Вопрос #2. Проблема с OLAP.
SQL и OLAP сервисы успешно стартовали. Внешние OLAP клиенты,
как MS Excel 2000 и идущий в поставке пример MDX Sample application,
успешно к OLAP сервису коннектятся. Однако при попытке
приконнектиться при помощи OLAP manager получаю ошибку:
"Cannot connect to the registry on the server computer [имя компьютера]".
В чем может быть проблема?

РАБОТА ДЛЯ DBA (Только пошлите английское резюме)

POSITION ID: DCI-594  EMAIL: joyn@dci-devctr.com
WEB: http://www.dci-devctr.com

POSITION ID: J584-28  EMAIL: john@novaalt.com
WEB: http://www.novaalt.com

POSITION ID: T0400  EMAIL: leet@hepcoinc.com
WEB: http://www.hepcoinc.com

POSITION ID: LH_SR.WEBENG  EMAIL: linda.hakkarinen@modisit.com
WEB: http://www.modisit.com

POSITION ID: 171  EMAIL: meade@tiburontech.com
WEB: http://www.tiburontech.com

POSITION ID: NTR_SQL  EMAIL: headhunter2@ncweb.com
WEB: http://www.dice.com/exceloh

POSITION ID: SR00-30  EMAIL: sriley@mercdatasys.com
WEB: http://www.mercdatasys.com

POSITION ID: SLC10040  EMAIL: Meredith@Consult-Net.com
WEB: http://www.consult-net.com

POSITION ID: 9632rkb-d  EMAIL: rbarrymore@itnet.judge.com
WEB: http://www.judge.com

POSITION ID: JO002238  EMAIL: dice@pierce.com
WEB: http://www.pierce.com

POSITION ID: hcg.796  EMAIL: resume@hicksconsult.com
WEB: http://www.hicksconsult.com

POSITION ID: D8731  EMAIL: mmurphy@newmill.com
WEB: http://www.newmill.com

ИНФОРМАЦИЯ АВТОРА РАССЫЛКИ

1. Для желающих подписаться на эту рассылку, но не имеющих
возможности воспользоваться WEB - интерфейсом сервера subscribe.ru,
есть возможность подписаться с помощью электронной почты.
Для этого Вам нужно направить письмо в subscribe.ru, в теле которого
должен находиться набор соответствующих команд. Письмо следует
отправлять на один из адресов:
subscribe@subscribe.ru     Ответы
в КОИ-8
subscribe-lat@subscribe.ru
Ответы латинскими буквами
subscribe-alt@subscribe.ru
Ответы в кодировке DOS (CP-866)
subscribe-win@subscribe.ru
Ответы в кодировке WINDOWS (CP-1251)
На одной строке может быть только одна команда. Вот перечень
команд, которые могут Вам понадобиться в первую очередь:
HELP -  Высылается подробная инструкция.
FAQ  - Высылаются ответы на часто задаваемые вопросы.
LIST - Высылается список рассылок, на которые можно подписаться
LIST latest -  Высылается список рассылок, открытых недавно.

Например, команда для подписки на эту рассылку будет иметь
следующий вид:

SUBSCRIBE ВАШ@АДР.ЭЛ.ПОЧТЫ пароль comp.soft.winsoft.sqlhelpyouself

Можно указать через пробел несколько кодов рассылок сразу.
Название команды можно сократить до SUB. Повторная
подписка на уже подписанную рассылку молча игнорируется.

2. Довожу до Вашего сведения, что автор рассылки не является
"гуру" в программировании для SQL - серверных приложений.
Поэтому, ваши вопросы по данной тематике лучше адресовать в
существующие форумы:

http://www.win2000mag.net/forums/application/Main.cfm?CFID=6932595&CFTOKEN=23483359&CFApp=57
http://www.swynk.com/discuss_sql7/default.asp
http://mondrian.sba.com/forums/Index.cfm?CFID=215555&CFTOKEN=8545&CFApp=89&;
или можно подождать/помочь организации русскоязычного форума,
который обязательно будет содержать такой раздел. На сегодняшний
день, есть возможность публикации Ваших вопросов в рассылке. Вы
можете направить в мой адрес MSSQLHelp@pisem.net
подробное и обстоятельное письмо с описанием проблемы и
получать через меня копии ответов подписчиков.
Многие "забугорные" WEB сервера имеют обширные библиотеки
скриптов на T-SQL и других примеров кода. Попробуйте поискать
решение там, например, на http://www.swynk.com/sqlhome/scriptlibrary.asp

Доступные ресурсы рассылки:
Страница Каталога
http://subscribe.ru/catalog/comp.soft.winsoft.sqlhelpyouself
Архив
http://subscribe.ru/archive/comp.soft.winsoft.sqlhelpyouself
Статистика
http://subscribe.ru/stat/comp.soft.winsoft.sqlhelpyouself