(Возврат на основную страницу)
Editorial
Ян Стаффорд (Jan Stafford)
Когда актер от нервного перенапряжения внезапно покрывается испариной, говорят: «пот прошиб». Но испытать это можно не только на сцене.
Любому IT-специалисту, отчаянно пытающемуся восстановить потерянные данные, хорошо знакомо это чувство. «Известно, что восстановление потерянных или удаленных данных — дело ненадежное», — говорит Бен Винстон (Ben Winston), специалист по обеспечению качества продукции компании Winternals Software, Inc., an Austin, тexнический разработчик дополнительных инструментов для Windows NT/2000.
Восстановление данных — трудная задача, поскольку они могли быть потеряны по разным причинам: при дефрагментации диска, разрушении носителей, механических неисправностях и т. д. «К счастью, существуют способы, увеличивающие шансы на успешное восстановление потерянных данных», — говорит Винстон. Ниже приводится список основных действий, которые следует и которые не следует предпринимать.
· Не записывайте дополнительные данные в место, содержащее потерянную информацию. Это увеличивает риск перезаписи данных, которые нужно восстановить.
· Предупреждайте запись данных, выполняемую при инсталляции продукта, при выходе и запуске системы, а также осуществляемую пользователями сети. Это тоже уменьшит шансы перезаписи потерянных данных.
· Не дефрагментируйте жесткий диск после потери данных. Любая дефрагментация сведет шансы на восстановление данных к нулю - кластеры, содержащие потерянные данные могут быть замещены и безвозвратно утеряны.
· Прекратите все виды деятельности системы, но не завершайте ее работу. Выключите плановую дефрагментацию, закройте все приложения, уберите все дискеты и компакт-диски, отсоединитесь от сети. Это уменьшит возможность перезаписи удаленных файлов.
· Восстанавливайте данные в место, отличное от того, которое содержит потерянную информацию. Иначе возможна перезапись данных, ожидающих восстановления.
DB Design & Warehousing
Энди Уоррен (Andy Warren)
В статье «Порочная практика» («Worst Practices» — WP) я представил концепции, противоположные «Оптимальной практике» («Best Practices» — BP). Однако, по моим наблюдениям, они используются еще слишком часто. Рассмотреть их и обсудить, чем же они плохи, — вот цель этой серии публикаций.
Из-за ограничений во времени и других практических вопросов мы не всегда можем применять оптимальные решения, но можно попытаться избежать наиболее грубых ошибок.
В этой статье мне хотелось бы обсудить владение объектами. По-моему, если объект принадлежит кому угодно, кроме DBO, — это порочная практика. Давайте обсудим, почему это так.
Давид Марсо (David Marco)
Михаил Дженнингс (Michael Jennings), Enterprise Warehousing Solutions
Эта статья адаптирована из книги «Построение и управление репозитория метаданных», John Wiley & Sons, ISBN # 0471-355232.
В чем вы видите наиболее трудную проблему, с которой на сегодняшний момент сталкиваются хранилища данных? Качество данных. Плохо, когда качество данных подвергает их риску неправильной интерпретации или когда использование информации из Вашего хранилища может нарушить уровень конфиденциальности Ваших пользователей. А ведь стоит только нарушить пользовательскую конфиденциальность, и прекращение существования Вашей системы становится вопросом времени.
Эти затруднения с качеством данных часто вызваны архитектурой системы, которая не способна идентифицировать «плохие» данные до их загрузки в хранилище данных. А это ведет к катастрофическим потерям времени и средств, которые компании тратят на согласование и проверку информации в хранилище. Вставка специальных тэгов метаданных непосредственно в структуру модели многомерных данных хранилища данных и процессы извлечения, преобразования и загрузки (ИПЗ) исправляют эту ситуацию, предоставляя практические способы измерения качества данных.
Разработчики хранилища данных используют специальные метаданные в качестве метода построения более тесных связей между репозиторием и хранилищем данных. Это достигается включением специальных метаданных непосредственно в структуру хранилища данных и ИПЗ-процессы. Этот способ используется для улучшения структуры и расширения архитектуры хранилища данных с целью оптимизации процесса их приобретения, поддержания активности и возможностей измерения качества. Эти специальные тэги метаданных, в отличие от информации, хранимой в репозитории метаданных, ссылаются на уровень строк хранилища данных. Эта прямая связь метаданных с каждой строкой информации в хранилище данных является ключевым отличием расширения архитектуры с помощью метаданных.
Performance
Бил Глазиано (Bill Graziano)
Я всегда думал, что курсоры медленнее, чем инструкции, основанные на запросах SQL, но не знал, что настолько!
Брад М. МкДжехи (Brad M. McGehee)
В большинстве версий SQL Server повышение производительности ограничено операциями ввода/вывода.
Это происходит по двум причинам. Во-первых, данные, хранящиеся на массиве дисков требуют операций ввода/вывода для восстановления, прежде чем они могут быть помещены в оперативную память для использования. Во вторых, доступ к диску является самым слабым компонентом SQL Server. Объединяясь, оба этих фактора вносят свой вклад в то, что именно операции ввода/вывода становиться самым узким местом в повышении производительности.
Чтобы помочь сократить эту проблему, SQL Server содержит то, что называется буфером кэша. Этот кэш, расположенный в оперативной памяти, используется для хранения последних данных, к которым обращался SQL Server. Сохранение данных в кэше уменьшает частоту обращения SQL Server к дисковым операциям ввода/вывода, что увеличивает производительность SQL Server в целом.
Очевидно, что чем больше размер буфера кэша, тем больше данных SQL Server может хранить в оперативной памяти и тем реже требуется совершать операции ввода/вывода. В идеальном случае все данные БД могли бы храниться в буфере кэша, что значительно сократило бы дисковые операции ввода/вывода и повысило производительность SQL Server. Однако это возможно лишь в некоторых отдельных случаях.
Other
Энди Уоррен (Andy Warren)
Добавление учетных записей, пользователей и ролей с помощью SQL-DMO.
Несколько недель назад мы получили письмо с просьбой помочь добавить учетные записи и пользователей в БД с помощью DMO. В ответе я отослал пример кода, представленный ниже. В ходе обсуждения этого вопроса обнаружились два полезных (хотя, возможно, и очевидных) момента — чтобы эффективно использовать DMO, необходимо знать, как работает SQL, а также нужно выбрать наиболее подходящее средство — DMO, T-SQL или Enterprise Manager. В этой статье мне бы хотелось немного поговорить о том, как работают учетные записи и пользователи, а также обсудить, какое средство наиболее удобно для их добавления в БД.
Энди Уоррен (Andy Warren)
В этой статье на примере нескольких общих сценариев безопасности объясняется, как использовать роль Public и какие проблемы могут быть с этим связаны.
Роль Public эквивалентна NT Everyone и группе Authenticated Users. Каждый пользователь, добавленный в БД, автоматически получает эту роль, включая регистрационную запись c правами Guest (если установить соответствующие права доступа). Это означает, что любое право доступа, которое Вы выдаете роли Public, автоматически распространяется на всех пользователей. Кроме того, ее нельзя удалить. Роль Public существует для того, чтобы облегчить вам жизнь, предоставляя возможность быстро добавлять и удалять разрешения для всех пользователей, не обращая внимания на роли отдельных членов.
Алок Мехта (Alok Mehta)
Даниэль Виллиамс (Daniel Williams)
Эта статья предполагает, что Вы знакомы с SQL, VBA и COM.
С помощью технологий Microsoft, используя любой почтовый клиент, такой как Hotmail, Outlook, Yahoo и даже WAP-телефон, можно вставлять, обновлять, запрашивать и удалять отдельные записи БД. Однако, несмотря на то, что электронная почта является мощным и широко используемым средством, обычно она не интегрирована с приложениями для выполнения каких-либо задач, кроме отсылки напоминаний. Сценарий приложения, описанный в настоящей статье, является программой, которая обновляет информацию БД с помощью почтового клиента. Эта программа использует простую модель данных, однако само решение применимо к любой используемой Вами модели. Она также устраняет необходимость в сложных n-уровневых интернет-приложениях и является дешевым в эксплуатации решением для обеспечения доступа к данным.
Представим, что необходимо разработать приложение для продавцов, которые постоянно запрашивают БД для получения или обновления информации о товарах. Допустим также, что электронная почта — самое распространенная форма общения в Вашей организации. В обычных условиях для запросов БД можно было бы разработать Web-интерфейс с помощью ASP и COM. Но, пока Вы создаете Web-приложение, продавцы не имеют доступа к данным.
В этой статье показан быстрый и легкий способ обеспечения гибкого доступа к БД с помощью электронной почты. При использовании представляемого сценария клиент может запрашивать в БД информацию о товарах в процессе создания Web-приложения. Вы можете ограничить пользователей только торговыми представителями компании или же разрешить доступ покупателям и другим служащим, которым необходимо просматривать и редактировать данные. В этом примере использована модель простой компании, которая продает множество продуктов.
(Возврат на основную страницу)