(Возврат на основную страницу)
Создание команд MERGE вместе с данными!
Джейсон Сельбург (Jason Selburg)
Зависимости объектов в xml формате
Петер Слобода (Peter Sloboda)
Процедура перестроения индексов
Кейт Хейс (Keith Hays)
Клавиатурные комбинации для повышения производительности
Эмил Бялобжеский (Emil Bialobrzeski)
Использование учетных записей-посредников для заданий
Ричард Уэймайр (Richard Waymire)
Создание команд MERGE вместе с данными!
Джейсон Сельбург (Jason Selburg)
Допустим, вы хотите быстро предоставить кому-то сценарий, который будет
заполнять определенную таблицу данными из вашей базы данных. А если у вас 200
таблиц? Это может занять некоторое время. А если у вас нет доступа к целевой
базе данных? Вы можете, конечно, использовать MERGE, но это потребует много
кода. Как было бы здорово запустить скрипт, который создаст файл SQL, содержащий
все операторы в одном файле и готов к запуску, после внимательного анализа,
конечно.
Ну, вот, такой скрипт я и предлагаю в настоящей статье и надеюсь, что он поможет
вам, но заставить вас думать о других возможностях автоматизации сценария в
режиме SQLCMD.
Кроме того, какой уважающий себя администратор не хочет знать, как это сделать с
помощью SQL?
Зависимости объектов в xml формате
Петер Слобода (Peter Sloboda)
С момента появления sys.dm_sql_referenced_entities, динамического представления,
которое содержит дерево зависимостей, я начал его пробовать и использовать для
отображения всех объекты в формате XML. Хранимая процедура использует
представление для извлечения иерархии, сохраняет его в таблице (#tree), по
которой впоследствии мы проходим средствами рекурсивного CTE.
Просто создайте хранимую процедуру, передайте ей имя объекта и откройте
результат в формате XML.
Я не включил проверку уровня рекурсии, но мы все знаем, если глубина достигает
32, программа выдает ошибку. Я не собираюсь поучать вас, но если любой из ваших
объектов имеет глубину зависимости более 32, у вас проблемы.
Процедура перестроения индексов
Кейт Хейс (Keith Hays)
Мы все видели процедуры, перестроения всех индексов в базе данных или всех
индексов в базе данных, имеющих фрагментацию меньше заданного ScanDensity.
Предлагаемая процедура на несколько шагов дальше. Во-первых, администратор базы
данных может указать ScanDensity_Threshold (значение мин для ScanDensity ) ,
плюс Limit (кол-во или %). Если указать ScanDensity_Threshold = 80, и лимит =
50% , то только худшие 50% всех индексов в базе данных имеющих ScanDensity <80
будут перестроены.
Программа определяет " худший " n % всех индексов путем расчета Reindex_Factor
на основе ScanDensity и PageCount.
Индекс с ScanDensity 70, занимающий 2000 страниц будет перестроен перед
индексом, имеющим ScanDensity 25 и 2 страницы. После ее завершения, вы можете
запросить таблицу DBA_Index_History чтобы увидеть, какие индексы были
перестроены и почему.
Администратор базы данных имеет возможность указать FillFactor_Age_Limit. Если
индекс будет перестроен во второй раз в течение срока, определенного значением
FillFactor_Age_Limit ,FillFactor будет снижена на 5, как минимум до 50. ( Если
это не желательно , просто установите FillFactor_Age_Limit = 0 ).
Эта процедура использует БД "DBA", которую я создаю на каждом из моих SQL
серверов. Если вы храните процедуры технического обслуживания в основной базе
данных , вам нужно будет принять это во внимание , но я очень рекомендую вам,
переместить их в базу данных "DBA". Это значительно упрощает управление!
Код откомментирован. Пожалуйста, тщательно изучите процедуру и комментарии,
чтобы понять, как она работает.
Это
вариант процедуры был протестирован в SQL 2012.
Клавиатурные комбинации для повышения производительности
Эмил Бялобжеский (Emil Bialobrzeski)
Использование учетных записей-посредников для заданий
Ричард Уэймайр (Richard Waymire)
Агент
SQL Server – это основа жизнедеятельности любой действующей системы баз данных.
Он находит целый ряд применений, которые не всегда очевидны, и поэтому знание
этой системы никогда не бывает лишним и для разработчиков, и для администраторов
БД. Ричард Уэймайр дает простое объяснение многим применениям агента SQL Server.
В предыдущей статье вы исследовали роли безопасности, предопределенные в базе
данных msdb, которые обеспечивают права доступа к агенту SQL Server. Эти роли
включают SQLAgentUserRole, SQLAgentReaderRole и SQLAgentOperatorRole. Членство в
каждой из этих ролей обеспечивает пользователю определенные привилегии для
использования агента SQL Server без необходимости быть членом серверной роли
sysadmin. Для полного административного контроля над агентом SQL Server вам
по-прежнему понадобится членство в роли sysadmin. Кроме того, вы познакомились с
наследованием прав доступа и вариантами учетной записи для службы агента SQL
Server. На этом этапе вы познакомитесь с понятием учетных записей-посредников
для агента SQL Server. Учетные записи-посредники позволяют шагу задания
действовать от лица конкретной учетной записи системы безопасности ОС Windows,
чтобы выполнить операции этого шага. Как правило, это делается для того, чтобы
иметь возможность включать в некоторые шаги задания операции, которые обычно
нельзя выполнить, если использовать учетные данные безопасности владельца
задания.