(Возврат на основную страницу)
Фил Фактор
Язык TSQL для текстовых файлов
Робин Пейдж и Фил Фактор
Практическое занятие по безопасности SQL Server. Часть 1
Инструментарий для делегирования процесса. Часть 1
Язык TSQL для текстовых файлов
Фил возвращается к старой теме «Getting text-based data in and out of SQL Server» («Обмен текстовыми данными с SQL Server»). Он демонстрирует разные способы, позволяющие легко получить от файловой системы списки файлов из указанных каталогов, показывает, как можно обратиться к объектам автоматизации оболочки Shell и предлагает несколько способов чтения и записи данных из базы данных в файл и обратно.
В данной статье снова поднимается тема, которая уже рассматривалась в статье, написанной мной для SimpleTalk два года тому назад, — «Reading and Writing Files in SQL Server using TSQL» («Чтение и запись файлов в SQL Server средствами языка TSQL»). К моему удивлению, та давняя публикация оказалась самой популярной из всех моих статей.
В этой запоздалой второй части (я в основном буду исходить из предположения, что у вас есть версии SQL Server 2005 или 2008) мы собираемся продемонстрировать средства языка TSQL, которые можно использовать для того, чтобы:
• Получить список файлов, которые находятся в некотором каталоге или папке, вместе (если это необходимо) с перечнем вложенных папок и атрибутов, таких как размер файла, дата версии, или краткую форму такого списка.
• Обратиться к объекту SHELL.APPLICATION для выполнения операций с файлами.
• Выполнить чтение данных из файла в переменную языка TSQL.
• Выполнить построчное чтение данных в таблицу: каждая строчка текста попадает в строку таблицы.
• Выполнить запись данных из переменной языка TSQL в файл.
• Выполнить запись в файл строковых результатов выражения SQL Expression.
Все это простые операции, но именно некоторые из самых элементарных операций, выполняемых в базе данных, могут оказаться наиболее дорогостоящими. Для сравнения, изучение операционной системы DOS начинается с того, что вы первым делом осваиваете команды DIR или Cls. Операция получения данных из файлов или записи данных в файлы очень проста; но не в SQL Server. Причина в том, что обычно SQL Server — самое неподходящее место для выполнения такой операции. Исключения крайне редки. В суровых условиях реальной жизни в отделе ИТ иногда просто нет другого выбора. Для большинства операций очевидным вариантом является использование служб SSIS/DTS, но не всегда.
Первая проблема, с которой вы сталкиваетесь, это безопасность. Пользователю базы данных, выполняющему демонстрируемые мной подпрограммы, потребуются особые права; права, которые, возможно, нельзя предоставлять обычным пользователям по причине безопасности. Необходимо также, чтобы вы открыли «шлюзы» в системе защиты «Настройка контактной зоны» («Surface Area Configuration») базы данных, которые обычно «задраены», речь идет о возможности использовать механизм OLE Automation и командную строку. (Наверное, придется использовать утилиту, которая называется «Surface Area Configuration for Features» — «Настройка контактной зоны для функциональных возможностей».) Мы не намерены рассматривать здесь эти вопросы или демонстрировать способы решения проблемы обеспечения безопасности вашей базы данных. Об этом читайте в статьях The SQL Server Security Workbench — «Практическое занятие по безопасности SQL Server» и The Process Delegation workbench — «Инструментарий для делегирования процесса».
Практическое занятие по безопасности
SQL Server. Часть 1
Робин Пейдж (Robyn Page) и Фил Фактор (Phil Factor)
Защита SQL Server иногда оказывается для разработчиков приложений практически белым пятном. Что повсеместно иллюстрирует успех совсем простых по «вооружению» атак на управляемые базами данных веб-сайты, которые можно было бы предотвратить даже умеренными средствами защиты. На этом практическом занятии мы представим две, имеющие небольшие отличия, модели защиты базы данных. В одной из этих моделей используются роли, чтобы запретить доступ к таблицам и представлениям, а в другой — запрещается выдавать какие-либо разрешения на доступ к любым объектам, кроме хранимых процедур, которые образуют прикладной интерфейс.
Итак, что же представляли собой эти атаки на базы данных, которые оказались столь успешными? Да ничего особенно умного, просто разные способы, позволяющие проверить, предусмотрены или нет какиелибо реальные средства защиты. Атаки «SQL Injection» (атаки путем внедрения кода SQL) — это пример лишь одного из массы способов получить доступ к данным с недобрыми намерениями.
Инструментарий для делегирования процесса. Часть 1
Робин Пейдж (Robyn Page) и Фил Фактор (Phil Factor)
Вот способ, позволяющий спроектировать часть приложения баз данных SQL Server так, что пользователю покажется, будто приложение работает с большей скоростью.
Зачастую, когда вы проектируете приложение или вебсайт, которые интенсивно «общаются» с базой данных, вам надо только одно, чтобы прикладной уровень, просигнализировав о том, что должно начаться выполнение задания, немедленно вернул управление, ничего не блокируя. Как хорошо иметь надежную систему, которая помещает в буфер подпрограммы, не критичные по времени выполнения, и выравнивает пиковые нагрузки, и все это — без обязательного использования компонента Service Broker.
Для этого не критичные по времени процессы делегируются другому подключению к базе данных. В качестве побочного результата появляется возможность усилить защиту так, что прикладные функции никогда не будут выполняться под учетными записями пользователей.
Методика следующая: организовав очередь, в максимально возможном объеме делегировать обработку другому «клиентскому» («backoffice») процессу, который использует для подключения другую учетную запись. Это довольно распространенная методика, она использует предупреждения (Alerts) и задания (Jobs) агента SQL Server (SQL Server Agent).
На этом практическом занятии мы с Филом покажем, как осуществить такое делегирование с помощью пользовательских предупреждений, как в версии SQL Server 2000, так и в версии SQL Server 2005. Разумеется, предупреждения и задания удобнее настраивать интерактивно в среде SSMS, но в данном случае мы прибегнем к сценариям, чтобы вы могли быстрее и с меньшими затруднениями опробовать предлагаемую методику.
Чтобы познакомиться с основами использования пользовательских предупреждений (UserDefined Alerts), вы, возможно, предпочтете прочесть статью «SQL Server 2000: User Settable Object» (обманчивое название?) или ее вариант из версии SQL 2005.
Вот скелетная система, которая спроектирована для отправки информации по электронной почте с вебсайта, которым управляет база данных. Эту систему можно использовать почти для любого продолжительного по времени или требующего повышенных мер безопасности процесса, которому не надо немедленно возвращать результаты пользователю, такого, например, как обработка счета, печать уведомления об отправке, подтверждение сделки или проведение расчетов по сделке, изменение размеров изображения при загрузке или индексация текста.
Первое, что мы должны сделать, — это создать журнал, очередь и таблицу параметров очереди. Журнал необходим для того, чтобы у нас была информация о том, как продвигается очередь, а также для записи сообщений об ошибках и предупреждений. Нам нужна таблица с параметрами очереди, потому что каждый добавляемый в очередь процесс будет иметь свои, отличные от других параметры.
Процесс включает следующие шаги:
• Пользователь вызывает функцию для отправки электронной почты
• Функция обеспечивает создание записи в таблице очереди, чтобы сообщить о желании пользователя послать электронную почту
• В таблицу параметров добавляются параметры
• Выполняется настройка пользовательского счетчика, так что счетчик должен получить значение 1, чтобы сработало предупреждение
• Пользователь выполняет возврат из функции отправки электронной почты
• Срабатывает предупреждение и выполнятся задание
• Шаг задания обеспечивает выполнение процедуры, которая опустошает очередь, выполняя каждую помещенную в очередь задачу, включая отправку электронной почты
Прежде всего, вы должны создать базу данных с именем BackOfficeDemo.
(Возврат на основную страницу)