2015-06-03 3 views
1

У меня есть запрос, который создает временную таблицу и использует эту таблицу в последующих частях запроса. Я выполнил первую часть запроса, которая просто создает таблицу для просмотра результатов. Я получил следующий результат:Журнал транзакций для базы данных «tempdb» заполнен: но таблица создана в любом случае?

запрос с ошибками:

(166166381 row(s) affected) 

Msg 9002, Level 17, State 4, Line 3 
The transaction log for database 'tempdb' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases 

Msg 9002, Level 17, State 4, Line 2 
The transaction log for database 'tempdb' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases 

поэтому создал (массивное) таблицу, но дал мне ошибку, указанную в журнале транзакций для Tempdb переполнена.

Произошла ли эта ошибка при отображении таблицы (как, возможно, не возвращать все строки), или я в порядке, чтобы использовать эту таблицу? Я просмотрел советы по удалению этой ошибки, но когда я смотрю на свойства tempdb, он говорит, что у меня нет разрешения, поэтому я не уверен, какие шаги предпринять для ошибки.

Вот код. Я не могу отформатировать его, чтобы поместиться в окне кода по какой-то причине

SELECT Cast(Datamart_Timestamp AS DATETIME) AS Datamart_Timestamp 
    ,Contract_ID 
    ,Admin_System 
    ,Contract_Status_Code 
    ,Cast(Contract_Status_Effective_Date AS DATETIME) AS Contract_Status_Effective_Date 
INTO ##Contract_Status 
FROM AV_TLA_Contract_Status AS CS 
WHERE (Datamart_Timestamp < '4/1/2011'); 

GO 
-- ////////////////////////////////////////////////////////////////////////////////// 

INSERT INTO ##Contract_Status 
SELECT CAST(CS.Datamart_Timestamp AS DATETIME) AS Datamart_Timestamp 
    ,CS.Contract_ID 
    ,CS.Admin_System 
    ,CS.Contract_Status_Code 
    ,CAST(CS.Contract_Status_Effective_Date AS DATETIME) AS Contract_Status_Effective_Date 
FROM AV_TLA_Contract_Status AS CS 
    LEFT OUTER JOIN AT_AHEV_2011_04_Contract_Status AS A 
    ON CS.Contract_ID = A.Contract_ID 
WHERE (CS.Contract_ID IS NOT NULL) 
    AND (A.Contract_ID IS NULL) 
    AND (CS.Datamart_Timestamp > '3/31/2011'); --Update so only most recent months are used. 
+0

Вы в порядке, чтобы использовать эту таблицу, потому что, если бы это не было грубой ошибкой коррупции. Вероятно, после выполнения инструкции create table появились дополнительные утверждения. – usr

+0

отлично, спасибо. Я считаю, что есть один раздел, который использует эту временную таблицу (которая выбирает элементы и создает в моей собственной базе данных), поэтому, надеюсь, после этого ничего не получится! – bkersh1

+0

Можете ли вы разместить свой код? В то время как таблица не «Коррумпирована», любые утверждения произошли после того, как выполняемая заявка на 166 миллионов строк (предположительно вставка) может не завершиться. – CDC

ответ

1

Не видит никакой проблемы с помощью созданной временной таблицы. Я считаю, что после создания временной таблицы с 166166381 rows пространство журнала транзакций было заполнено, и поэтому сообщение было выброшено, и оно предназначено для будущего создания временной таблицы.

+0

благодарю вас за ответ! – bkersh1

+0

Хм, я вижу нисходящее, но никаких комментариев с указанием причины. Странный! – Rahul

+0

Я попытался подняться, но нужно 15 репутации! Странно, что вы получили нисходящее ноль, но – bkersh1

0

Вы можете, конечно, использовать таблицу, но когда вы получаете сообщение с полным журналом, это означает, что любая деятельность, требующая регистрации, не была зарегистрирована, поэтому либо откат, либо отменена. Итак, ваш стол есть, но вы вполне можете пропустить кучу необходимых изменений и/или данных.

О том, как справиться с ошибкой, у вас есть два варианта:

  1. Обратитесь к своему дБА и попросить их, чтобы расти/увеличить размер журнала
  2. Пересмотрите то, что вы делаете - вы только что вставили 166 миллион строк в таблицу temp. Это необходимо? Можете ли вы вставить подмножество данных, которое содержит только нужные вам данные? Если это общая база данных, вы очень хорошо помешали другим людям/приложениям писать в tempdb.

Поскольку у вас нет разрешения на изменение TempDB, я думаю, это общая БД, и что DBA бы не расти журнал для вас, дБА сказал бы сделать # 2.

+0

Привет, Грег: Мы получили сервер только для нашего использования (не общий). Я считаю, что у меня нет разрешения на модификацию, так как администратор базы данных создал для нас – bkersh1

+0

ok, 166 миллионов строк в таблице temp не является хорошей практикой. сосредоточиться на # 2, – Greg

Смежные вопросы