(Возврат на основную страницу)
Признание
Примерно лет 12 назад я работал в информационном центре. В многоэтажном здании нас сидело несколько сотен. Только на одном этаже была, наверное, пара сотен человек. Однажды я ввязался в спор с двумя коллегами на тему преимуществ «горячих клавиш» по сравнению с мышью. Я считал, что все сотрудники должны освоить использование «горячих клавиш», они же полагали, что в этом нет необходимости.
Пару дней спустя я прошелся по всему этажу и стащил шарики из всех мышек. На всем этаже не осталось ни одной работоспособной мыши.
На следующий день я наблюдал, как все сотрудники службы технической поддержки оказались практически беспомощными, так как они никогда не пытались освоить даже самые простые комбинации «горячих клавиш». Посыпались письма: «кто взял шарики», «очень смешно, теперь верните» и т. д. Сначала письма были спокойными, но по мере развития ситуации раздражение нарастало. Примерно часа через четыре они начали обмениваться таблицами «горячих клавиш». И это понятно, они даже почту без мыши не могли открыть. Так что в течение пары дней работа шли довольно медленно, но потом они освоились и даже не оченьто горевали. Примерно через неделю, когда работоспособность мышей была восстановлена, я заметил, что коекто попрежнему работает с использованием «горячих клавиш»... и среди них были те самые два моих коллеги, с которыми я изначально затеял спор. Они обнаружили, что гораздо удобнее работать, если руки не мечутся по столу.
Ну, так вот, я не собираюсь читать никому нотации, но мне кажется, что в итоге все получилось весьма удачно. И упоминаю я про это только потому, что некоторое время назад я нашел в темном углу гаража целый мешок мышиных шариков и меня разобрал смех при воспоминании об этом случае.
Может показаться странным, но я до сих пор оцениваю многие приложения по тому, как много функциональности в них реализуется через управление «горячими клавишами». То есть думали ли разработчики о продуктивности моей работы, заставляя елозить руками туда и сюда?
Как бы то ни было, мне кажется, что история должна вам понравиться.
Интеллектуальная обработка данных и хранилищ данных в SQL Server 2005. Часть 3
Данная статья представляет обзор инструментов, которые вы сможете использовать при создании аналитического приложения, и уделяет особое внимание новой функциональности, упрощающей разработку и управление сложными системами интеллектуальной обработки данных.
Системы интеллектуальной обработки данных реального времени
Хранилища данных и приложения интеллектуальной обработки данных традиционно использовали «устаревшие» данные, данные с большой задержкой обновления — то есть данные, обновляемые раз в месяц, неделю или день. Традиционалисты считают, что система интеллектуальной обработки данных реального времени (real time BI) вообще является сочетанием несочетаемого — для принятия стратегических решений не требуются данные, обновляемые чаще раза в сутки. Что упускают эти люди, так это то, что системы интеллектуальной обработки данных должны быть доступны всем на предприятии, а не только нескольким аналитикам и менеджерам для принятия стратегических и тактических решений. Оперативная интеллектуальная обработка данных требует данных с небольшой задержкой обновления.
В Analysis Services 2005 представлены новые возможности обработки для оперативной интеллектуальной обработки данных. В Analysis Services 2000 кубы — независимо от варианта их хранения или стратегии использования разделов — обрабатывались с помощью модели Pull. В Analysis Services запускался процесс, который искал новую информацию в базеисточнике данных, обрабатывал и при необходимости сохранял детализированные данные, рассчитывал и сохранял агрегаты.
Модель Pull попрежнему поддерживается в Analysis Services 2005, но были добавлены еще две модели, которые особенно полезны для интеллектуальной обработки данных с небольшой задержкой обновления:
• Получение (push) данных из канала Integration Services или пользовательского приложения. Данные могут напрямую попадать в раздел Analysis Services из канала пакета Integration Services, без промежуточного сохранения. Это может использоваться для уменьшения задержки обновления и затрат на хранение аналитических данных.
• Управление кубом как упреждающим кешем, без административного вмешательства, для поддержания в кеше заранее определенных уровня задержки обновления данных и характеристик производительности.
Производительность выполнения запросов в многомерном хранилище Analysis Services выше, чем в реляционном хранилище. Если кратко, то запросы выполняются быстрее всего в многомерном (MOLAP) хранилище. Обратной стороной этого является задержка обновления данных: многомерное хранилище является снимком реляционного источника данных. Основным преимуществом технологии упреждающего кеширования является максимизация производительности выполнения запросов и минимизация задержки обновления данных и затрат на администрирование.
Возможности упреждающего кеширования упрощают процесс управления устаревшими данными. Когда происходит транзакция в базеисточнике данных, например новая транзакция по члену измерения или по факту, существующий кеш устаревает. Упреждающее кеширование обеспечивает настраиваемый механизм для определения того, как часто нужно пересоздавать многомерный кеш, как выполняются запросы во время перестройки кеша, а также для запуска процесса перестройки кеша без административного вмешательства.
Упреждающее кеширование дает возможность устанавливать у куба автоматическое обновление его многомерного кеша при возникновении транзакции. Хотя Analysis Services обрабатывает данные очень быстро, обработка всетаки занимает определенное время. При необходимости ваша конфигурация упреждающего кеширования может автоматически перенаправлять запросы в реляционное хранилище, если обновление упреждающего кеша еще не закончено.
Когда вы разрабатываете конфигурацию вашего упреждающего кеша, важно помнить, что упреждающее кеширование настраивается для каждого многомерного раздела. Если раздел содержит данные за небольшой период времени, например за час, то процесс обновления кеша происходит очень быстро. Наиболее сложные конфигурации упреждающего кеширования зависят от сообщения (notification), отправляемого реляционной базой данных в Analysis Services, о том, что произошло изменение данных. Реляционная база данных Microsoft SQL Server поддерживает такие сообщения. Для баз данных, которые не отправляют сообщения, Analysis Services может быть настроен на опрос базы данных на наличие изменений с помощью заранее созданного запроса.
Взламываем SQL Server. Часть 5
Меры противодействия внедрению SQLкода
Крепитесь, вас ждут неприятные новости. Если ваши приложения подвержены внедрению SQLкода, нет критического исправления, сервисного пакета или быстрого способа устранить проблему, чтобы защититься. Вместо этого вы должны рассчитывать на такие защитные механизмы, как продуманная архитектура, процессы разработки и пересмотр кода. Хотя некоторые инструменты заявляют, что способны отслеживать проблемы с внедрением SQLкода, ни один из них пока не может в достаточной степени застраховать вас от них.
Вот несколько методов, которые помогут при борьбе с внедрением кода:
• Замените одинарные кавычки двумя одинарными кавычками.
• Проверяйте числовые данные.
• Используйте хранимые процедуры.
• Избегайте динамического построения команд, посылаемых SQL Server.
Ссылки
Соответствующие рекомендации, бюллетени безопасности Microsoft и критические исправления:
• MS00092, «Extended Stored Procedure Parameter Parsing Vulnerability» (http://www.microsoft.com/technet/ security/bulletin/MS00092.asp);
• MS00048, «Stored Procedure Permissions Vulnerability» (http://www.microsoft.com/technet/security/bulletin/MS00048.asp);
• MS00014, «SQL Query Abuse Vulnerability» (http://www.microsoft.com/technet/;
• security/bulletin/MS00014.asp).
Бесплатные инструменты:
• sqlpoke http://packetstormsecurity.org/NT/;
• scanners/Sqlpoke.zip;
• sqlbf http://packetstormsecurity.org/;
• Crackers/sqlbf.zip;
• sqldict http://packetstormsecurity.org/Win/;
• sqldict.exe;
• Sqlping http://www.sqlsecurity.com/;
• DesktopDefault.aspx?tabindex=5&tabid=7.
Разнообразные словари для подбора паролей методом грубой силы:
• http://packetstormsecurity.org/ Crackers/wordlists/dictionaries/.
Коммерческие инструменты:
• Encryptionizer http://www.netlib.comISS Database Scanner http://www.iss.netXP_Crypt http://www.activecrypt.com/.
Другие уязвимости SQL Server:
• «SQL Query Method Enables Cached Administrator Connection to be Reused» (http://www.microsoft.com/technet/security/bulletin/MS01032.asp);
• «DTS Password Vulnerability» (http://www.securityfocus.com/bid/);
• 1292 «Microsoft SQL Server 7.0 "Malformed TDS Packet Header" Vulnerability» (http://www.microsoft.com/technet/security/bulletin/fq99059.asp);
• SQL Slammer Worm http://www.cert.org/advisories/;
• CA200304.html.
Табл. 1. Расширенные хранимые процедуры, которые лучше убрать из SQL Server, если они не используются
|
sp_bindsession |
xp_deletemail |
xp_readerrorlog |
|
sp_cursor |
xp_dirtree |
xp_readmail |
|
sp_cursorclose |
xp_dropwebtask |
xp_revokelogin |
|
sp_cursorfetch |
xp_dsninfo |
xp_runwebtask |
|
sp_cursoropen |
xp_enumdsn |
xp_schedulersignal |
|
sp_cursoroption |
xp_enumerrorlogs |
xp_sendmail |
|
sp_getbindtoken |
xp_enumgroups |
xp_servicecontrol |
|
sp_GetMBCSCharLen |
xp_enumqueuedtasks |
xp_snmp_getstate |
|
sp_IsMBCSLeadByte |
xp_eventlog |
xp_snmp_raisetrap |
|
sp_OACreate |
xp_findnextmsg |
xp_sprintf |
|
sp_OADestroy |
xp_fixeddrives |
xp_sqlinventory |
|
sp_OAGetErrorInfo |
xp_getfiledetails |
xp_sqlregister |
|
sp_OAGetProperty |
xp_getnetname |
xp_sqltrace |
|
sp_OAMethod |
xp_grantlogin |
xp_sscanf |
|
sp_OASetProperty |
xp_logevent |
xp_startmail |
|
sp_OAStop |
xp_loginconfig |
xp_stopmail |
|
sp_replcmds |
xp_logininfo |
xp_subdirs |
|
sp_replcounters |
xp_makewebtask |
xp_unc_to_drive |
|
sp_repldone |
xp_msver |
xp_regaddmultistring |
|
sp_replflush |
xp_perfend |
xp_regdeletekey |
|
sp_replstatus |
xp_perfmonitor |
xp_regdeletevalue |
|
sp_repltrans |
xp_perfsample |
xp_regenumvalues |
|
sp_sdidebug |
xp_perfstart |
xp_regread |
|
|
xp_availablemedia |
xp_regremovemultistring |
|
|
xp_cmdshell |
xp_regwrite |
Исследуем функцию NewSequentialID() в SQL Server 2005
Преимущества и недостатки использования GUID в качестве первичных ключей широко известны. Но, несмотря на недостатки этого подхода (см. второй раздел этой статьи, написанный Маркусом Макиннесом (Marcus Mac Innes)), некоторые все же используют его, потому что он обеспечивает выполнение специфических бизнес-требований (эти идентификаторы уникальны в рамках нескольких серверов).
К счастью, в SQL Server 2005 появился новый способ создания GUID, который генерирует их последовательно. Это дает возможность применения последовательных идентификаторов (как при использовании IDENTITY) в сочетании с преимуществами, основанными на уникальности GUID.
Есть несколько очень важных моментов, касающихся этой функции. Вот что говорится о ней в SQL Server 2005 Books Online (http://msdn.microsoft.com/enus/library/ms189786.aspx):
«Создает GUID, который больше любого другого GUID, сгенерированного до этого на данном компьютере».
«Важно: если для вас важна приватность, не пользуйтесь этой функцией, поскольку она позволяет угадать значение следующего сгенерированного GUID и получить доступ к ассоциированным с ним данным».
«Сгенерированные с помощью NEWSEQUENTIALID() идентификаторы GUID уникальны только в рамках данного компьютера, если на компьютере не установлен сетевой адаптер».
«NEWSEQUENTIALID() можно использовать для генерации идентификаторов GUID с целью разрешения конфликтов страниц на листовом уровне индексов».
Внимательно прочитайте первое предложение, поскольку некоторые интерпретируют его неверно. Оно означает, что создаваемые GUID могут совпадать с идентификаторами, сгенерированными на другой машине, только если на вашем компьютере нет сетевого адаптера.
Давайте посмотрим, как это работает, на примере GUID, сгенерированных на двух разных компьютерах
Ссылки
1. Блог (http://www.styledesign.biz/weblogs/macinnesm/archive/2004/09/14.aspx).
2. SQL Server 2005 Books Online (http://msdn.microsoft.com/enus/library/ms189786.aspx).
3. SQL Server 2005 Books Online (http://msdn.microsoft.com/enus/library/ms189786.aspx).
4. The Cost of GUIDs as Primary Keys (http://www.informit.com/articles/article.asp?p=25862&seqNum=1&rl=1).
5. Performance Effects of Using GUIDs as Primary Keys (http://www.sqlmag.com/articles/index.cfm?articleid=46821&).
6. Guid Primary Keys are Revolutionised in SQL Server 2005 (http://www.styledesign.biz/weblogs/macinnesm/archive/2004/09/14.aspx).
7. Identity vs GUIDs vs COMB GUIDs vs NewSequentialID? (http://groups.google.com/group/microsoft.public.sqlserver.programming/browse_thread/thread/73ba34c9d1b0cd53/).
8. Surrogate Key vs. Natural Key (http://www.sqlmag.com/Article/ArticleID/23449/sql_server_23449.html).
9. Practical Database Design, Part 1 (http://www.ibm.com/developerworks/web/library/wadbdsgn1.html).
10. New SQL Server 2005 Feature: newsequentialid() (http://spaces.msn.com/drsql/blog/cns!80677FB08B3162E4!416.entry).
11. Using NewSequentialID Instead of NewID (http://www.sqlmag.com/Article/ArticleID/49960/sql_server_49960.html).
(Возврат на основную страницу)