(Возврат на основную страницу)
Джон Ханибол (Jon Honeyball)
В последнее время появляется все больше свидетельств того, что Microsoft собирается в корне изменить организацию хранения данных в своих ОС, вернувшись к унифицированной модели хранения данных Cairo — супер-ОС, созданной на основе технологии Windows NT, выход которой, обещанный в начале 90-х, так и не состоялся.
Как я не раз утверждал, Microsoft необходимо довести до логического конца историю с хранением данных: создано слишком много способов хранения сравнительно сходных элементов, и давно пора все упростить.
Грядущие преобразования будут определять характер основных изменений в ближайшие 4 – 5 лет эволюции ОС Windows. С точки зрения пользователя, эти изменения будут минимальны или вовсе неощутимы: Microsoft умеет вносить изменения так, чтобы с этим справилось большинство пользователей ее продуктов.
с технической же стороны изменения обещают быть довольно глубокими. Они коснутся, главным образом, четырех областей: Active Directory, SQL Server, Exchange Server и, собственно, файловой системы (ФС). Как видно, изменения в продуктах BackOffice тесно переплетаются с изменениями в базовой ОС.
Согласно заявлению Microsoft, сделанному на проводившейся недавно в Барселоне конференции TechEd, одной из конструкторских задач в Yukon (кодовое название следующей версии SQL Server) было улучшение эффективности обработки частично структурированных и неструктурированных данных. Сейчас уровень производительности SQL Server как хранилища данных на основе РСУБД не подвергается сомнению — результаты тестов TPCC и SAP свидетельствуют о лидерстве Microsoft по такому параметру, как скорость сервера. Но SQL Server никогда не был оптимизирован для хранения данных, структурированных случайным образом. Соответственно, сделанное заявление жизненно важно для Microsoft, поскольку, по слухам, в Kodiak (так назван следующий основной выпуск Exchange Server) вместо JET/EDB/ESE, используемого в настоящее время в качестве механизма хранилища данных, будет использован Yukon. В этом случае Yukon придется поддерживать экстраординарную гибкость при хранении данных, которую сейчас обеспечивает Exchange Server.
Yukon станет первым полномасштабным сервером от Microsoft, реально построенным на основе технологии .NET. Иными словами, это будет первый механизм BackOffice, созданный с использованием Visual Studio .NET и Common Runtime. Это не сюрприз, поскольку Microsoft призналась, что Transact SQL (TSQL) войдет в семейство языков, поддерживаемых технологией .NET, наряду с Visual Basic и C#. Иными словами, Common Runtime станет неотъемлемым компонентом структуры механизма Yukon, и на любом из языков .NET можно будет писать хранимые процедуры, тесно взаимодействующие с ядром механизма Yukon.
Также стоит отметить, что в настоящее время кураторами групп разработчиков Exchange Server и SQL Server в Microsoft являются одни и те же ключевые персоны, что ясно указывает на глубокие перемены, происходящие в области хранения данных.
Однако отказ от использования хранилища данных на основе JET/ESE в Exchange Server приведет к ряду серьезных последствий. Для хранения данных Active Directory в Windows 2000 и Windows XP используется механизм JET/ESE. В этом нет ничего неожиданного, поскольку Active Directory — это «повзрослевшее дитя» службы каталога, которая использовалась в Exchange Server 4.0/5.0/5.5: Active Directory возникла на основе JET и осталась с этим механизмом хранения данных вплоть до выхода Windows 2000.
Microsoft сейчас наотрез отказывается обсуждать переход Active Directory с JET/ESE на SQL Server даже в частных разговорах. Это, вероятно, самое уязвимое место в области Windows Server. Причина ясна: в конце этого года начнутся поставки Windows XP Server, в которой будет продолжено использование JET/ESE, хоть и в последний раз. Какие-либо шаги в направлении перехода Active Directory на использование механизма SQL Server Yukon мы увидим лишь в следующем выпуске Windows Server с кодовым именем Longhorn, который ожидается к середине 2003 года. Очевидно, Microsoft не хочет, чтобы хоть что-то помешало выходу в свет Windows XP Server, таким образом, конец истории с механизмом хранения данных откладывается на 2002 год. Можно совершенно определенно сказать, что до конца нынешнего года в этой области не ожидается никаких дискуссий.
Можно считать это концом истории, но мне кажется, что Microsoft планирует более широкие и глубокие перемены. Технология «Диск M:» в Exchange Server 2000 позволяет монтировать механизмы хранения данных, назначая им букву диска, и работать с ними, как если бы они были хранилищами на основе ФС. Можно входить в дерево и делать свой почтовый ящик разделяемым на уровне ФС, используя при этом все обычные механизмы доступа и безопасности. Все это работает благодаря драйверу, который подключается, с одной стороны, поверх механизма хранения данных JET/ESE, а с другой стороны — к нижнему уровню стека драйверов Windows 2000.
Технология Диск M: очень важна для Microsoft, которая предлагает в настоящее время чрезвычайно мощную реплицируемую ФС, объединяющую серверы под управлением Exchange 2000. Например, если разместить какие-либо данные на сервере лондонского офиса, эти данные автоматически появятся на сервере в Нью-Йорке, при этом планы и правила репликации контролируют системные администраторы. Это позволяет очень быстро опубликовывать данные через IIS 5.0: для превращения общей папки (Public Folder) в Web-узел для интра-, экстра- или Интернета достаточно одного щелчка мышью. Кроме того, имеется ряд дополнительных механизмов управления документами, возможности которых превышают возможности NTFS.
В ранних бета-версиях Windows 2000 был сервис под названием NSS (Native Storage Services), поддерживавший разложение документов Office на потоки NTFS, что позволяло более эффективно хранить их в ФС NTFS. В более поздних бета-версиях NSS исчез; его обещанное возвращение в Windows XP так и не состоялось. NSS был удален из-за конфликта с иерархической файловой системой (Hierarchical Filing System, HFS) Windows 2000. HFS работала с целыми файлами, тогда как в основе NSS лежали операции на субфайловом уровне.
Исходя из того, что NSS до сих пор числится «пропавшим без вести» в совокупности с работой, выполненной по технологии Диск M: и ассоциированным возможностям индексирования, а также судя по первым этапам разработки Tahoe, совершенно ясно, что Microsoft больше не собирается заниматься серьезными разработками на основе NTFS.
мне кажется, что Microsoft собирается реализовать основой переход на новую технологию хранения данных в Blackcomb (новом выпуске Windows XP, ожидаемом в 2004 – 2005). Вышедший и стабилизировавшийся к тому времени Yukon станет механизмом хранения данных для Kodiak. Active Directory также будет использовать механизм хранения данных на основе Yukon, а технология Диск M: по-прежнему будет представлять большую важность для корпоративных пользователей.
На этом этапе Microsoft перевернула с ног на голову всю модель NTFS/SQL Server: вместо того, чтобы использовать для хранения файлов NTFS, SQL Server сам становится базовым механизмом хранения, а NTFS — API-совместимым драйвером механизма хранения, каким сегодня является Диск М:. Иначе говоря, при включении машины будет загружаться SQL Server, а NTFS останется как устаревший API для поддержания преемственной совместимости с приложениями, которым по-прежнему требуется манипулировать файлами через API ФС.
Возможностей для этого предостаточно. После окончательного отмирания реального режима и 16-разрядного кода в результате «кончины» Windows 98/ME и пришествия Windows XP, Microsoft получила возможность использовать загрузочный код любого размера. Таким образом, теперь встроенное хранилище данных вовсе не обязательно должно быть NTFS, так же легко им может быть и SQL Server, запускающийся как встроенное хранилище данных, а драйвер NTFS при этом используется как сервис. Для настольных компьютеров и лэптопов (laptop) эту роль может выполнять MSDE, как сейчас в облегченных редакциях SQL Server для этих машин.
Эти события повлекут за собой глубокие изменения. Поскольку все данные теперь будет расположены в едином хранилище, станет возможно работать с любыми данными, как будто все они принадлежат к одному типу. Все запросы могут быть «в процессе», что будет работать намного быстрее, чем мешанина запросов, обращенных к данным из различных хранилищ, имеющая место в настоящее время. Производительность серверов и рабочих станций в 2005 будет куда больше, чем сейчас, особенно в 64-разрядном мире. Таким образом, исполнение огромных запросов к унифицированным хранилищам станет абсолютно возможным, а для пользователя все станет предельно просто: запрос типа «найди мне всю информацию о проекте Х, в группу менеджеров которого входят Фред и Эмили» теперь не вызывает улыбку, более того, English Query — это устоявшаяся тех- нология в группе продуктов SQL Server.
С исторической точки зрения можно сказать, что мы действительно являемся свидетелями возвращения Cairo. Microsoft обещала, что в этой ОС будет нормальная служба каталога, обмен сообщениями, межмашинное взаимодействие, гибкий и настраиваемый пользовательский интерфейс, а также унифицированное хранилище данных. Первое дает Active Directory, второе — Exchange Server, третье — Common Runtime/SOAP/XML, четвертое — HTML/XML/XSL/IE, наконец, пятое — производные от Yukon механизмы.
Так что Cairo возвращается!
Джозеф Финсел (Josef Finsel)
SQL Server Database Maintenance Plan не позволяет инсталлировать план обслуживания вместе с БД, я предлагаю решение, которое это делает.
Планы обслуживания существенно облегчат Вам жизнь при помощи автоматизирования рутинных функций администрирования БД. План обслуживания дает возможность постоянно получать статистику обновлений сервера, гарантируя оптимизацию истинных запросов. Кроме того, планы обслуживания позволяют регулярно проверять целостность БД, и, что самое важное, автоматизировать резервирование файлов как самой БД, так и журнала транзакций.
Вам потребуется: SQL Server 7.0 или 2000
При помощи мастера Database Maintenance Plan Wizard, который входит в Microsoft SQL Server, можно за несколько минут без труда подготовить общий план обслуживания наиболее важных БД. К сожалению, этот мастер не поможет создать план, который устанавливал бы БД. Это придется сделать самостоятельно, что довольно сложно и требует работы с системными таблицами и другими «секретными» данными.
Для начала я опишу план обслуживания, затем более подробно остановлюсь на этапах его создания, который включает установку вместе с БД. Надеюсь, урок, извлеченный из моих ошибок, поможет вам легко и быстро создать собственный план обслуживания.
Майкл Амундсен (Michael C. Amundsen)
Сразу скажу, что статья не имеет ничего общего ни с детьми, оставшимися без родителей1 , ни с фотокопиями! Однако она имеет самое непосредственное отношение к задаче, которую выполняет каждый администратор баз данных (database administrator, DBA), достойный носить это звание.
По мере роста размера и сложности любой базы данных (БД), важное значение приобретает регулярная проверка нарушений целостности БД, например, дублирующихся записей в мастер-таблицах (см. ниже), а также потерянных записей, у которых нарушена связь с другими связанными с ними записями (обычно их называют родительской и дочерней).
Чаще всего пользователи просят написать программу, которая решала бы эти задачи, или, если БД находится на крупном сервере, один или несколько администраторов могут написать для этой цели соб-ственные запросы SQL.
В этой статье я покажу, как с помощью Microsoft Visual Basic написать универсальные программы для проверки наличия «зависших» и дублирующихся строк, и они будут работать в любой БД. также вы научитесь создавать вложенные запросы SELECT и использовать конструкцию LEFT JOIN для ускорения обработки данных и повышения эффективности кодирования.
Тай И (Tai Yee)
В статье дается расширенное общее описание репликации в Microsoft SQL Server 7.0. Также описаны способы уменьшения бремени административной работы при поддержании актуальности и согласованности многочисленных копий данных, размещенных на разных узлах.
Репликация в SQL Server 7.0
Попадали ли вы в ситуацию, когда Вам нужно было распространить деловую информацию по сети офисов в филиалах компании без потери согласованности данных? Допустим, штаб-квартира вашей компании расположена в Чикаго, а региональные офисы — в Сиэтле, Финиксе, Атланте и Нью-Йорке. Хотелось бы держать в главном офисе оригинал прайс-листа для всех товаров, которые продает компания, а в каждом региональном офисе — отдельную копию. Более того, в региональных офисах ведется учет принимаемых заказов, а в штаб-квартире должен быть главный архив заказов, принятых в каждом региональном офисе. Один из методов решения этой задачи заключается в ведении списка цен и заказов в штаб-квартире с помощью таблиц. Периодически копии таблицы с прайс-листом распространяются по региональным офисам, а хранящаяся в главном офисе таблица с архивом заказов обновляется сведениями о заказах, которые приходят из каждого регионального офиса. Несмотря на то, что этот метод позволяет решить поставленную задачу по поддержанию в актуальном состоянии данных в каждом офисе, иногда его использование может быть затруднительно. Лучший способ заключается в автоматизации обеспечения согласованности данных, что также позволит уменьшить бремя административной работы.
подобная ситуация называется распределенной средой (distributed environment), в которой существуют многочисленные копии одних и тех же данных, расположенные на разных серверах. Такая среда может быть создана преднамеренно или возникнуть самопроизвольно. По мере роста, добавления новых узлов и увеличения объема хранимой информации управлять распределенной средой становится все труд-нее. В определенный момент, скорее всего, потребуется более легкий способ управления данными в распределенной среде.
Один из способов управления данными в распределенной среде заключается в использовании репликации, поддерживаемой Microsoft SQL Server. В SQL Server термином репликация (replication) обозначают копирование данных БД с одного узла на другой.
Нинья Ингрэм (Ninia Ingram)
в статье разъясняется, как с помощью Microsoft SQL Server 7.0 и Visual Studio 6.0 Database Tools анализировать данные из различных СУБД.
Связанные серверы и функциональность конструкции TOP в Query Designer позволяют:
обращаться к внешним источникам данных OLE DB с помощью технологии связанных серверов;
ограничивать объем возвращаемых данных с помощью конструкции TOP;
повышать производительность и эффектив ность работы БД, используя группы файлов;
генерировать уникальные идентификаторы при помощи типа данных GUID.
Введение
Представьте, что Вам необходимо выявить 50 товаров — важнейших источников прибыли компании. Являясь транснациональной, компания обладает крупными дочерними предприятиями на пяти континентах и главным офисом в Северной Америке. Дочерние предприятия специализируются на различных товарах, и во всех шести офисах, включая главный, используются разные СУБД. Например, в Токио данные хранятся в БД Microsoft Visual FoxPro, в Лондоне используется Oracle, в Буэнос-Айресе — Sybase, в главном офисе, как и в Йоханнесбурге, используется Microsoft SQL Server; наконец, в офисе, расположенном в Канберре, для хранения данных используется система на основе OLE DB, созданная сторонними разработчиками. Как собрать в главном офисе все эти данные для генерации отчета?
Похоже, задача будет не из легких? Нет, если решать ее с помощью новой версии Microsoft SQL Server 7.0 и Microsoft Visual Studio 6.0 Database Tools с использованием связанных серверов и конструкции TOP в Query Designer.
Конечно, в этом случае процедура будет несколько длиннее, но зато будет возможность задействовать преимущества некоторых функций SQL Server 7.0, которые смогут облегчить решение задач, связанных с обработкой корпоративных данных и повысить ее эффективность.
Джеймс Хуонг (James Huang)
Программа массового копирования (Bulk Copy Program, bcp) — это утилита командной строки, которая поставляется со всеми выпусками SQL и является важным компонентом инструментария администратора БД.
Программа массового копирования выполняет перенос данных между существующими таблицами или представлениями БД и хранящимися в ОС файлами данных в формате ASCII или в машинном формате. Общеизвестно, что bcp уступает службе DTS (Data Transformation Service) в богатстве возможностей по обработке данных в различных форматах. Тем не менее она является по-настоящему простым, гибким и мощным инструментом для тех, кому нравится программировать сценарии, обладать полным контролем над процессом преобразования данных и необходимо ускорить перенос данных. Эта утилита служит для переноса данных между БД или просто для импорта данных из текстовых файлов.
Во время работы над последним проектом мне понадобилось перенести БД с данными для разработки на рабочий сервер. Требования были таковы.
1. Необходимо перенести на рабочий сервер часть данных, включая всю информацию о продукте и часть сведений о пользователях, но оставив все результаты тестирования.
2. Занести в рабочую БД список сведений о пользователях. Информация будет взята из устаревшей системы и/или из файлов MS Excel.
3. Необходимо сохранить БД с информацией для разработки, чтобы группа разработчиков могла использовать ее, невзирая на перенос.
Мы решили написать для этого пакетный файл, в котором всю работу выполняла утилита bcp. Результат оказался более чем приемлемым. В этой статье я расскажу о пакетном файле для переноса БД и покажу, как задействовать в нем bcp.
(Возврат на основную страницу)