您可以診斷並解決無邊界 Lakehouse 及其相關聯資源中的錯誤，包括中繼資料資料表查詢、metadata.json 檔案大小限制，以及多區域目錄設定等問題。解決這些問題後，即可在湖倉工作負載中還原資料表作業和查詢執行作業。
無法查詢中繼資料表
在 BigQuery 中，使用五部分名稱 ID 查詢由 Lakehouse 執行階段目錄支援的 Apache Iceberg 資料表中繼資料表 (例如 .snapshots 或 .files) 時，就會發生這個問題。
如要解決這個問題，請使用 Apache Spark 查詢這些資料表。
metadata.json 檔案大小限制
Apache Iceberg metadata.json 檔案大小上限為 1 MB。這項限制適用於追蹤資料表快照、結構定義和分區規格的中繼資料檔案。如果中繼資料檔案超過這個大小，透過 Apache Iceberg REST 目錄端點執行資料表作業時，可能會發生錯誤。
如要解決這個問題，請與 Google 帳戶團隊聯絡，要求提高上限。
查詢多區域目錄時發生 NOT_FOUND 項錯誤
在 Lakehouse 執行階段目錄中，使用多區域 Cloud Storage bucket 建立目錄，但未指定主要位置，然後嘗試指定 BigQuery 虛擬區域 (例如 US 或 EU) 查詢目錄，就會發生這個問題。
使用多區域 bucket 建立目錄時，中繼資料會儲存在多區域地理範圍內的特定區域位置，而非對應的 BigQuery 虛擬區域。如果強制在沒有中繼資料的虛擬區域執行查詢，查詢會失敗並顯示 NOT_FOUND 錯誤。
如要解決這個問題，請在建立目錄時指定主要位置 (例如 US 或 EU)。詳情請參閱「指定美國和歐盟多區域的主要區域」。
儲存空間最佳化工作不會顯示在 INFORMATION_SCHEMA.JOBS 中
如果對 Apache Iceberg 資料表啟用資料表管理功能，並執行資料異動 (例如插入或 DML 陳述式)，但 INFORMATION_SCHEMA.JOBS 檢視畫面中未顯示任何儲存空間最佳化工作 (例如 CALL BQ.OPTIMIZE_STORAGE)，就會發生這個問題。如要進一步瞭解如何查詢這些工作，請參閱「取得 Iceberg 儲存空間最佳化工作」。
如果略過儲存空間最佳化，就會發生這種情況。資料表管理功能會在資料異動後評估資料表版面配置，並只在資料檔案需要壓縮或重組時，才執行最佳化工作。由於背景資料表管理工作會在專案中執行，並耗用運算資源，因此如果資料表版面配置已最佳化，BigQuery 就不會重寫資料。在下列情況下，系統會略過最佳化：
- 檔案已達最佳狀態：現有資料檔案已接近或超過目標檔案大小 (平均未壓縮大小至少為 256 MB 的 50%)。
- 未達門檻：資料表累積的小型檔案數量不足，或未達壓縮所需的大小門檻 (例如資料表總大小超過 1 GB)。
如果略過儲存空間最佳化，系統就不會執行背景工作，也不會在 INFORMATION_SCHEMA.JOBS 中記錄任何項目。
如果查詢效能符合您的需求，且檔案大小適當，則無須採取任何行動。如果日後寫入作業導致檔案碎片過多，系統會自動執行儲存空間最佳化作業。
如要在測試環境中觀察儲存空間最佳化工作，請在大小超過 1 GB 的資料表中，分批插入多筆小型資料，模擬檔案分割。