升級後檢查和疑難排解
升級後檢查
在就地升級之後，應執行下列活動以完成升級。 假設AEM已從6.4 jar開始，且已部署升級的程式碼庫。
驗證升級成功的日誌
upgrade.log
過去，檢查實例的升級後狀態需要仔細檢查各種日誌檔案、儲存庫的部分和啟動板。 產生升級後報告有助於在上線前偵測有缺陷的升級。
此功能的主要用途是減少需要手動解釋或跨多個端點執行複雜解析邏輯，以限定升級成功與否。 該解決方案旨在為外部自動化系統提供明確的資訊，以便對更新的成功或已識別的失敗做出反應。
更具體地說，它可確保：
- 升級架構偵測到的升級失敗可集中在單一升級報告中；
- 升級報告包括有關必要手動干預的指標。
為了彌補這一缺點，已對upgrade.log檔案中生成日誌的方式進行了更改。
以下是範例報表，其中顯示升級期間無錯誤：
以下是範例報表，顯示升級程式期間未安裝的套件：
error.log
在使用目標版本jar啟動AEM期間和之後，應仔細檢查error.log。 應審查任何警告或錯誤。 一般而言，最好在記錄檔開頭尋找問題。 日誌中稍後發生的錯誤，實際上可能是檔案中較早調出的根本原因的副作用。 如果發生重複錯誤和警告，請參閱下面的分析升級問題。
驗證OSGi Bundles
導覽至OSGi主控台/system/console/bundles，並查看是否未啟動任何組合。 如果有任何捆綁包處於安裝狀態，請咨詢error.log以確定根問題。
驗證Oak版
升級後，您應該會看到Oak版本已更新為1.8.2。 若要確認Oak版本，請導覽至OSGi主控台，並查看與Oak bundles相關的版本：Oak Core、Oak Commons、Oak Segment Tar。
檢查PreUpgradeBackup資料夾
在升級期間，AEM會嘗試備份自訂項目，並將它們儲存在/var/upgrade/PreUpgradeBackup/<time-stamp-of-upgrade>下方。 要在CRXDE Lite中查看此資料夾，您可能需要臨時啟用CRXDE Lite。
具有時間戳的資料夾應具有名為mergeStatus的屬性，其值應為COMPLETED。 to-process資料夾應為空，被覆寫的節點指示在升級期間覆蓋的節點。 perting節點下方的內容表示升級期間無法安全合併的內容。 如果您的實作依賴任何子節點（而且您的升級程式碼套件尚未安裝），則需要手動合併這些節點。
在本練習後，如果在「舞台(Stage)」或「生產(Production)」環境中，則禁用CRXDE Lite。
頁面的初始驗證
對AEM中的數個頁面執行初始驗證。 如果升級Author環境，則開啟「開始」頁和「歡迎」頁(/aem/start.html、/libs/cq/core/content/welcome.html)。 在「作者」和「發佈」環境中，都會開啟數個應用程式頁面，並進行煙霧測試，以便正確顯示。 如果發生任何問題，請咨詢error.log以進行故障診斷。
套用AEM Service Pack
如果相關的AEM 6.4 Service Pack已發行，請套用。
移轉AEM功能
AEM中的數項功能需要升級後執行其他步驟。 在升級程式碼與自訂頁面上，可找到這些功能與在AEM 6.4中移轉的步驟的完整清單。
驗證計畫維護配置
啟用Data Store Garbage Collection
如果使用File Data Store，請確定已啟用Data Store Garbage Collection任務並將其添加到Weekly Maintenance清單。 說明如下：此處。
S3自訂資料存放區安裝或使用共用資料存放區時，不建議使用此功能。
啟用聯機修訂清除
如果使用MongoMK或新的TarMK區段格式，請確定已啟用「修訂清除」工作並新增至「每日維護」清單。 說明此處。
執行測試計畫
根據測試過程部分中定義的升級代碼和自定義執行詳細的測試計畫。
啟用複製代理
發佈環境完全升級並經過驗證後，在「作者環境」上啟用複製代理。 驗證代理是否能夠連接到相應的發佈實例。 如需事件順序的詳細資訊，請參閱升級程式。
啟用自訂排程工作
此時，任何作為代碼庫一部分的計畫作業都可以啟用。
分析升級的問題
本節包含AEM 6.4升級程式中可能遇到的問題案例。
這些案例應有助於追蹤升級相關問題的根本原因，並有助於識別專案或產品特定問題。
在升級後重新建立動態媒體雲端設定
從舊版升級至AEM 6.4後，從舊版設定進行的Dynamic Media Cloud設定可能無法從AEM 6.4 TouchUI存取。 若要解決此問題，請使用CRXDE Lite移除舊版設定，然後建立新的Dynamic Media Cloud設定。 另請參閱AEM 6.4](/docs/experience-manager-64/sites-deploying/dynamicmedia-repository-restructuring-in-aem-6-4.html?lang=zh-Hant)中的[動態媒體資料庫重組。
資料庫遷移失敗
從CRX2到Oak的資料移轉，對於任何以CQ 5.4為基礎的Source Instances開始的情形都可行。請務必確實遵照本文檔中的升級說明（包括準備repository.xml），確保未通過JAAS啟動自定義驗證器，並且在開始遷移之前已檢查實例是否不一致。
如果遷移仍然失敗，您可以通過檢查upgrade.log來找出根本原因。 如果尚未知道問題，請向客戶支援報告。
升級未運行
在開始準備步驟之前，請務必使用java -jar aem-quickstart.jar命令先執行source實例。 為確保快速啟動。properties檔案正確生成，必須執行此操作。 如果缺少，升級將無法運作。 或者，您也可以查看源實例安裝資料夾中的crx-quickstart/conf下方，檢查檔案是否存在。 此外，當啟動AEM以開始升級時，必須使用java -jar aem-quickstart.jar命令來執行它。 從開始指令碼開始時，不會在升級模式中啟動AEM。
包和包無法更新
如果在升級期間無法安裝套件，則其所包含的套件也不會更新。 此類問題通常是由資料存放區配置錯誤所造成。 它們也會以ERROR和WARN消息的形式出現在error.log中。 由於在大多數情況下預設登錄可能無法運行，因此您可以直接使用CRXDE來檢查和查找配置問題。
某些AEM Bundles不會切換至活動狀態
如果捆綁包未啟動，則應檢查是否有任何未滿足的從屬關係。
如果出現此問題，但是它基於失敗的軟體包安裝，導致軟體包無法升級，它們將被視為與新版本不相容。 有關如何診斷此故障的詳細資訊，請參見上述軟體包和捆綁失敗更新。
此外，建議您比較最新AEM 6.4執行個體的套件清單與升級的執行個體，以偵測未升級的套件。 這將提供error.log中更詳細的搜尋範圍。
自訂組合未切換至活動狀態
如果您的自訂搭售未切換至作用中狀態，則很可能有程式碼未匯入變更API。 這通常會導致不滿足要求的從屬關係。
已移除的API應在先前的某個版本中標示為已過時。 您可能會在此取代通知中找到有關直接轉換程式碼的指示。 Adobe的目標是盡可能建立語義版本，讓版本能夠指示變更的中斷。
此外，最好檢查是否絕對需要導致問題的更改，如果不需要，請進行恢復。 此外，在嚴格的語義版本修訂後，檢查軟體包導出的版本增加是否超出必要。
故障平台UI
如果某些UI功能在升級後無法正常運作，您應先檢查介面的自訂覆蓋。 某些結構可能已變更，而覆蓋可能需要更新或已過時。
接著，檢查是否有任何Javascript錯誤，這些錯誤可追蹤至自訂新增的擴充功能，這些擴充功能會連結至用戶端程式庫。 自訂CSS也會套用相同的功能，這可能會對AEM版面造成問題。
最後，檢查Javascript可能無法處理的設定錯誤。 通常情況下，副檔名會不當停用。
故障自訂元件、範本或UI擴充功能
在大多數情況下，這些問題的根本原因與未啟動的捆綁包或未安裝的軟體包的根本原因相同，但問題在首次使用元件時開始出現的唯一差異。
處理錯誤自訂程式碼的方法是先進行煙霧測試，以找出原因。 找到建議後，請查看文章此[link]區段中的建議，以瞭解修正建議的方式。
下缺少自定義
/apps 並且 /libs 由升級處理得當，但升級後 /etc 可能需要手動還原 /var/upgrade/PreUpgradeBackup 變更。請務必檢查此位置是否有需要手動合併的任何內容。
分析error.log和upgrade.log
在大多數情況下，需要查閱記錄檔以找出問題的原因。 但是，在升級時，也需要監視相關性問題，因為舊捆綁包可能無法正確升級。
執行此操作的最佳方式是移除所有預期與您所面對之問題無關的訊息，以刪除error.log。 您可以透過像grep這樣的工具，使用：
grep -v UnrelatedErrorString
有些錯誤訊息可能無法立即解釋。 在這種情況下，查看發生錯誤的上下文也有助於瞭解錯誤的建立位置。 您可以使用下列項目來分隔錯誤：
grep -B在錯誤前添加行；
或
grep -A，以在後面添加行。
在少數情況下，也可以找到WARN訊息，因為可能存在導致此狀態的有效案例，而應用程式不一定能判斷這是否為實際錯誤。 請確定您也參考這些訊息。
聯絡Adobe支援
如果您已閱讀本頁的建議，但仍有問題，請聯絡Adobe支援。 為了盡可能向負責您案例的支援工程師提供更多資訊，請確保包含升級的upgrade.log檔案。