(Возврат на основную страницу)
Editorial
Шон МакКоун
Access поощряет глупость
Programming
Робин Пэйдж, Фил Фактор
Практикум по строковым функциям SQL. Часть 1
Робин Пэйдж, Фил Фактор
Практикум по строковым массивам
DB Design & Warehousing
Кален Делани
Сокровищница XML Query Plan
Other
Брэд МакГи
Использование монитора производительности. Часть 2
Access поощряет глупость
По каналу HBO мне довелось смотреть передачу «Hacking Democracy» (http://www.hbo.com/docs/programs/hackingdemocracy/synopsis.html). Речь шла об одной даме, которая получила доступ к исходному коду программы, разработанной фирмой Diebold для управления машинами для голосования. Не удивлюсь, если эта история приведет к тому, что Diebold будет номинирована на премию Дарвина в области информатизации. (Премия Дарвина вручается тем, кто приложил наибольшие усилия для улучшения генофонда человечества, найдя самый оригинальный и идиотский способ для самоуничтожения. Подробности см. по адресу http://www.darwinawards.com. — Прим. ред.) Особенно учитывая, что исходники лежали на незащищенном FTPсайте, где их мог взять любой желающий. Когда история раскрылась, владельцы программы стали вопить, что ее у них украли, черт возьми, она там валялась, только подбери! И вообще, как получилось, что такой секретный код оказался доступен любому пользователю Интернета? Хороший вопрос, не так ли? Коль скоро код настолько секретный, никто — подчеркиваю, никто — за пределами компании не должен его видеть. Это их хлеб, хранить его в секрете — одна из главных задач. Но случилось, что случилось, и я мог бы считать это событие одним из глупейших проколов в ITиндустрии за много лет, но так ли это?
То, что обнаружила упомянутая дама, оказалось программой, которую было чрезвычайно просто взломать. При проверке защищенности кода управления машинами для голосования, программист вломился в систему менее чем за десять секунд. Я говорю об этом, потомуто этот факт очень важен. Менее чем десять секунд понадобилось для взлома чрезвычайно секретного приложения.
Естественно, следующий возникающий вопрос звучит так: что же они такое сделали, чтобы сломать систему за десять секунд? Как оказалось, они просто открыли базу данных Access, которую программа устанавливала локально, и вручную поменяли результаты голосования в примитивной таблице, входящей в эту базу данных. Еще одна причина, чтобы высказать мою нелюбовь к Access. Он вдохновляет людей на идиотизм. Кто бы не использовал Access, очевидно, что они не думают о безопасности. Упомянутая история великолепный тому пример. Почему такой важный проект построен на основе приложения, обеспечивающего столь слабый уровень защиты данных? Это позорно и говорит о полной некомпетентности. Создать систему, в которой ктото может напрямую добраться к данным и руками поменять результаты голосования, просто абсурдно.
Понятно, что это не вина Microsoft, что Access использовался в настолько идиотской ситуации, но это и не вина Access. Хотя думаю, вы согласитесь, что Access поощряет такого рода вещи, не так ли? Программисты привыкают использовать простые базы данных Access для своих нужд и не думают о другом инструменте, когда подворачивается настоящий проект. Я даже не могу вспомнить, какая другая СУБД была бы настолько открыта для вмешательства извне. Даже среди бесплатных приложений найдется немало, которые лучше защищены.
Но ведь это как с ограничением на ношение оружия, верно? Убивает не пистолет, убивает человек. Так почему же все стараются избавиться от пистолетов? Да потому что это инструмент для убийства.
Так что глуп не Access, глупы люди. Access — всего лишь инструмент, позволяющий человеку прогрессировать в своей глупости. На самом деле вопрос звучит так: «они выложили код на открытый FTP, потому что они пользуются Access», или «они использовали Access, потому что уже выложили код на FTP»?
Практикум по строковым функциям SQL. Часть 1
DOWNLOAD
Робин и Фил возвращаются к основам и разбирают во всех подробностях основные пользовательские строковые функции TSQL на примере Python. Изобилие примеров и программистских трюков.
Иногда при разработке приложений SQL Server, у вас возникает необходимость произвести некоторые манипуляции со строками. Для новичка строковые функции SQL кажутся довольно непривлекательными, в особенности по сравнению с доступными в Python.
Отличия не только в стиле. Базовые функции TSQL очень мощны, но при просмотре кода не всегда очевидно, что именно они делают. Ведь никто не станет утверждать, что знаменитая функция STUFF интуитивна! (Робин разместила документацию об основных строковых функциях в своем Robyn Page’s SQL Server String Manipulation Workbench.)
При подготовке проекта базы данных всегда лучше начать с набора базовых пользовательских функций для работы со строками, чтобы сделать ваш код более читабельным. И только когда возникают какиелибо проблемы с производительностью, следует использовать встроенные функции вместо своих собственных. В пылу командной разработки, работа идет быстрее, если есть готовые функции для работы со строками.
По некоторой причине нам нравится использовать строковые функции PHP и Python, адаптированные для использования в SQL Server. Мы уже описывали некоторые подпрограммы, позаимствованные из PHP в The TSQL String Array Workbench.
Практикум по строковым массивам
DOWNLOAD
Робин и Фил рассказывают, как использовать основанные на XML массивы для более простой обработки строк в SQL Server 2005/2008, и иллюстрируют эту технику несколькими полезными функциями.
Введение
Работать с массивами в SQL Server 2005 несложно. Существует очень простая техника, которая может использоваться для выполнения необыкновенно сложной обработки строк. Некоторое время назад один наш друг жаловался на скудные возможности SQL Server в обработке строк. Он был PHPпрограммистом. Здесь нет ничего похожего на возможность PHP по обработке массивов, сказал он нам. Взять хотя бы функцию str_replace. Она очень полезна. Она может принимать в качестве параметров даже массивы строк и, таким образом, в состоянии выполнять довольно сложные строковые подстановки.
Это заставило нас задуматься. Мы можем сделать это на SQL Server 2005 очень просто. Довольно просто сделать массивы и на SQL 2000, хотя для этого и придется немного изловчиться. Если мы решим использовать XML, то сможем передавать структуры между процедурами и функциями, так же как массивы.
Сокровищница XML Query-Plan
Некоторые нюансы планов запросов SQL Server 2005 можно увидеть только в XML-версиях планов, которые могут быть получены при помощи функции XML Showplan. В статье «Выявление отсутствующих индексов» мы рассматривали способы определения отсутствующих индексов. Теперь я предлагаю продолжить дискуссию изучением дополнительных примеров особенностей планов запросов, которые присутствуют только XML-выводе планов, а также утилит, которые делают работу с XML-планами запросов существенно приятней.
Использование монитора производительности. Часть 2
При мониторинге вашего сервера помните, что частота, с которой данные утилиты собирают информацию со счетчиков, пропорциональна дополнительным нагрузкам на ваш сервер. Например, обычно интервал замера счетчика для вывода диаграмм в реальном времени в этих двух программах равен одной секунде. Если вы уменьшите интервал до 0,5 секунды, то накладные расходы удвоятся. Но если вы увеличите интервал до пяти секунд, то издержки существенно уменьшатся.
Так с какой же периодичностью следует получать данные со счетчиков производительности? Это зависит от стоящих перед вами целей. В некоторых случаях вам нужно собирать данные в режиме реального времени (каждую секунду), в других — 5, 15, 30 секунд будут подходящими периодами. Главное — не собирать информацию чаще, чем вам на самом деле это нужно. Лично я при сборе данных для вывода в виде диаграммы использую 36секундные интервалы. Практика показала, что этот интервал лучше всего подходит для мониторинга производительности SQLсервера, а также позволяет видеть на экране диаграмму с данными ровно за один час. Конечно, ваша ситуация может отличаться от моей.
При мониторинге SQLсервера с использованием монитора производительности, не запускайте его на том же сервере, производительность которого вы отслеживаете. Вместо этого выполняйте его на другом сервере или рабочей станции и удаленно отслеживайте SQL Server. Выполнение монитора производительности на отслеживаемом сервере приведет к искажению результатов мониторинга.
Развивая эту мысль: не запускайте монитор производительности и профайлер (Profiler) одновременно, даже если они запускаются удаленно. Это приводит к слишком большим накладным расходам и станет причиной некоторого падения производительности вашего SQLсервера. Кроме того, при одновременном выполнении, монитор производительности может выдавать менее точную информацию, изза накладных расходов от выполнения профайлера.
Для получения наиболее точных результатов при мониторинге SLQ Server и других серверных счетчиков, используйте режим журнала монитора производительности. Это позволит вам собрать показания счетчиков за некоторый период времени. Если вы проводите мониторинг за период менее восьми часов, начните со сбора данных каждые 15–60 секунд. SQL Server вычислит среднее значение чтений за этот период времени. Таким образом, чем больший временной интервал вы выберете, тем более «усредненные» данные получите. Обычно это не является проблемой при сборе информации в журнал, так как основной вашей целью в этом случае является определение основных тенденций. Конечно, если вы пытаетесь проанализировать какуюто определенную проблему, возникающую в относительно краткие периоды времени (скажем, менее часа), тогда вы можете захотеть установить временной промежуток в 1 секунду, что позволит вам увидеть и проанализировать всю деятельность в деталях.
Если вы хотите собрать информацию о длительных промежутках времени (таких как неделя или месяц), то вам стоит выбрать временной промежуток от 300 до 600 секунд. Если вы отбираете данные слишком часто, особенно для длинных периодов, количество собранной информации будет огромным. С другой стороны, если отбирать данные слишком редко, то вы можете упустить важную информацию. Вероятно, вам придется поэкспериментировать с различными интервалами, пока не найдете тот, который будет вам наиболее подходить в ваших обстоятельствах.
При использовании системного монитора (монитора производительности) для создания журналов производительности, вы можете сохранять данные журналов в различных файловых форматах. Вместо того, чтобы воспользоваться выбором по умолчанию, вы должны внимательно ознакомиться с теми преимуществами, которыми обладают предлагаемые вам форматы. Ниже представлены краткие выводы по каждому из форматов журнала:
• Текстовый файл — CSV. Хранит данные счетчиков в виде разделенного запятыми ASCIIтекста. Такой формат удобно использовать, если вы решили экспортировать данные в другие приложения для анализа. В большинстве случаев я выбираю этот формат. Использует расширение CSV.
• Текстовый файл — TSV. Хранит данные в виде ASCIIтекста разделенного табуляциями. Этот формат удобно использовать, если вы решили экспортировать данные в программу обработки электронных таблиц. Использует расширение TSV.
• Двоичный файл (используется по умолчанию). Хранит данные последовательно в двоичном виде, который не может быть экспортирован в какойлибо другой формат. Этот вариант следует использовать, только если вам нужна возможность останавливать и запускать мониторинг и заключать всю собранную информацию в один физический файл, и если вам никогда не понадобится экспортировать данные. Использует расширение BLG.
• Двоичный циркулярный файл. Хранит данные в двоичном виде. Данные записываются непрерывно в один файл, перезаписывая предыдущую информацию. Данные не могут быть экспортированы. Использует расширение BLG.
В большинстве случаев для большей гибкости следует выбирать CSV или TSV форматы, так как данные из этих форматов могут быть перенесены в таблицу SQL Server или электронную таблицу Excel для анализа.
Если вы хранили данные в одном формате, но теперь решили использовать другой, вы можете изменить формат файлов в окне «Свойства журнала счетчиков»; перейдите на закладку «Файлы журнала» (Log Files) и выберите «Тип файла журнала» (Log File Type) на нужный вам.
Системный монитор (монитор производительности) позволит вам экспортировать созданные вами диаграммы в виде HTML, что позволит вам легко делиться полученной информацией с другими. Сделать это можно так:
• Сначала создайте диаграмму в системном мониторе. Используя опции системного монитора оформите внешний вид диаграммы по своему вкусу.
• Затем, когда диаграмма готова, щелкните на ней правой кнопкой мыши и выберите «Сохранить как».
• Затем, когда появится диалоговое окно, выберите путь и имя для htmlфайла и сохраните его.
• Когда диаграмма в виде HTML будет сохранена, она может быть просмотрена с помощью любого веббраузера.
Монитор производительности позволяет вам изображать в виде графиков данные со счетчиков от нескольких SQLсерверов одновременно. Эта возможность может быть полезной в некоторых случаях. Например, предположим, что у вас есть два идентичных сервера, на обоих работает SQL Server, но один из них гораздо медленнее другого. Верите или нет, но это вполне обычная проблема на форуме этого сайта. Первый способ определить, почему два одинаковых сервера могут работать с разной производительностью это профилировать их оба одновременно в одном окне просмотра диаграмм монитора производительности. Проблема производительности, конечно, может не относиться к аппаратным средствам сервера, но полученная информация должна ограничить область поиска проблемы.
(Возврат на основную страницу)