排程管理常見問題

排程管理任務執行失敗時，可以在「運作監視」的「任務執行明細」中看到日誌旁的問號標籤。

點選該標籤即可查看詳細的錯誤資訊。本文將介紹排程管理任務中的常見錯誤及其解決方案。

指定BI排程管理任務執行節點

應用場景：

對於多節點叢集工程，使用者希望指定bi節點不執行排程管理任務，以確定業務資源

使用者可透過新增工程節點啟動參數-Dschedule.disable=true實現

• 對於配置了該參數值為true的工程節點，將不執行定時的調度任務，但仍然執行手動觸發的調度任務

• 對於未配置該參數，或參數值為false的工程節點，將執行所有調度任務

配置方法（僅面向非維運平台部署的工程）：

• Windows：進入%Tomcat_HOME%\bin目錄。尋找名為setenv.bat的檔案。如果檔案不存在，可以建立一個新的setenv.bat檔案。在檔案中新增以下行來設定，配置完成後重啟工程。

set  JAVA_OPTS=%JAVA_OPTS% -Dschedule.disable=true

• Linux：進入%Tomcat_HOME%\bin目錄。尋找名為setenv.sh的檔案。如果檔案不存在，可以建立一個新的setenv.sh檔案。在檔案中新增以下行來設定，配置完成後重啟工程。

JAVA_OPTS="$JAVA_OPTS -Dschedule.disable=true"

調整BI排程管理任務執行緒數

應用場景：

當BI排程管理任務併發較高時，任務執行可能出現延遲。

使用者可透過調整BI排程管理任務的執行執行緒數，來改善該情況。

配置方法：

超級管理者可透過V1.9.31及以上版本「fine_conf_entity視覺化配置」插件，配置BI排程管理任務併發執行緒數。

重啟伺服器後設定生效。

注：修改 FineDB 資料庫表欄位值的方法請參考  fine_conf_entity視覺化配置 。

調整FR排程管理任務執行緒數

應用場景：

單個FR排程管理任務，可能會對多個使用者單獨產生結果，因此在呼叫範本時產生的資料連結數也會增多，

如果資料連結數超出了最大連結數限制，可能會導致資料庫壓力過大，進而導致排程管理任務失敗。

報錯：ERROR：dn_6003_6004：[FATAL]Already too many clients

解決方案：

超級管理者可透過「fine_conf_entity視覺化配置」插件，降低FR排程管理模組最大執行緒數和最大連結數，減小資料庫的併發壓力。

重啟伺服器後設定生效。

注：修改 FineDB 資料庫表欄位值的方法請參考  fine_conf_entity視覺化配置 。

調整排程管理任務逾時提示

原因分析：

排程管理任務在執行超過 5 分鐘（預設）時，會有提示：TimeoutException

提示並不會中斷任務執行，如果任務後續執行成功了，會正常記錄成功日誌。

解決方案：

超級管理者可透過「fine_conf_entity視覺化配置插件」關閉逾時提示或者延長逾時提示出現的時間。

重啟伺服器後設定生效。

注：修改 FineDB 資料庫表欄位值的方法請參考  fine_conf_entity視覺化配置 。

修改排程管理附件語言

在「調度物件」步驟中若勾選「附件存檔」，排程管理任務結束後生成的附件可修改語言。

超級管理者可透過「fine_conf_entity視覺化配置插件」改變排程管理生成附件的語言。重啟伺服器後設定生效。

注：修改 FineDB 資料庫表欄位值的方法請參考 FineDB 常用表欄位修改 。

Result file creation failed

報錯資訊：

報錯內容：Result file creation failed: (附件名稱)

此類錯誤通常會導致後續的附件處理任務（如郵件傳送等）出現找不到檔案的報錯，或傳送的附件大小為 0KB 等問題。

原因分析：

排程管理任務可能會生成各類檔案，而檔案的命名來源於排程管理任務設定中的「檔案名稱」。

若「檔案名稱」中使用了公式，計算後的實際檔案名稱可能會超出作業系統對檔案名稱長度的限制（通常為 255 個字元），進而導致檔案生成失敗。

解決方案：

請修改排程管理任務中的「檔案名稱」設定，使用更短的檔案名稱以避免該問題。

Query: wait millis xxxxx, active xx, maxActive xxxx

報錯資訊：

報錯資訊：資料集配置錯誤Query: wait millis xxxxx, active xx, maxActive xxxx

原因分析：

在排程管理任務執行範本計算時，系統需要連結範本所使用的資料源進行取數。

當資料連結逾時時，系統將報錯提示資料集配置錯誤。

解決方案：

管理者可登入帆軟應用，依次點選「管理系統 > 資料連結」，找到排程管理任務所使用的資料連結，並增大「最大等待時間」。

如下圖所示。

535 Error: authentication failed

報錯資訊：

報錯資訊：535 Error: authentication failed，如下圖所示：

原因分析：

帆軟應用「管理系統>系統管理>信箱」中的寄件人設定錯誤。

寄件人的地址或密碼不正確。

解決方案：

請參考「郵箱」中的配置步驟，覈對信箱寄件人配置。

注意，對於大部分信箱，SMTP 伺服器的帳號密碼跟登入信箱的帳號密碼並不相同，請務必仔細檢查。

Couldn't connect to host

報錯資訊：

報錯資訊為Couldn't connect to host（timeout可能為其他值），如下圖所示：

原因分析：

因為網路原因無法連結到 SMTP 伺服器。

解決方案：

檢查配置的 SMTP 伺服器地址和埠是否正確且能聯通。可以 ping 地址得到 ip ，然後「telnet ip port」確認能否聯通。

1）首先確認所填寫的郵件伺服器地址和埠都是正確的，並且傳送測試郵件。如果測試郵件都無法成功傳送，說明郵件伺服器有問題。請去郵件用戶端再次確認下。

2）如果郵件伺服器測試傳送郵件成功，但是偶爾還是有任務失敗，報錯相同，可能原因是當時網路不通暢，連結不上郵件伺服器。

3）或者是信箱伺服器的併發過大，導致伺服器處於無法回应的狀態，進而連結不上伺服器。

要麼提高信箱伺服器的效能，要麼將工程傳送郵件的任務時間間隔開，不要併發到一個時間段。

Invalid Addresses

報錯資訊：

報錯資訊為Invalid Addresses，如下圖所示：

原因分析：

收件人（或副本、密送）中含有無效信箱地址，具體地址也會一同提示，如上圖中的notexist12345@163.com。

解決方案：

1）檢查並刪除收件人（或副本、密送）中的無效信箱地址。

2）若定時任務中有很多收件人，排查較困難，可以勾選「根據使用者單獨生成結果」。

在運作監視資訊中可以看到只有無效的收件人會失敗，其他正常使用者會傳送成功，將無效的收件剔除或修改正確即可。

response: 421

報錯資訊：

com.fr.schedule.output.EmailException: javax.mail.MessagingException: Could not connect to SMTP host: SMTP.163.com, port: 25, response: 421；

原因分析：

• 信箱伺服器地址和埠配置存在問題。

• SMTP 主機已達最大聯機數量。

解決方案：

• 請收信者和郵件管理者確認收信端郵件伺服器是否正常作業。

• 收件者 SMTP 主機拒絕提供服務，因為已經超過其能提供的最大服務量。可透過提高 SMTP 伺服器的頻率或者將任務拆分開來解決。

com.sun.mail.smtp.SMTPSendFailedException: 554

報錯資訊：

com.sun.mail.smtp.SMTPSendFailedException: 554

原因分析：

郵件伺服器將郵件當成了垃圾郵件。

解決方案：

由於每個信箱都有反垃圾郵件的功能，規則各有不同。

1）首先建議點開信箱的「垃圾箱」，找回郵件。

2）將寄件人的信箱地址新增到信箱的「通訊錄」中，以防被誤判成垃圾郵件。

too many recipients

報錯資訊：

定時任務傳送郵件，收件人數量較多時，SMTP 伺服器報錯，報錯內容中含too many recipients字樣， 如下圖所示：

原因分析：

平台負責將郵件資訊（收件人、副本、密送、主題、正文等）傳送給 SMTP 伺服器，由 SMTP 伺服器根據這些資訊傳送郵件，平台本身並不進行實際郵件的傳送；

造成該報錯的實際原因為「收件人」或「副本」或「密送」的信箱數量超過了 SMTP 伺服器的限制，不同的 SMTP 伺服器所限制的數量可能不一樣。

解決方案：

方案一：減少預設使用者組中使用者的數量，由於不同的 SMTP 伺服器所限制的數量可能不一樣，建議使用者數量在 500 以內。

方案二：提高 SMTP 伺服器對收件人的限制，需要客戶方的 SMTP 伺服器管理人員做修改，由於不同的 SMTP 伺服器修改方式不相同，本文暫不提供修改方法。

郵件傳送成功但收不到郵件

報錯資訊：

無報錯資訊，運作監視中顯示郵件傳送成功，但實際沒有收到。

原因分析：

原因一般是 SMTP 伺服器投遞的郵件被收件人信箱拒收了。可以登入 SMTP 服務對應的信箱（即「系統管理」中配置的信箱），檢查是否有退信相關郵件。

解決方案：

根據對應信箱的退信規則，排查退信原因。

sender thread limit exceeded

報錯資訊：

信箱類型為 Outlook 信箱，報錯：STOREDRV.ClientSubmit; sender thread limit exceeded

原因分析：

Microsoft 限制同時間只支援 3 條執行緒併發傳送郵件，超過 3 條則會丟擲以上異常，Outlook的信箱預設會有這個限制。

排程管理的信箱傳送郵件是多執行緒的，所以可能會出現執行緒超出3的情況。

解決方案：

JAR 包版本在 2019-08-16 之後的報表伺服器，超級管理者可透過「fine_conf_entity視覺化配置插件」修改排程管理模組最大執行緒數。

按照 Microsoft 的限制，把 QuartzConfig.threadCount 的值改為 3 或小於 3 ，就可以避免排程管理由於執行緒超出而失敗。

重啟伺服器後設定生效。

注：修改 FineDB 資料庫表欄位值的方法請參考 FineDB 常用表欄位修改 。

附件亂碼

問題描述：

Linux 系統中，定時任務「調度物件」中物件類型為BI 範本，附件中的 PDF 檔案中文亂碼，圖表組件和表格組件也出現中文亂碼的情況。

原因分析：

系統沒有安裝中文字體。

解決方案：

系統安裝對應字體後，排程管理匯出的檔案正常。

郵件正文空格顯示問題

問題描述：

郵件正文內容中的多個空格被合併為一個，行首空格不顯示。

解決方案：

郵件正文中若需在行首輸入空格，或在行內連續輸入多個空格時，要將這些空格更換為同等數量的「 」。如下圖所示：

結果連結無法正常跳轉

問題描述：

設定定時任務傳送郵件時，在「郵件通知」中勾選了「正文加上結果連結」，點選郵件中的結果連結，出現圖一或圖二的報錯，報錯內容：非常抱歉，您無法查看該頁面，如需存取請聯絡管理者

如下圖所示：

原因分析：

可能是使用者在「調度物件」步驟中勾選了「任務結束即清理」。

解決方案：

取消勾選「任務結束即清理」，勾選「僅保留最近一次」、「僅保留最近5次」、「不清理」、「自訂」中任意一個即可。

遷移 FineDB 資料庫後郵件傳送失敗

問題描述：

定時任務傳送郵件，沒有「運作監視」，也沒有收到簡訊，後台報錯：

couldn't store job:Packet for query is too large (35045785>4194304).You can change this value on the server by setting the max_allowed_packet' variable.

原因分析：

使用者將內建 FineDB 資料庫遷移到本地 MySQL 資料庫中，本地 MySQL 資料庫中「max_allowed_packet」值設定過小導致單個記錄超過限制後寫入資料庫失敗，且後續記錄寫入也會失敗。

解決方案：

方案一：

MySQL 安裝目錄下的「my.ini」檔案中的[mysqld] 欄位中的「max_allowed_packet = 1M」修改為 500M ，重啟 MySQL 即可。

方案二：

1）使用「set global max_allowed_packet = 524288000;」 語句將「max_allowed_packet」的值設定為 500 M。

2）使用「show VARIABLES like '%max_allowed_packet%';」 語句查看是否修改成功。

工程共用 FineDB 資料庫導致定時任務執行失敗

問題描述：

1）排程管理任務手動執行正常，比如立即執行一次這種，還有剛建立任務立即執行也正常。

2）排程管理任務定時執行，偶爾不執行或一直不執行，但任務下次執行時間正常變化。

3）排程管理任務定時執行，郵件傳送成功，但是附件為 0kb。

4）在運作監視中不存在排程管理任務未執行的時間點記錄，後台日誌也不見該時間點的日誌和報錯。

5）排程管理任務設定了開始時間，但在開始時間後任務停止且沒有繼續任務的按鈕，或者偶爾執行成功，但再次點選執行時會提示任務已被刪除。

原因分析：

多個工程連結了同一 FineDB 資料庫，導致排程管理的定時執行，可能執行到其他工程上去了。

排查步驟：

1）排查有幾台機器連結着平台的FineDB資料庫

使用對應SQL語句查詢有幾台機器連結了 finedb 資料庫，當有多個機器連結時，排查下其他機器上是否也有部署工程。

• MySQL：

select * from information_schema.processlist where DB like '%遷移的資料庫名%';

• Oracle：

select sid,serial#,username,program,machine,terminal,osuser,process,client_info from v$session where username is not null order by username,program,machine;

• SqlServer：

select t2.name, t3.client_net_address, t1.host_name, t1.login_time, t1.status, t1.last_request_start_time from master.sys.dm_exec_sessions t1 inner join master.dbo.SYSDATABASES t2 on t1.database_id=t2.dbid inner join master.sys.dm_exec_connections t3 on t1.session_id=t3.session_id where t2.name = '資料庫名';

2）排查該機器下是否有多個運作着平台的容器

使用ps -ef | grep java檢查伺服器下是否有多個容器開啟了報表工程，若有，則一一排查對應的 finedb 資料庫

3）排查虛擬目錄配置情況

僅限Tomcat、Resin等可以配置虛擬目錄的容器。

webapps 下的 webroot 項目會被 tomcat 自動啟動，如果又配了虛擬目錄指向這個 webroot，就會被啟動 2 次。

• conf/server.xml裏搜一下Context，看有沒有docBase指向webroot的Context。

• conf/Catalina/localhost下有沒有指向webroot的xml檔案。

逾時報錯

問題描述：

排程管理傳送郵件失敗，報錯如下所示：

com.fr.restriction.MemoryAlarmException:很抱歉，sql 執行時間過長觸發保護機制，請稍後重試。若您是管理者，可於智慧維運-記憶體管理-範本限制中更改此項限制。

解決方案：

關閉所有 範本限制

郵件結果連結 URL 以 localhost 開頭

問題描述：

排程管理任務「調度物件」步驟中「物件類型」選擇「報表範本」，「檔案處理」步驟中，處理方式選擇「郵件通知」，「郵件內容設定項」中勾選「正文加上結果連結」。收到的郵件點選結果連結，連結 URL 以localhost開頭。如下圖所示：

使用者希望localhost轉成實際 IP 。

解決方案：

1）將數據決策系統的 URL 改成實際 IP ，例如：http://ip:埠/工程名/decision，如下圖所示：

2）在平台建立排程管理任務或重新編輯儲存之前任務，點選郵件中的結果連結，連結 URL 開頭改變。如下圖所示：

排程管理任務總是提前/延後固定小時數執行

問題描述：

排程管理任務總是提前/延後數小時執行，且該值恆定，常見的為 8 小時等。

原因分析：

首先排查 FineDB 所在機器時區是否正確，Windows 則在命令提示符下使用tzutil /g，回顯China Standard Time則為正常，Linux 則在 Bash 下使用date -R，回顯中包含 +0800 則為正常。

其次排查平台工程所在機器時區是否正確，方法同上。

最後排查平台所在工程 JVM 時區是否正確，可建立類 Test ，內容為下述程式碼，編譯成Test.class檔案上傳至平台工程所在機器，執行java Test，若回顯Asia/Shanghai則為正確。

import java.util.TimeZone;
public class Test{
  public static void main(String[] args) {
   System.out.println(TimeZone.getDefault()); 
  }
}

上述回顯的具體時區，以客戶實際所在時區為準。

解決方案：

若機器時區不正確，則聯絡客戶修改系統時區。

若 JVM 時區不正確，則需要新增-Duser.timezone=Asia/Shanghai的 JVM 啟動參數：如果是 Tomcat 等容器啟動，則新增至容器的JAVA_OPTS位置，與設定記憶體大小的 -Xmx/-Xms 位置相同；如果是設計器/安裝版 BI 直接啟動，在啟動器同目錄下有designer.vmoptions或finebi.vmoptions，將上述參數新增至其中即可。

刪除定時任務中使用者資訊報錯提示

排程管理任務設定時，「基本設定>預設使用者組」中，支援配置系統中的使用者、部門、角色。

若管理者在「使用者管理」中刪除了該任務配置的相關使用者、部門、角色，再次執行排程管理任務，fanruan.log日誌檔案中顯示error級別報錯提醒。

具體報錯邏輯如下表所示：

MySQL中資料表編碼不一致

報錯資訊：

報錯資訊為Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '='

原因分析：

MySQL 資料庫中資料表的編碼方式不一致，在取數後無法進行比較，導致定時任務執行失敗。

解決方案：

將 MySQL 資料庫以及資料表的編碼統一修改為 uft8。

1）檢查 MySQL 資料庫的編碼和排序規則。

查看字元集：SHOW VARIABLES LIKE 'character%';

查看排序方式：SHOW VARIABLES LIKE 'collation_%';

2）若 MySQL 資料庫的字元集編碼為非 uft8，透過以下步驟修改字元集編碼：

修改 MySQL 的 my.ini 檔案中的字元集鍵值。

default-character-set = utf8 character_set_server = utf8

修改完後，重啟 MySQL 的服務

service mysql restart

使用命令查看，發現資料庫編碼均已改成 UTF-8。

mysql> SHOW VARIABLES LIKE 'character%';

3）資料庫編碼正常的情況下，檢查資料表中所有列的編碼和排序規則。

show full COLUMNS from 表名; 

4）檢查出異常編碼的資料表後，修改編碼為 utf8 即可。

ALTER TABLE `表名` CONVERT TO CHARACTER SET utf8;