(Возврат на основную страницу)
Editorial
Майкл Оти
Детка за миллиард: Sun и MySQL
Programming
Как мне создать мощную и гибкую версию sp_who2 с использованием имеющихся в SQL Server средств DMV?
Эрик Петерсон
Запросы «тормозят»? Попробуйте дефрагментировать
Эрланд Соммарског
Условия динамического поиска в T-SQL. Часть 1
DB Design & Warehousing
Ицик Бен-Ган
Разоблачение мифов о временных объектах. Часть 2
Детка за миллиард: Sun и MySQL
Приобретение Sun Technologies СУБД MySQL показывает, что компания движется от аппаратной базы в сторону развития крупного бизнеса продажи ПО открытого кода.
По меньшей мере в течение последней декады (целая эпоха по меркам ITиндустрии), основными игроками на рынке СУБД выступали Oracle, IBM и Microsoft — именно в таком порядке. В 2006 году Гартнер выпустила исследование рынка СУБД, где MySQL было отведено место в конце списка, вместе со всеми остальными СУБД открытого кода. Все вместе, они делили 7,9 % рынка. Теперь же, с приобретением в январе 2008 года быстро приобретающей популярность MySQL Sun Microsystems способна поменять расклад на рынке СУБД. Некоторые специалисты подвергают сомнению правильность решения Sun, утверждая, что Sun не сможет заработать скольконибудь заметных денег на ПО открытого кода и лучше бы ей приобрести устоявшийся коммерческий программный продукт, если уж она хочет войти на рынок СУБД. Но я полагаю, что комбинация Sun и MySQL способна создать платформу разработки, которую остальные поставщики СУБД просто не смогут игнорировать.
По крайней мере MySQL — совсем неплохое вложение средств для Sun. Хотя MySQL, как СУБД и является свободно распространяемой (в определенном смысле), как и остальные продукты открытого кода, она не является совершенно бесплатной. Как компания MySQL делает деньги на технической поддержке корпоративных заказчиков и продуктов управления самой СУБД. В целом рынок MySQL достаточно велик и оценивается в 8 миллионов активных инсталляций MySQL. Кроме того, продажи MySQL растут, достигая стабильного, хотя может быть и не очень впечатляющего прироста 100 % в год. Очевидно, что Sun учитывает весьма обширную базу пользователей, как одно из важных приобретений.
Очевидно, что прибыль не является основным мотивирующим фактором приобретения MySQL. Я вижу приобретение MySQL как средство позиционирования Sun на будущее. Желание Sun вложить 1 миллиард долларов в приобретение MySQL говорит о стратегическом направлении мысли руководителей компании. Хотя Sun и является в основном поставщиком «железа», очевидно, что она старается отойти от собственного железа. Не так давно Sun начала поддерживать x64 и даже предлагает несколько моделей серверов на базе AMD с Windows Server 2003 в качестве одного из вариантов ОС. Заплатив свой миллиард, Sun немедленно появляется в виде крупного поставщика ПО открытого кода на ОС открытого кода, Windows Server и собственной Solaris.
С точки зрения разработчиков и платформы, приобретение MySQL — отличное дополнение к Java. Уже давно Java установился как предпочтительный инструмент разработки под Linux, и его многоплатформенность выглядит очень привлекательной для многих разработчиков, работающих с ПО открытого кода. Учитывая, что MySQL удерживает 49 % СУБД среди аналогичных продуктов открытого кода, она является предпочтительной для большинства проектов, использующих Linux и другие проекты открытого кода. Сочетание Java и MySQL представляет собой эквивалент Microsoft .NET Framework и SQL Server только среди средств открытого кода.
Так что же приобретение Sun MySQL может означать для SQL Server и рынка СУБД в целом? Вопервых, это приобретение способно узаконить MySQL как СУБД класса предприятия. Несомненно то, что MySQL достаточно известна и для несущественных приложений является предпочтительной, более того, даже некоторые крупные компании, такие как Google, Yahoo! и craigslist.com используют MySQL. Тем не менее, MySQL никогда не представляла угрозы для крупных игроков в корпоративных областях. После перехода под крыло Sun MySQL ситуация изменится, хотя изменения скорее коснутся Oracle, чем SQL Server. Это объясняется тем, Sun — один из основных поставщиков серверов для Oracle и владение MySQL может снизить уровень поддержки Oracle. При этом MySQL попрежнему будет составлять жесткую конкуренцию SQL Server Express, хотя сомнительная интеграция с .NET и отсутствие инструментария для business intelligence (BI) скорее всего не даст ей серьезно конкурировать с коммерческой версией SQL Server.
Как мне создать мощную и гибкую версию sp_who2 с использованием имеющихся в SQL Server средств DMV?
DOWNLOAD
Частью задания от Microsoft было предложить идеи о «sp_who3... как вывести sp_who2 на новый уровень использования SQL Server 2005 DMV (Dynamic Management Views — Динамическое Административное Представление)». Вот чего, на наш взгляд, не хватает в sp_who и sp_who2:
• они не поддерживают упорядочивание;
• кроме «активного», другие фильтры не поддерживаются (например, фильтр по spid, названию базы данных, имени хоста, IPадресу, названию программы и SQLкоманде);
• параметр @loginame для sp_who2 не работает как «разрекламировано»;
• теряется много такой полезной информации, как разделение ввода/вывода между чтением и записью, отображение использования памяти, добавление DBCC INPUTBUFFERрезультатов и другие данные, как, например, счетчик строк, количество транзакций и количество блокировок.
Так что мы решили написать свою собственную процедуру; надо сказать, решили еще задолго до того, как поступило это предложение. В следующей процедуре мы учли все эти ограничения и сделали ее более совместимой со следующими версиями путем искоренения ссылок на sysprocesses, syslockinfo и других объектов, предположительно запретных.
Запросы «тормозят»? Попробуйте дефрагментировать
DOWNLOAD
Вам когданибудь жаловались пользователи, что запросы стали выполняться дольше, хотя в них ничего не поменялось? Если да, то велика вероятность, что индексы в таблице, к которой обращается запрос, стали фрагментированными. Решение этой проблемы — двухэтапный процесс. Вопервых, вам необходимо определить, какие индексы стали фрагментированными. Вовторых, вам необходимо дефрагментировать эти индексы. Я написал хранимую процедуру, cspDefragIndexes, которая автоматически выполняет оба шага. Вы можете использовать cspDefragIndexes для анализа всех индексов в отдельно взятой таблице или во всей базе данных, чтобы определить, действительно ли они фрагментированы. Также вы можете использовать cspDefragIndexes для дефрагментации таблицы или базы данных. Эта процедура даже обновляет все статистические данные.
Хранимую процедуру cspDefragIndexes можно загрузить на сайте журнала. Чтобы выполнить процедуру, необходимо определить два параметра. Первый параметр — это имя таблицы. Или вы можете указать «ALL» для работы со всеми таблицами в базе. Второй параметр указывает, должна ли процедура отобразить индексы и процент их фрагментации (задаем значение «N») или дефрагментировать индексы (значение «Y»).
Например, вы хотите узнать, насколько фрагментированы индексы таблицы Customer, тогда нужно выполнить команду cspDefragIndexes ‘Customer’, ‘N’
Условия динамического поиска в T-SQL. Часть 1
DOWNLOAD
Введение
Обычным требованием для информационной системы является наличие функции (или нескольких функций), с помощью которой пользователи могут производить поиск данных по возможным критериям. Это серьезный вызов, потому что необходимо обеспечить не только необходимые выходные данные, но и уложиться в определенные временные рамки, по крайней мере, для общеупотребительного поиска. И, наконец, код должен быть управляемым, в расчете на новые задачи и требования.
В данной статье я рассмотрю различные способы решения этой проблемы. Существует две основных альтернативы: динамический SQL и статический SQL. Существуют также гибридные решения, в которых используются оба подхода. Когда количество возможных условий поиска более чем достаточное, динамический SQL оказывается более эффективным по показателям производительности, разработки и поддержки. В SQL 2000 и более ранних версиях, чтобы использовать динамический SQL в чистом виде, вам необходимо дать пользователям явное разрешение для использования SELECT в необходимых таблицах, а это далеко не всегда можно разрешить. В SQL 2005 существует несколько подходов к этому вопросу.
Сначала я рассмотрю использование динамического SQL и подскажу, как избежать нескольких опасностей. Затем я опишу технику использования статического SQL и предложу вам набор методов и приемов, которые вы сможете комбинировать для осуществления вашего поиска. И, наконец, я представлю вам два гибридных решения, в которых проблема разрешений решается с помощью использования и динамического, и статического SQL.
Данный текст был написан для версии SQL Server от SQL 7 и выше.
Разоблачение мифов о временных объектах. Часть 2
Конкретные примеры могут помочь понять разницу между типами объектов
Ицик БенГан (Itzik BenGan)
* См. Ицик БенГан. Разоблачение мифов о временных объектах. Часть 1 // SQL Server для профессионалов. 2008. №4.
DOWNLOAD
В предыдущей статье «Разоблачение мифов о временных объектах. Часть 1», я начал разговор о временных объектах, в котором упомянул временные таблицы, табличные переменные и табличные выражения. Я дал обзор каждого типа объектов, описал свойства и дал рекомендации, в каких случаях их использовать. В этой статье, чтобы прояснить смысл сказанного, я углублюсь в обсуждение темы путем рассмотрения конкретных примеров. Перед чтением этой статьи убедитесь, что вы, в качестве подготовки, прочитали предыдущую статью. Информация в указанной статье является важной предварительным условием для понятия примеров, приведенных в данной статье.
(Возврат на основную страницу)