(Возврат на основную страницу)
Трассировка по умолчанию в SQL Server – сила аудита
производительности и безопасности
Федор Георгиев
Понимание курсоров сервера Fast_Forward в SQL Server
Марк Фридман, август 2009
Копирование схем
Винай Кумар (Vinay Kumar )
Проверка связанных серверов
Марк Хюбер (Mark Huber)
Понимание и использование параллелизма в SQL Server
Пол Уайт
Трассировка по умолчанию в SQL Server – сила аудита
производительности и безопасности
Федор Георгиев
С появлением SQL Server 2005 стало легко проводить трассировку, которую
выполняют по умолчанию на каждом SQL Server снимается простая ненагружающая
трассировка . С ее помощью администратор баз данных получает очень ценную
информацию о запущенном сервере, но она не очень хорошо
документируетсядокументирована. Федор раскрывает много секретов этого процесса и
показывает, как получить отчет по нему.
SQL Server обладает различными инструментами аудита. Все они имеют свои
преимущества и недостатки. Трассировка по умолчанию, появившаяся в SQL Server
2005, имеет большое преимущество вследствие того, что может включаться по
умолчанию, и обычно именно так и используется. Она дает полную информацию об
изменениях в системе.
Сначала ответим на некоторые основные вопросы:
Что такое трассировка по умолчанию? Трассировка по умолчанию в SQL Server
активна по умолчанию и создает минимальную нагрузку, по умолчанию состоящую из
пяти файлов трассировки (.trc), расположенных в каталоге журналов с
установленным SQL Server.
Понимание курсоров сервера Fast_Forward в SQL Server
Марк Фридман, август 2009
Модель серверного курсора у SQL Server это важный инструмент для разработчиков
множества приложений. Курсор Fast_forward весьма популярен в качестве
альтернативы курсорам read_only, forward_only, но их внутренние процессы не
достаточно хорошо известны. И я начну заполнять эти пробелы.
Происхождение
Серверный - это курсор, управляемый компонентом SQL Engine. Он состоит из
выполнения запроса и некоторого состояния периода исполнения, включая текущую
позицию. Клиенты SQL могут использовать серверный курсор для извлечения
результатов запроса по одной записи или в пакетном режиме по N результатов за
один раз, вместо обычного – при котором из результатов извлекается сразу вся
выборка. Итеративные модели есть во многих приложениях и клиентских библиотеках,
но серверные курсоры - это единственный способ, которым компонент может
выполнить инкрементную обработку запроса.
Популярность серверных курсоров объясняется тремя преимуществами:
1-Отличное совпадение итеративной модели программирования, комфортной для
программистов, не связанных с базами данных. Это преимущество явно
переоценивается и от него больше вреда, чем пользы. В Books Online на этот счет
говорится:
Если полученные данные будут затребованы все разом без необходимости позиционных
обновлений или пролистывания, рекомендуется использовать результирующие выборки
по умолчанию
2-Сокращение необязательной обработки ненужных данных при прекращении ранее
начатого считывания данных клиентским приложением. Поскольку во многих случаях
(но не во всех) обработка, выполняемая курсором на сервере, инкрементирующая и
вызывается по требованию, нагрузка на сервер и передача данных соответственно
тоже сокращаются.
3-Очень хорошо сопоставляются поэкранный/оконный просмотр и пролистывание
больших наборов данных. Просто нет более удобного способа сказать SQL Server
«дай мне следующую запись(и)».
Копирование схем
Винай Кумар (Vinay Kumar )
В настоящее время я работаю на проекте, в котором мы имеем более 10 заказчиков.
Все клиенты управляются через посредство различных схем. Объекты внутри схемы
взаимодействуют только внутри своей схемы.
Иногда необходимо обновить хранимые процедуры, которые одинаковы для всех схем.
В этом случае приходилось открывать процедуры одну за одной во всех схемах. Я
поискал в Интернете какое-то решение, но ничего не нашел. Тогда я решил написать
предлагаемый вашему вниманию скрипт.
Я создаю тестовый сценарий. В нем я создаю таблицу: "SchemaTable" в каждой схеме
(Marketing, Sales ,Accounts ,Economics, Employee, Manager, Employee). Затем я
создаю процедуру только в схеме Employee. Эта схема работает только с таблицами,
принадлежащими этой схеме.
Теперь, мне нужно создать такую же хранимую процедуру во всех схемах.
Проверка связанных серверов
Марк Хюбер (Mark Huber)
Я создал сервер мониторинга и одна из вещей, которая меня интересовала - все ли
серверы, за которыми я наблюдаю, находятся в рабочем состоянии. Для проверки
этого я создал предлагаемую процедуру. У меня даже есть один Oracle сервер и я
периодически опрашиваю его, чтобы убедиться, что он по-прежнему способен
принимать соединения.
Процедура создавалась для проверки готовности связанных (linked) серверов, потом
я добавил параметры и логику, которая проверяет, когда было выполнено задание и
как оно отработало.
Понимание и использование параллелизма в SQL Server
Пол Уайт
Неявное использование параллелизма в SQL Server может ускорить выполнение
запросов SQL. Многие из нас не имеют точного представления, как это работает и
работает ли вообще. Пол Уайт начал серию статей, где все просто и понятно
объясняет.
Многие опытные профессионалы в области баз данных имеют смутное представление о
параллельном выполнении запросов. Иногда это результат неудачного опыта работы с
предыдущими версиями SQL Server. Однако часто причина в том, что представление
сформировано в результате заблуждений или из-за недостаточного мастерства
владения методами, необходимыми для эффективного создания и отладки запросов для
параллельного выполнения.
Это первая статья серии, и она должна донести до читателя, обладающими глубокими
знаниями, необходимость в особом использовании доступных в Microsoft SQL Server
функций параллельной обработки запросов. В первой ее части приведено пошаговое
руководство с описанием основополагающих знаний о параллелизме в SQL Server, она
знакомит с такими концепциями, как параллельные операции просмотра и поиска,
рабочие процессы, потоки, задания, контексты выполнения и операторы обмена, для
координации параллельных операций.
Дальнейшие статьи укажут направление изучения внутренних процессов подсистемы
базы данных и покажут, как с помощью определенного уровня параллелизма можно
улучшить не только работу хранилищ данных и систем поддержки принятия решения, с
которым обычно связывается параллельное исполнение запросов. Системы, которые
часто относят к классу OLTP, нередко содержат запросы и процедуры, которые
позволяют получать преимущество при использовании параллелизма.
Возможно, неизбежно, что ата и последующие статьи содержат достаточно глубокий
технический контент. Наиболее эффективное использование параллелизма требует
хорошего понимания того, как в действительности выполняются такие процессы как,
распределение во времени, оптимизация запроса и подсистема выполнения. Несмотря
на это, остается надежда на то, что эта серия статей будет информативной и
полезной даже для начинающих.
(Возврат на основную страницу)