資料更新報錯

問題現象

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

原因分析

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

解決方案

增加 UNDO 表空間大小，可以新增 undo 表空間的資料檔案或者切換 undo 表空間，可以參考：Oracle undo 表空間管理。

問題現象

單機部署的 FineBI 業務包更新失敗、單表更新失敗。查看%FineBI6.0%\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 全局更新卡住了，單個業務包更新失敗。查看%FineBI6.0%\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。查看%FineBI6.0%\logs下的fanruan.log檔案，看到報錯：Out of memory  如下圖所示：

原因分析

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

解決方案           

檢查 MySQL 中的key_buffer_size、max_heap_table_size和 tmp_table_size三個參數，調整至合適的大小。可以參考：out of memory解決方法。

問題現象

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

原因分析

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

解決方案       

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

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

具體可以參考：解決方法

問題現象

進行資源遷移後，開啟BI進入資料準備之後顯示為空白。查看%FineBI6.0%\logs下的fanruan.log檔案，看到報錯：Data too long for column 'id' at row 1  如下圖所示： 

原因分析

由於資源遷移前後兩個系統下資料庫欄位預設長度設定不一致，某表中的'id'欄位為業務包表欄位名，比較長，當該'id'欄位長度超過資源匯入對應系統的資料庫中預設最大長度，則會出現此問題。

解決方案

修改需要資源匯入的系統使用的資料庫的欄位預設長度即可。以FineBI內建資料庫findb為例：

1）連結 FineDB 資料庫，刪除資料庫的表fine_conf_entity與fine_conf_classname中的'id'欄位索引，重建該欄位並修改長度。依次執行如下語句：

alter table fine_conf_entity drop primary key;
alter table fine_conf_entity add key(id);
alter table fine_conf_entity modify column id varchar(xxxx);  xxxx可以根據相應資料庫字元長度設定合適大小。

2）對 classname 也進行此操作,然後重啓 BI 即可。

問題現象

定時自動更新業務包時，後臺出現報錯Futures timed out after [300 seconds]。查看%FineBI6.0%\logs下fanruan.log檔案，看到報錯:java.until.concurrent.TimeoutException:Futures timed out after [300 seconds],如下圖所示：

解決方案

在finedb資料庫中找到表fine_conf_entity，並增加參數（ID)DistributedOptimizationConfig.spiderConfig.spark_sql_broadcastTimeout，將VALUE值設為 12000 即可。如下圖所示：

報錯現象

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

原因分析

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

解決方案

在 %FineBI6.0%/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 檔案。

原因分析

資料庫密碼過期。

解決辦法

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

解決辦法

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

原因分析

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

解決辦法

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

參數預設值：/DISTRIBUTED_LOCK_MANAGERTEST

原因分析

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

解決辦法

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

解決辦法

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

解決辦法

1）刪除定時更新任務的觸發記錄，刪除finedb中的QRTZ開頭的表中的所有資料，後重啓BI；

2）重新修改一下之前的定時任務，儲存。

原因分析

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

解決方案

關掉tomcat後重新啟動。

解決辦法

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

原因分析

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檔案

原因分析

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

解決方案

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

解決辦法

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

原因分析

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

原因分析

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

解決辦法

遷移資料庫

問題現象

com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Application was streaming results when the connection failed. Consider raising value of 'net_write_timeout' on the server.

原因分析

資料庫寫操作逾時

解決方法

1）可以調小一下基礎表更新執行緒的併發：設定該參數DistributedOptimizationConfig.spiderConfig.spider_base_update_thread_proportion，預設為30，可以設為20或25；

2）修改併發參數tableLoadThreadPoolNum，由預設20改為10；

3）調大net_write_timeout參數值：連結資料庫，執行show global variables like '%timeout%'，再執行 SET GLOBAL net_write_timeout = XXX（預設60，需要調大一點）

解決方法

更換lic檔案

原因分析

任務在更新中，此時重啓環境會認為更新中的更新失敗並報錯。

513 上報錯資訊會優化成：重啓BI後清理正在更新中的更新任務為失敗