Новости сайта "Упражнения по SQL" (http://www.sql-ex.ru) 179
Новости сайта "Упражнения по SQL (http://www.sql-ex.ru)" Выпуск 179 (01 марта 2008 г.)Новым посетителям сайта Сайт посвящен изучению языка, с помощью которого осуществляется взаимодействие с реляционными (и не только) СУБД. Суть обучения
состоит в выполнении заданий на написание запросов к учебным базам данных; при этом система контролирует правильность выполнения заданий. В настоящее время реализованы все операторы подъязыка манипуляции данными (DML), которые включают в себя оператор извлечения данных SELECT, а также операторы модификации данных - INSERT, DELETE и UPDATE.
Мы надеемся, что справочного материала сайта окажется достаточно для самостоятельного обучения. Кроме того, свои решения вы можете обсудить на форуме сайта. Опытных же специалистов приглашаем проверить (продемонстрировать) свое мастерство и принять участие в соревновании, обеспечиваемом рейтинговой системой учета времени выполнения заданий. Фактически, рейтинг ведется на втором этапе тестирования, который начинается сейчас после решения 57-ти задач первого этапа. При подсчете рейтинга каждого участника отбрасывается один самый худший показатель среди всех решенных им упражнений. Демонстрация плана выполнения запроса и сравнительная оценка эффективности решений поможет вам освоить принципы оптимизации запросов, которые пригодятся на третьем рейтинговом этапе, который начинается после 138 задачи.Имеется возможность получить сертификат по SQL DML при выполнении определенного количества заданий. Новости сайта§ Внес незначительные уточнения в формулировку задачи 52 в ответ на замечания SoftDeveloper. § Написал FAQ на 51 задачу, проблемы с решением которой, на мой взгляд, связаны с невнимательным прочтением формулировки. § Исправил баг, связанный с исчезновением плюсов (+) из кода при редактировании сообщения на форуме. § Дописал в справку особенности реализации в MS SQL функции LEN(), которая не учитывает концевые пробелы. Незнание этой особенности вызывает проблемы при решении некоторых задач на сайте, в то время как справка должна давать информацию, необходимую для решения задач. § Изменения среди лидеров (решенные задачи третьего этапа): § Продвинулись в рейтинге: § Продвижение ближайших претендентов на попадание в ТОР 100: § На этой неделе сертифицированы: § Число подписчиков - 3723 Число участников рейтинга - 14352 Число участников второго этапа - 1265 Число участников третьего этапа - 27 Сертифицировано на сайте - 241 Лучшие результаты (ТОР 20)
Лучшие результаты за неделю
Изучаем SQLА знаете ли вы? Вложенные транзакцииKalen Delaney (оригинал: Did you Know? Nesting Transactions )Перевод Моисеенко С.И. Transact-SQL обеспечивает три различных метода управления транзакциями: автоматическая фиксация транзакций (autocommit transactions), явные транзакции (explicit transactions) и неявные транзакции (implicit transactions). Автоматически фиксируемая транзакция - любая отдельная операция INSERT, UPDATE или DELETE, независимо от того, сколько строк было затронуто. Как только оператор выполнен, изменения фиксируются, что означает, что все соответствующие строки в журнале, включая запись в журнале COMMIT TRAN, записываются в журнал транзакций на диске (в ваш .ldf файл). Если Вы хотите иметь возможность объединить несколько операторов в единую транзакцию или если Вы хотите откатывать транзакцию в зависимости от некоторого условия, Вы можете использовать явное управление транзакциями с помощью операторов управления BEGIN TRANSACTION (начало транзакции или BEGIN TRAN) и COMMIT TRANSACTION (фиксация транзакции или COMMIT TRAN). Например, чтобы обновить обе таблицы T1 и T2 или ни одну из них, Вы можете использовать следующий псевдокод:
BEGIN TRAN
UPDATE T1 ...
UPDATE T2 ...
COMMIT TRAN
Если в системе наступает сбой после обновления T1, транзакция не будет зафиксирована. Она будет фиксироваться только в том случае, если оба обновления прошли успешно. Помимо этого, при использовании явных транзакций вы можете решить откатить транзакцию после проверки состояния ошибки или числа обработанных строк:
BEGIN TRAN
UPDATE T1 ...
IF @@error > 0 ROLLBACK TRAN
ELSE COMMIT TRAN
Третий тип управления транзакциями - неявные транзакции - не считаются поведением по умолчанию и представляют часть продукта для поддержки совместимости с другими продуктами баз данных. Я бы коснулась пары вопросов, связанных с ними. Вот небольшая загадка, которую я часто загадываю моим студентам. Предположим, имеется следующий пакет:
BEGIN TRAN UPDATE T1 BEGIN TRAN UPDATE T2 BEGIN TRAN UPDATE T3 COMMIT TRAN
"Что будет зафиксировано?" - спрашивается в задачнике. Обычно я получаю несколько ответов, среди которых: все обновляется, ничего не обновляется, обновляется Т1, обновляется Т3 (никто при этом не предлагает вариант обновления Т2). Оказывается, что ни один из приведенных ответов не является верным. SQL Server поддерживает внутренний счетчик, подсчитывающий, сколько раз был выполнен BEGIN TRAN, и вам необходимо выполнить такое же число COMMIT TRAN, чтобы реальная фиксация имела место. Каждый BEGIN TRAN увеличивает значение счетчика, а каждый COMMIT TRAN уменьшает его. Только когда значение счетчика станет 0, записи журнала будут сброшены на диск, и транзакция будет завершена на самом деле. Вы можете посмотреть значение счетчика с помощью функции @@trancount. С помощью этой функции вы можете увидеть, что когда вы выполняете откат - ROLLBACK, счетчик сразу же сбрасывается в 0.
BEGIN TRAN SELECT @@trancount BEGIN TRAN SELECT @@trancount BEGIN TRAN SELECT @@trancount ROLLBACK TRAN SELECT @@trancount
Итак, зачем нам могут понадобиться вложенные транзакции, если они реально не дают никаких преимуществ? Ответа на этот вопрос вам придется подождать до следующей публикации. Она будет посвящена связи вложенных транзакций с третьим типом управления транзакциями - неявными транзакциями. Название "неявные транзакции" может слегка запутать. Только BEGIN TRAN может быть неявным; COMMIT TRAN же всегда явный. Это означает, что ни одна транзакция не будет зафиксирована, пока не встретится COMMIT TRAN. Транзакции всегда буду начинаться с выполнения INSERT, UPDATE, DELETE или SELECT (а также с некоторых других операторов, например, CREATE и DROP, о чем вы можете почитать в Books Online), если нет уже открытой транзакции. Как я уже говорила, режим неявных транзакций не является режимом по умолчанию для SQL Server. Вы должны установить режим неявных транзакций либо с помощью оператора SET:
SET IMPLICIT_TRANSACTIONS ON;
или с помощью установки второго бита конфигурационной опции user_options в значение 1. Вы можете прочитать о sp_configure 'user options' в Books Online. Хотя я не рекомендую использование неявных транзакций, если вы собираетесь их использовать, я бы посоветовала, чтобы их использовали все сессии, то сделать это посредством установки конфигурационной опции. Если некоторые сессии будут использовать неявные транзакции и требовать COMMIT для каждого отдельного оператора INSERT, UPDATE и DELETE, а другие сессии не будут требовать закрытия, это означает напрашиваться на неприятности. Итак, что случится, если вы используете BEGIN TRAN, когда находитесь в режиме неявных транзакций? Я всегда думала, что BEGIN TRAN должен игнорироваться, однако выяснилось, что я ошибаюсь. Подумайте о том, что должно произойти, если вы имеете нормальный неявный режим транзакций, в следующем случае:
UPDATE T1
SET ...
COMMIT TRAN
А затем предположим, что кто-то выполняет пакет в пределах явной транзакции и оформляет ее с помощью BEGIN/COMMIT:
BEGIN TRAN
UPDATE T1
SET ...
COMMIT TRAN
COMMIT TRAN
Если BEGIN TRAN игнорируется, первый COMMIT установил бы @@trancount в 0, а второй дал бы ошибку. Вы можете проверить это поведение, просто выполнив COMMIT TRAN отдельно. SQL Server генерирует следующее сообщение: Msg 3902, Level 16, State 1, Line 1 The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION. (запрос COMMIT TRANSACTION не имеет соответствующего BEGIN TRANSACTION) Итак, если имеете режим неявных транзакций, выполнение BEGIN TRAN (чего вы фактически не должны делать) установит @@trancount в значение 2. Это на самом деле удивило меня, когда я заметила это, но затем я осознала значение такого поведения. Когда вы выполняете любую операцию DML, уже находясь в пределах транзакции, @@trancount не будет увеличиваться. Когда вы выполняете COMMIT для вашего оператора DML, @@trancount будет уменьшен на 1. Когда же вы выполняете COMMIT TRAN, соответствующий BEGIN TRAN, @@trancount уменьшится до 0, и транзакция действительно будет зафиксирована. Ниже полный скрипт, иллюстрирующий поведение @@trancount с неявными транзакциями:
SET IMPLICIT_TRANSACTIONS OFF; GO IF EXISTS (SELECT * FROM sys.objects WHERE name = 'T1' AND type = 'U') DROP TABLE T1; GO CREATE TABLE T1 (col1 int); GO INSERT INTO T1 SELECT 1; GO SET IMPLICIT_TRANSACTIONS ON; GO BEGIN TRAN; SELECT @@trancount; UPDATE T1 SET col1 = col1 + 1; COMMIT TRAN; SELECT @@trancount; COMMIT TRAN; SELECT @@trancount; GO SET IMPLICIT_TRANSACTIONS OFF; GO
13-08-2007 Полезная информация§ Все статьи, публикуемые в рассылке, затем выкладываются на сайте Книги и статьи по SQL. § Желающих поспособствовать популяризации сайта прошу проголосовать/поставить закладку в социальных сетях: КонтактыПо всем вопросам, связанным с функционированием сайта, проблемами при решении упражнений, идеями вы можете обращаться к Сергею И.Моисеенко msi77@yandex.ru. Вы также можете предложить свои задачи для публикации на сайте. |
| В избранное | ||
