由於“OLDEST_PAGE”，數據庫的事務日誌已滿
我們有一個託管在 azure 上的數據庫。它是天藍色彈性池的一部分。從昨天開始，我們所有的數據庫操作都一直失敗並出現以下錯誤。
由於“OLDEST_PAGE”，數據庫的事務日誌已滿
我們檢查了數據庫上的所有活動事務，但目前沒有活動事務，但日誌文件仍然佔用 100% 的空間。
我瀏覽了以下文件頁面，但我無法完全理解這個問題：
誰能幫我理解這個問題？
更新
當我們將此數據庫移動到新池時，日誌大小會自動減小。搬家後我們沒有遇到任何問題。
這不是你應該在 Azure SQL 數據庫上看到的東西。您應該為此提供支持。
如果你願意，你可以自己做幾件事。首先嘗試檢查點數據庫。其次，如果您確定沒有活動事務，請更改數據庫 SLO。將其從彈性池中取出，然後將其放回。
注意：在意識到這是在 Azure SQL DB 上之前，我寫了這個答案（大衛的回答似乎表明這是 Azure 中的合法錯誤行為）。
離開這裡作為 OP 也在尋找關於該錯誤意味著什麼的解釋，也許它會對存在此錯誤的本地設置中的其他人有所幫助。
您的事務日誌已滿。查看您共享的螢幕截圖，它只有 59 MB。這是相當小的。人們會認為它只會繼續增長以適應更多交易。但由於某種原因它不能。
SQL Server 想要開始重新使用日誌文件。但是你已經發生了令人討厭
OLDEST_PAGE的事情。這意味著記憶體中的已修改日期頁尚未持久化到磁碟上的數據文件中，因此 SQL Server 無法開始重新使用記錄那些可能未持久化的事務的事務日誌部分。臨時解決方法是
CHECKPOINT在伺服器上手動執行命令，嘗試強制將這些緩衝頁面刷新到磁碟。您可能必須多次執行該命令，但這將允許該事務日誌文件開始被重用。更大的問題在於您的事務日誌。你應該執行這個查詢：
select max_size, growth from sys.master_files where [name] = 'YourLogFileName';進而：
檢查
max_size是否有明確的最大值阻止您的日誌文件增長如果是這種情況，請設置
max_size為更大的數字以適應您的實際事務負載。此數量取決於您通常的事務數量以及您使用的恢復模式。檢查
growth是否已禁用自動增長（增長 = 0）如果它被禁用，您可以啟用它。
如果您不能這樣做，並且您處於完全恢復模式，您可以安排更頻繁的日誌備份。
如果您不能這樣做，並且您處於簡單恢復模式，您將需要手動增加日誌文件的大小，直到它足夠大以處理您在自動或間接檢查點之間的事務。
也許，您的 Azure 儲存磁碟已滿，這就是阻止文件增長的原因（儘管我預計會有不同的錯誤消息）。