資料更新報錯

問題現象

建立 Oracle 資料連結，更新一張 9000 萬資料量的 SQL 表失敗，查看%FineBI%\logs下的 fanruan.log 檔案，報錯如下圖所示：

原因分析

SQL 語句執行時間太長，或者 UNDO 表空間過小，或者交易量過大，或者過於頻繁的提交，導致執行 SQL 程式中進行一致讀時，資料庫回滾段佔滿，SQL 執行後修改的前鏡像（即 UNDO 資料）在 UNDO 表空間中已經被改寫，不能構造一致讀塊。

解決方案

增加 UNDO 表空間大小，可以新增 undo 表空間的資料檔案或者切換 undo 表空間

問題現象

單機部署的 FineBI 業務包更新失敗、單表更新失敗。查看%FineBI%\logs下的 fanruan.log 檔案，看到報錯：錯誤程式碼:62400001Got timeout reading communication packets如下圖所示：

原因分析

在 MySQL 通訊協定建立連結之後，此時使用者端連結的時間受wait_timeout和interactive_timeout參數控制。

interactive_timeout：指伺服器關閉交互式連結前等待活動的秒數。

wait_timeout：指伺服器關閉非交互連結之前等待活動的秒數。

兩者生效取決於：使用者端是交互或者非交互的連結。在交互模式下，interactive_timeout才生效；在非交互模式下，wait_timeout生效。出現更新問題是由於由於參數過小而導致連結逾時，進而使得資料更新失敗。

解決方案

1）在 MySQL 資料庫中查看wait_timeout和interactive_timeout 參數，執行 SQL 語句：show global variables like '%timeout%'

2）修改至合適的參數大小，執行 SQL 語句：set global wait_timeout=xxxx;  set global interactive_timeout=xxxx

問題現象

Linux 系統下，BI 全局更新卡住了，單個業務包更新失敗。查看%FineBI%\logs下的fanruan.log檔案，看到報錯：DISDB1:DISDB1:Name or service not known，如下圖所示： 

原因分析

在 Linux 環境下執行 hostname，發現hostname為DISDB1，查看etc/hosts配置檔案，檔案中沒有hostname對應配置。導致更新失敗。

解決方法

透過命令 vi /etc/hosts進入配置檔案hosts並且新增對應的  IP  hostname，如下圖所示：

問題現象

單表更新成功但是後台報錯out of memory。查看%FineBI%\logs下的fanruan.log檔案，看到報錯：Out of memory  如下圖所示：

原因分析

報錯out of memory是需要看資料庫的當時的狀態和記憶體使用情況，可能是由於資料庫不穩定引起的。

解決方案           

檢查 MySQL 中的key_buffer_size、max_heap_table_size和 tmp_table_size三個參數，調整至合適的大小

問題現象

建立 Oracle 資料連結並建立 SQL 資料集，預覽和儲存失敗。查看後台出現此報錯 ORA-01652: 無法透過 128 (在表空間 TEMP 中) 擴展 temp段

原因分析

臨時表空間主要用途是在資料庫進行排序運算、管理索引、存取檢視表等操作時提供臨時的運算空間，當運算完成之後系統會自動清理。當臨時表空間不足時，表現為運算速度異常的慢，並且臨時表空間迅速增長到最大空間（擴展的極限），一般不會自動清理。如果臨時表空間沒有設定為自動擴展，則臨時表空間不夠時交易執行將會報ora-01652無法擴展臨時段的錯誤。

解決方案       

方法一：增大臨時檔案大小。

方法二：將臨時資料檔案設為自動擴展。

報錯現象

日誌報錯：ERROR [standard] java.lang.NullPointerException  com.fr.transaction.ConfigException: java.lang.NullPointerException，所有資料集突然更新失敗。

原因分析

內建資料庫鎖住（可能關閉工程的時候沒殺乾淨，或者用第三方工具連過 finedb）

解決方案

在%FineBI%/webapps/webroot/WEB-INF/embed/finedb 目錄下刪除 db.lck 檔案或遷移資料庫。

報錯現象

表更新失敗，且更新介面顯示：com.fr.engine.bi.config.exception.IllegalTableMarkedException: 表異常標紅

原因分析

資料庫中的表欄位產生了變化，與之前該表抽取到 FineBI 的資料不一樣了。

解決方案

點選「編輯」按鈕，「取消勾選」標紅的欄位。

問題現象

Linux 環境下，連結資料庫後無法更新。

原因分析

Linux 中儲存資料的資料夾沒有讀寫權限。儲存的資料夾和路徑可在「資料準備>更新設定」中看到，詳細請參見：資料更新與存放

解決方法

給儲存更新資料的資料夾讀寫權限。

例如：儲存資料的資料夾路徑為/home/update data，那麼 chmod -R 777 /home/update data  即可給該資料夾讀寫權限。

解決辦法

排查叢集環境的每個節點的WEB-INF/classes/com/，是否都放了 class 檔案。

原因分析

資料庫密碼過期。

解決辦法

修改資料庫密碼，並修改資料連結的密碼。

解決方法

更換lic檔案

解決辦法

檢查一下客戶的報表範本是不是有表做錯了

原因分析

兩個環境共享了一個ZK。相同的表同一時間更新才會出現這個問題。

解決辦法

修改zk路徑。在fine_conf_entity中參數名：DistributedOptimizationConfig.spiderConfig.spider_zookeeper_lock_root_path

參數預設值：/DISTRIBUTED_LOCK_MANAGERTEST

原因分析

記憶體化參數設定為10000，實際值為40573，需要調大記憶體化參數。記憶體化指的是將表資料全部載入到記憶體中進行計算。

解決辦法

調大記憶體化參數。參見文檔：BI/Spider参数

解決辦法

看一下分析表的父表，是否更新成功過（看資料佔用空間是否為0kb）。（T_XXXX一般為父表的資料檔案）

原因分析

tomcat 重複啟動，有多個進程。

解決方案

關掉tomcat後重新啟動。

原因分析

客戶沒有遷移資料庫，可能有多個工程連結了finedb，或者用第三方工具連結了finedb導致啟動載入時連結被鎖住

解決辦法

遷移資料庫

解決辦法

查看更新的表所用資料（基礎表或者資料庫表）是否變化

原因分析

BI申請資源超過spark 系統資源；BI端防火牆未開放，需要確認防火牆的狀態

解決方案

修改bi端spark資源相關配置，spark_executor_memory；spark_executor_cores；spark_cores_max，如果資源配置正常，則查看是否存在舊有進程佔用資源；關閉bi端防火牆，或者允許bi應用透過防火牆。

解決方案

參考文檔：Linux最大開啟檔案數

原因分析

作用於該組件的聯動關係欄位不唯一導致的

解決辦法

排查聯動關係是否符合1:1/1:N/N:1

解決方案

去資料庫中查看該表是否還存在

原因分析

資料庫方言權限相關問題

解決方案

重新設定資料庫相關權限

原因分析

61300108的報錯主要是alluxio服務和block id的問題
解決方案

alluxio組件增加個參數配置，alluxio.network.netty.heartbeat.timeout.ms=1800000

原因分析

1）分析表與基礎表的欄位類型不一致； 2）基礎表和資料庫欄位類型不一致

解決方案

1）將用到的基礎表刪除後重新新增後更新；2）將基礎表重新編輯儲存；

問題現象

nested exception is java.lang.NoClassDefFoundError

原因分析

jar包衝突問題，是由於hive-jdbc-1.1.0-cdh5.13.0-standalone.jar裏面的jackson的包衝突了導致，和bi本身衝突

解決方案

把上面衝突的jar從lib裏面刪除即可。

原因分析

資料庫的報錯，非更新bug，jdbc不支援

解決辦法

欄位設定那裏編輯後重新儲存下就可以了。

原因分析

 linux檔案數設定過小。

解決方案

linux開啟檔案數問題。

解決辦法

排查叢集環境的每個節點的WEB-INF/classes/com/，是否都放了class檔案

原因分析

資料庫欄位增加，增量刪除報錯了。

解決方案

重新編輯欄位，全量更新一下。

解決辦法

調大數據庫的臨時表空間的大小。

原因分析

在更新的程式中同時看儀表板了；沒更新完，報錯取不到鎖是正常現象。