Журнал транзакций заполнен (из-за НИЧЕГО), но эта база данных находится в простом режиме восстановления.

Я поддерживаю допотопное веб-приложение (которое скоро выйдет на пенсию), которое все еще использует «aspnetdb» для своей системы аутентификации. Я выполнял некоторую работу по подготовке к его выводу из эксплуатации в своей тестовой среде, когда обнаружил, что мой тестовый сервер жалуется на следующую ошибку:

Журнал транзакций для базы данных «aspnetdb» заполнен из-за «НИЧЕГО».

Теперь, как правило, я бы предположил, что проблема связана с журналом транзакций базы данных... но эта база данных недавно была переведена в простой режим восстановления (это тестовая машина).

Я безуспешно провел несколько экспериментов и немного погуглил. Кто-нибудь видел эту ошибку раньше? Полный журнал транзакций в базе данных в простом режиме восстановления?

Это на SQL Server 2016, работающем в режиме совместимости с 2008, потому что aspnetdb устарел.


person Pxtl    schedule 22.06.2019    source источник
comment
Я думаю, что при простом восстановлении вы не увидите растущий журнал, однако, если вы не создали резервную копию базы данных или не выполнили какое-либо действие для усечения журналов, возможно, база данных была заполнена с самого начала, и вы столкнулись с авто- проблемы роста. В этой ситуации я хотел бы задаться вопросом, устанавливает ли режим восстановления простое сокращение журналов?   -  person Ross Bush    schedule 22.06.2019
comment
Что опять? Мол, ставить рекавери простое хоть оно и так на рекавери простое? Я попробую... Нет, не сработало. Я попытался вернуть его в FULL, и это тоже не сработало.   -  person Pxtl    schedule 22.06.2019
comment
Мне было интересно, приведет ли переключение режима восстановления к сжатию файла журнала. Допустим, журнал был очень большим, и вам не хватило места. Сокращает ли простой процесс восстановления файл журнала или для этого нужно предпринять какие-то другие действия? Вы также можете опубликовать это на --› dba.stackexchange.com   -  person Ross Bush    schedule 22.06.2019
comment
Ну, я тоже разместил его там сейчас. Спасибо за совет. К сожалению, я не могу отключить простое восстановление - кажется, что каждая операция вызывает жалобу.   -  person Pxtl    schedule 22.06.2019
comment
Вы пытались сжать файл журнала?   -  person Ross Bush    schedule 22.06.2019
comment
Да, сжатие файла журнала не имеет никакого эффекта.   -  person Pxtl    schedule 22.06.2019


Ответы (2)


Понял, помощь получена от stackexchange.

https://dba.stackexchange.com/questions/241172/transaction-log-is-full-due-to-nothing-but-this-database-is-in-simple-recov?noredirect=1#comment475763_241172

Autogrowth был установлен на 0. К сожалению, в SSMS нет возможности увидеть это, поскольку он скрывает такие настройки для простых баз данных в режиме восстановления.

Запросите, чтобы увидеть реальную ценность Autogrowth, благодаря @HandyD:

SELECT 
    db.name AS [Database],
    mf.name AS [File],
    CASE mf.[type_desc]
        WHEN 'ROWS' THEN 'Data File'
        WHEN 'LOG' THEN 'Log File'
    END AS [FileType],
    CAST(mf.[size] AS BIGINT)*8/1024 AS [SizeMB],
    CASE
        WHEN mf.[max_size] = -1 THEN 'Unlimited'
        WHEN mf.[max_size] = 268435456 THEN 'Unlimited'
        ELSE CAST(mf.[max_size]*8/1024 AS NVARCHAR(25)) + ' MB'
    END AS [MaxSize],
    CASE [is_percent_growth]
        WHEN 0 THEN CONVERT(VARCHAR(6), CAST(mf.growth*8/1024 AS BIGINT)) + ' MB'
        WHEN 1 THEN CONVERT(VARCHAR(6), CAST(mf.growth AS BIGINT)) + '%'
    END AS [GrowthIncrement]
FROM sys.databases db
LEFT JOIN sys.master_files mf ON mf.database_id = db.database_id
where mf.name like 'aspnetdb%'

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

ALTER DATABASE aspnetdb MODIFY FILE (
    NAME = aspnetdb_log
    , SIZE = 1GB
) --this fixes the problem
GO
ALTER DATABASE aspnetdb MODIFY FILE (
    NAME = aspnetdb_log
    , SIZE = 1025MB
    , MAXSIZE = UNLIMITED
    , FILEGROWTH = 10MB
) -- now we have autogrowth
GO
USE aspnetdb
DBCC SHRINKFILE(aspnetdb_log,1) --now we can shrink the DB back to a sane minimum since autogrowth is in place
GO
person Pxtl    schedule 24.06.2019

Даже в простом режиме восстановления вы все равно можете получить полный журнал транзакций. Простой режим восстановления просто означает, что журнал транзакций усекается после каждой завершенной транзакции.

Журналу транзакций по-прежнему требуется место для размещения всех активных транзакций и всех транзакций, для которых выполняется откат.

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

Другой аспект - фактическая доступность пространства. Если вы настроили файл журнала с максимальным размером файла или когда у вас заканчивается место на диске, вы можете столкнуться с этим.

person Gert-Jan    schedule 22.06.2019
comment
На этой машине у меня 40 ГБ свободного места на диске, а база данных aspnetdb относительно мала, и открытых транзакций нет. Даже самые маленькие обновления терпят неудачу. - person Pxtl; 22.06.2019
comment
Вы проверили настройки автоматического увеличения журнала транзакций? Убедитесь, что он либо имеет неограниченный рост файлов, либо какое-то разумное значение для ограниченного роста файлов (я бы сказал, по крайней мере, 100 МБ). - person Gert-Jan; 23.06.2019