Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
MS SQL Server - дело тонкое...
| Информационный Канал Subscribe.Ru |
| #126<< #127 |
|
РЕКЛАМНАЯ АКЦИЯ
Скидка 14 % для посетителей SQL.RU при покупке RCO для поиска по-русски в Oracle и SQL. С 16 января до 15 февраля 2003 года SQL.RU и RCO.RU предлагают посетителям сайта SQL.RU получить скидку 14% при заказе продуктов RCO for Oracle и RCO for BackOffice 2000, предназначенных для эффективного полнотекстового поиска по-русски в Oracle и SQL. Для получения скидки посетителю необходимо при заказе продуктов назвать пароль: "RCO: достоин тот иметь, кто умеет искать". Контакты для заказа продуктов:тел.: 930 89 59, 930 89 58 e-mail: rco@metric.ru СОДЕРЖАНИЕ СЕМИНАР Группа компаний Талгар совместно с проектом SQL.RU проводит второй ежемесячный семинар посвященный СУБД Microsoft SQL Server. Тема семинара: "Построение защищенных (безопасных) приложений на базе Microsoft SQL Server 2000 ". На семинаре обсуждаются вопросы программирования и администрирования баз данных на основе Microsoft SQL Server 2000. Семинар состоится 23 января 2003 года в Учебно-консультационном центре Группы компаний Талгар в 11-00. На семинаре будут представлены доклады:
На семинар приглашаются ведущие специалисты, программисты, разработчики информационных систем.
Вы можете заранее задать вопрос докладчику или определить темы, которые вы
хотели бы обсудить на предстоящем семинаре. Для этого необходимо послать письмо
на адрес mssql@talgar.ru. Участие в семинаре бесплатно. Внимание ! Количество участников ограничено. Большая просьба направлять на семинар от каждой организации не более двух человек. Для участия в семинаре необходимо заполнить регистрационную форму на каждого участника семинара и отправить ее по факсу или электронной почте. Также Вы можете заполнить регистрационную форму на нашем веб-сайте. По всем вопросам регистрации , пожалуйста, обращайтесь к менеджеру Хуриленко Оксане. Тел./факс (095) 333-72-13, 128-88-66, 128-93-41 Доступен для загрузки Microsoft SQL Server 2000 Service Pack 3:
Дополнительная информация:
SQL Server 2000 Books Online (Updated for SP3)
Использование SQL Server совместно с Encrypting File System (EFS)
Разрешение проблем с EFS и SQL Server Есть несколько типичных проблем, с которыми Вы можете столкнуться при использовании EFS совместно с SQL Server. Возможно, Вы зашифровали базу master или целиком каталог Data не под той учётной записью, под которой стартует SQL Server. Если это так, сервер баз данных не будет запускаться. Например: C:\Program Files\Microsoft SQL Server\MSSQL\Data>net start mssqlserver The MSSQLSERVER service is starting. The MSSQLSERVER service could not be started. The service did not report an error. More help is available by typing NET HELPMSG 3534. Попробуйте расшифровать файлы базы данных master (или целиком весь каталог) и попытайтесь перезапустить SQL Server. Если SQL Server стартует, значит Вы всё-таки зашифровали эти файлы, используя не ту учётную запись. Если SQL Server не запускается, то это вряд ли связано с EFS, хотя Вам лучше расшифровать все зашифрованные ранее файлы до начала разрешения проблем, чтобы упростить этот процесс (в случае, если потребуется копировать файлы, и т.д.) Если Вы выборочно шифруете файлы баз данных, наиболее вероятная причина появления этой проблемы, если помеченная Suspect база данных была зашифрована другой учётной записью. Что бы проверить это предположение, расшифруйте файлы помеченной базы и перезапустите SQL Server. Если база будет успешно воспринята сервером, попробуйте зашифровать её, зарегистрировавшись на сервере под учётной записью, от имени которой стартует SQL Server, и перегрузитесь. Шифрация и сжатие одновременно не возможны Компрессия файлов и папок в Windows 2000 не может применятся одновременно с EFS. В результате, если Вы попробуете средствами EFS зашифровать сжатый файл, будет зашифрован несжатый формат и сохранён на диске в таком виде. Если у Вас не достаточно свободного дискового пространства, операция может окончится неудачей. Автор вообще не рекомендует применять компрессию для файлов баз данных SQL Server. EFS работает только на NTFS. Поэтому, если Вы копируете зашифрованный файл на диск, который не является томом NTFS, Вы потеряете шифрацию. Вы не будете предупреждены об этом системой, так что просто имейте это ввиду, если захотите перенести зашифрованные файлы на FAT или FAT32. Если кто-то, кроме учетной записи сервиса, попробует скопировать зашифрованный файл, то будет выдано сообщение об ошибке: Cannot copy *****: Access is denied. The source file may be in use. Кроме того, что будет получен отказ в исполнении такой операции вы получаете возможность аудита таких событий. И наконец, когда Вы шифруете или дешифруете файлы, Вы можете получать следующую ошибку: C:\Program Files\Microsoft SQL Server\MSSQL\Data>cipher /E /A pubs.mdf Encrypting files in C:\Program Files\Microsoft SQL Server\MSSQL\Data\ pubs.mdf [ERR] pubs.mdf: The process cannot access the file because it is being used by another process. 0 file(s) [or directorie(s)] within 1 directorie(s) were encrypted. Причина возникновения этой ошибки в том, что SQL Server может держать файл открытым. Открытые файлы не могут быть зашифрованы (операционная система нуждается для этого в монопольном доступе). Попробуйте остановить сервис SQL Server и повторить попытку шифрации.
Индексы. Теоретические основы.
Вольный перевод главы книги Design SQL Server 2000 Exam 70-229 © Sybex 2001 Наверное нет большой нужды повторять что индексы могут существенно ускорить доступ к данным. Это не является гарантированным правилом и, например, при небольшом размере таблицы, простой перебор записей может быть более эффективен чем выборка по индексам. Простейшим примером применения индексов в реальной жизни является оглавление книги. Вместо перебора всех страниц книги, читатель может открыть конкретную главу книги, получив номер ее начальной страницы из оглавления. Той же самой цели служат и индексы в таблице. Они позволяют получить данные из определенной записи без перебора всех записей в таблице.
Физически данные хранятся на 8Кб страницах. Сразу после создания, пока таблица не имеет индексов, таблица выглядит как куча (heap) данных. Записи не имеют определенного порядка хранения. Рис 1. иллюстрирует таблицу Customers из базы данных Northwind, хранящихся в виде кучи. 
Рис. 1 Куча (A heap) Когда вы хотите получить доступ к данным, SQL Server будет производить сканирование таблицы (table scan). SQL Server сканирует всю таблицу что бы найти искомые записи. Например мы хотим найти запись, удовлетворяющую условию: SELECT * FROM Customers WHERE CustomerID = ‘ROMEY’ SQL Server прочитает все записи начиная с первой и заканчивая последней и выберет те, которые будут удовлетворять указанному условию. SQL Server не знает что в таблице существует только одна запись, удовлетворяющая условию, пока в таблице не существует unique constraint, unique index или primary key. Во всех трёх перечисленных случаях создается индекс для поддержания ограничения. Приведенный пример иллюстрирует две базовые функции индексов:
- увеличение скорости доступа к данным Несмотря на достоинства, индексы так же имеют и ряд недостатков. Первый из них – индексы занимают дополнительное место на диске и в оперативной памяти. Каждый раз когда вы создаете индекс, вы сохраняете ключи в порядке убывания или возрастания, которые могут иметь многоуровневую структуру. И чем больше/длиннее ключ, тем больше размер индекса. Второй недостаток – замедляются операции вставки, обновления и удаления записей. Однако алгоритмы построения индексов разработаны таким образом что бы иметь как можно меньший негативный эффект для указанных операций и даже позволяет выполнять их быстрее, как будет показано позднее. В SQL Server индексы хранятся в виде B-деревьев (B-tree). “B” означает сбалансированное (не путать с бинарным). Рис 2 показывает индекс, созданный для поля CustomerID для таблицы Customers. 
Рис. 2 B-Tree индекс Теперь если выполнить предыдущий запрос по поиску записи CustomerID = ‘ROMEY’, будут прочитаны только страницы 30, 22 и 10 в указанном порядке. Как указывалось ранее индексы в SQL Server представляют собой сбалансированные деревья. Это означает, что длины веток для всех ответвлений индекса, одинаковы. Если посмотреть на Рис. 2 сверху вниз, вам придется просканировать только три страницы что бы найти запись удовлетворяющую условию. Каждая ветка сбалансирована и внутренний механизм построения индексов держит это дерево сбалансированным при любых изменениях в таблице. Обратите внимание что на Рис. 2 данные не отсортированы. Это значит что при создании индекса должен быть создан уровень листьев (leaf level), содержащий указатели на данные отсортированные по указанному ключу (это уровень, обозначенный страницами с 20 по 23). На Рис.2 указатель представляет собой row ID, который имеет следующий формат: НомерФайла:НомерСтраницы:ПозицияЗаписи. Таким образом ID 1:13:5 указывает пятую запись, тринадцатой страницы в файле номер один. Любой другой уровень индексов называется не лепестковым или промежуточным уровнем. Самый первый уровень индексов является “входной дверью” в индекс и называется корневым. Корневой уровень состоит только из одной страницы и содержит указатели на ключи следующих уровней индекса. Все индексы имеют одинаковую В-tree структуру. SQL Server предлагает к использованию два типа индекса: кластерный (clustered) и некластерный (nonclustered). Разница между этими типами индексов будет освещена ниже.
В RDBMS, понятие “кластерный” имеет много значений, но общая идея этого понятия – рассмотрение двух физических объектов как единую сущность. Например, в области построения сетей, кластер есть группа двух и более серверов, видимых как единая логическая сущность и используется для отказоустойчивости и выравнивания (балансировки) нагрузки. В SQL Server кластер означает индекс, смешанный с данными. Таблица представляет собой часть индекса, или индекс представляет собой часть таблицы в зависимости от вашей точки зрения. 
Рис.3 Кластерный индекс Фактически, для кластерного индекса leaf level этого индекса есть сами страницы таблицы с данными. Рис.3 показывает кластерный индекс, созданный по полю CustomerID таблицы Customers. Поскольку сами данные таблицы являются частью индекса, то очевидно что для таблицы может быть создан только один кластерный индекс. В SQL Server кластерный индекс является уникальным индексом по определению. Это означает что все ключи записей должны быть уникальные. Если существуют записи с одинаковыми значениями, SQL Server делает их уникальными, добавляя номера из внутреннего (невидимого снаружи) счетчика. Рис. 4 иллюстрирует этот случай. Почему архитектура SQL Server имеет такую функциональность? Ответ прост – потому что есть только два способа найти необходимую запись: по row ID или по ключу кластерного индекса. Row ID используется когда нет кластерного индекса, и кластерный индекс – в противном случае. На Рис.3 ключ кластерного индекса построен по полю CustomerID, которое по определению имеет только уникальные значения. На Рис.4, например, предположим что кластерный ключ был изменен на поле City. Более чем один клиент может существовать в каждом городе. Например, есть 4 клиента в Mexico. Таким образом SQL Server добавит номера счетчика к дублирующимся записям Mexico, делая эти записи уникальными. Если еще одно значение Mexico будет добавлено в таблицу, его кластерный ключ будет Mexico4. Первое дублирующееся значение не имеет значения счетчика. Счетчик начинается с первого повторения значения. 
Рис.4 Кластерный индекс Номер, добавляемый к дублирующимся значениям является результатом работы автоматического счетчика. Но добавляемое значение не будет видно ни конечному пользователю, ни разработчику. Оно просто имеет внутреннюю поддержку для идентификации записи. Запомните правило, когда работаете с SQL Server: запись может быть найдена либо по row ID либо по кластерному ключу. Это важное замечание, поскольку row ID или кластерный ключ будут сохраняться внутри не кластерного индекса и использоваться для получения реальных данных из записей.
Некластерный индекс имеет leaf level, который содержит все ключевые значения, отсортированные в том виде как был определен индекс, вместе с row ID или кластерным ключом. Сами данные не хранятся в индексе и вынимаются из таблицы, используя row ID или ключ кластерного индекса. Рис.5 иллюстрирует некластерный индекс по полю City. Как видно в указанном примере, таблица не имеет кластерного индекса потому что ссылкой на запись является row ID. 
Рис.5 Некластерный индекс Кластерный индекс использует row locator и он является частью не кластерного индекса на leaf level. Этот факт приводит к важному правилу SQL Server: создавайте кластерные ключи как можно более короткими. Каждый некластерный индекс будет использовать значения кластерного индекса. Следовательно увеличение размера кластерного индекса приводит к многократному увеличению требований по памяти для всех не кластерных индексов. Последнее приводит к увеличению времени на процессы чтения, сканирования данных и, как следствие, к снижению общей производительности системы. Еще одно наблюдение – увеличение длины ключа приводит к снижению количества записей индекса, способных уместиться в пределах одной страницы, как следствие – к увеличению операций чтения-записи. Рис.6 показывает как строится некластерный индекс поверх кластерного. 
Рис 6 Некластерный индекс поверх кластерного ПРОДОЛЖЕНИЕ СЛЕДУЕТ Отечественные статьи
Пример использования
механизмов аутентификации и авторизации при построении многоуровневого
приложения
Новые технические статьи Microsoft
BUG:
Commerce Server Cannot Connect to a Clustered Named Instance Through a Firewall
Another Disaster (Almost)
Самые популярные темы недели
Междумордие
Transactional
replication and foreign keys - Гуру, ау
|
| #126<< #127 |
| http://subscribe.ru/
E-mail: ask@subscribe.ru |
Отписаться
Убрать рекламу |
| В избранное | ||
