http://starrocks.io logo
Join Slack
Powered by
<@U0A71G31CDV> what is my BE error? [root@dc-star...
# questions-and-troubleshooting
l
@Rocky what is my BE error? [root@dc-starrock-02 log]# tail -f -n100 be.out [1779791467.48][thread: 23026043033152] je_mallctl execute purge success [1779791467.48][thread: 23026043033152] je_mallctl execute dontdump success * Aborted at 1779791467 (unix time) try "date -d @1779791467" if you are using GNU date * PC: @ 0x14f15a68d02c __pthread_kill_implementation * SIGABRT (@0x39bb94) received by PID 3783572 (TID 0x14f12b1d9640) LWP(3783915) from PID 3783572; stack trace: * @ 0x14f15a6904f8 __pthread_once_slow @ 0xdee2e94 google::(anonymous namespace)::FailureSignalHandler(int, siginfo_t*, void*) @ 0x14f15a63fc30 (/usr/lib64/libc.so.6+0x3fc2f) @ 0x14f15a68d02c __pthread_kill_implementation @ 0x14f15a63fb86 __GI_raise @ 0x14f15a629873 __GI_abort @ 0x8e39b73 starrocks::failure_function() @ 0xded7c8a google:LogMessage:Fail() @ 0xded96c4 google:LogMessageFatal:~LogMessageFatal() @ 0x8512597 starrocks:JVMFunctionHelper:getInstance() @ 0xaad70fa starrocks:JDBCScanner:_close_jdbc_scanner() @ 0xaad72e1 starrocks:JDBCScanner:close(starrocks::RuntimeState*) @ 0xaa23301 starrocks:connectorJDBCDataSource:close(starrocks::RuntimeState*) @ 0xa15cf90 starrocks:pipelineScanOperator:_close_chunk_source_unlocked(starrocks::RuntimeState*, int) @ 0xa15beec starrocks:pipelineScanOperator:_finish_chunk_source_task(starrocks::RuntimeState*, int, long, long, long) @ 0xa162fec auto starrocks:pipelineScanOperator:_trigger_next_scan(starrocks::RuntimeState*, int)::{lambda(auto:1&)#1}::operator()<starrocks:workgroup:YieldContext>(starrocks:workgroup:YieldContext&) const [clone .isra.0] @ 0xa2a87bf starrocks:workgroupScanExecutor:worker_thread() @ 0x8673f77 starrocks:ThreadPool:dispatch_thread() @ 0x866ac70 starrocks:🧵:supervise_thread(void*) @ 0x14f15a68b2ea start_thread @ 0x14f15a710500 __clone3 start time: Tue May 26 054630 PM +07 2026, server uptime: 174630 up 81 days, 12 min, 2 users, load average: 0.00, 0.05, 0.45 Run with JEMALLOC_CONF: 'percpu_arenapercpu,oversize threshold0,muzzy_decay_ms5000,dirty decay ms5000,metadata_thpauto,background threadtrue,proftrue,prof activefalse' unsupported call jni function, JAVA_HOME is required JNI_GetCreatedJavaVMs failed with error: -1 getJNIEnv: getGlobalJNIEnv failed unsupported call jni function, JAVA_HOME is required JNI_GetCreatedJavaVMs failed with error: -1 getJNIEnv: getGlobalJNIEnv failed F20260526 174922.910195 23408687052352 java_udf.cpp:121] Check failed: _env != nullptr couldn't got a JNIEnv 4.0.10 RELEASE (build 5b36164 distro centos arch x86_64) query_id:019e63e6-94d7-7e4a-a7a4-c2dfbc4b20d0, fragment_instance:019e63e6-94d7-7e4a-a7a4-c2dfbc4b20d1, plan_node_id:0 [1779792562.910][thread: 23408687052352] je_mallctl execute purge success [1779792562.910][thread: 23408687052352] je_mallctl execute dontdump success * Aborted at 1779792562 (unix time) try "date -d @1779792562" if you are using GNU date * PC: @ 0x154aa928d02c __pthread_kill_implementation * SIGABRT (@0x3d015c) received by PID 3998044 (TID 0x154a4279f640) LWP(3998419) from PID 3998044; stack trace: * @ 0x154aa92904f8 __pthread_once_slow @ 0xdee2e94 google::(anonymous namespace)::FailureSignalHandler(int, siginfo_t*, void*) @ 0x154aa923fc30 (/usr/lib64/libc.so.6+0x3fc2f) @ 0x154aa928d02c __pthread_kill_implementation @ 0x154aa923fb86 __GI_raise @ 0x154aa9229873 __GI_abort @ 0x8e39b73 starrocks::failure_function() @ 0xded7c8a google:LogMessage:Fail() @ 0xded96c4 google:LogMessageFatal:~LogMessageFatal() @ 0x8512597 starrocks:JVMFunctionHelper:getInstance() @ 0xaad70fa starrocks:JDBCScanner:_close_jdbc_scanner() @ 0xaad72e1 starrocks:JDBCScanner:close(starrocks::RuntimeState*) @ 0xaa23301 starrocks:connectorJDBCDataSource:close(starrocks::RuntimeState*) @ 0xa15cf90 starrocks:pipelineScanOperator:_close_chunk_source_unlocked(starrocks::RuntimeState*, int) @ 0xa15beec starrocks:pipelineScanOperator:_finish_chunk_source_task(starrocks::RuntimeState*, int, long, long, long) @ 0xa162fec auto starrocks:pipelineScanOperator:_trigger_next_scan(starrocks::RuntimeState*, int)::{lambda(auto:1&)#1}::operator()<starrocks:workgroup:YieldContext>(starrocks:workgroup:YieldContext&) const [clone .isra.0] @ 0xa2a87bf starrocks:workgroupScanExecutor:worker_thread() @ 0x8673f77 starrocks:ThreadPool:dispatch_thread() @ 0x866ac70 starrocks:🧵:supervise_thread(void*) @ 0x154aa928b2ea start_thread @ 0x154aa9310500 __clone3 start time: Tue May 26 060209 PM +07 2026, server uptime: 180209 up 81 days, 28 min, 2 users, load average: 0.24, 0.81, 1.58 Run with JEMALLOC_CONF: 'percpu_arenapercpu,oversize threshold0,muzzy_decay_ms5000,dirty decay ms5000,metadata_thpauto,background threadtrue,proftrue,prof activefalse' unsupported call jni function, JAVA_HOME is required JNI_GetCreatedJavaVMs failed with error: -1 getJNIEnv: getGlobalJNIEnv failed unsupported call jni function, JAVA_HOME is required JNI_GetCreatedJavaVMs failed with error: -1 getJNIEnv: getGlobalJNIEnv failed F20260526 180319.128356 23003322230336 java_udf.cpp:121] Check failed: _env != nullptr couldn't got a JNIEnv 4.0.10 RELEASE (build 5b36164 distro centos arch x86_64) query_id:019e63f3-573a-783c-a579-fd196fd2b12d, fragment_instance:019e63f3-573a-783c-a579-fd196fd2b12e, plan_node_id:0 [1779793399.128][thread: 23003322230336] je_mallctl execute purge success [1779793399.128][thread: 23003322230336] je_mallctl execute dontdump success * Aborted at 1779793399 (unix time) try "date -d @1779793399" if you are using GNU date * PC: @ 0x14ec2808d02c __pthread_kill_implementation * SIGABRT (@0x3d0654) received by PID 3999316 (TID 0x14ebe0d9a640) LWP(3999685) from PID 3999316; stack trace: * @ 0x14ec280904f8 __pthread_once_slow @ 0xdee2e94 google::(anonymous namespace)::FailureSignalHandler(int, siginfo_t*, void*) @ 0x14ec2803fc30 (/usr/lib64/libc.so.6+0x3fc2f) @ 0x14ec2808d02c __pthread_kill_implementation @ 0x14ec2803fb86 __GI_raise @ 0x14ec28029873 __GI_abort @ 0x8e39b73 starrocks::failure_function() @ 0xded7c8a google:LogMessage:Fail() @ 0xded96c4 google:LogMessageFatal:~LogMessageFatal() @ 0x8512597 starrocks:JVMFunctionHelper:getInstance() @ 0xaad70fa starrocks:JDBCScanner:_close_jdbc_scanner() @ 0xaad72e1 starrocks:JDBCScanner:close(starrocks::RuntimeState*) @ 0xaa23301 starrocks:connectorJDBCDataSource:close(starrocks::RuntimeState*) @ 0xa15cf90 starrocks:pipelineScanOperator:_close_chunk_source_unlocked(starrocks::RuntimeState*, int) @ 0xa15beec starrocks:pipelineScanOperator:_finish_chunk_source_task(starrocks::RuntimeState*, int, long, long, long) @ 0xa162fec auto starrocks:pipelineScanOperator:_trigger_next_scan(starrocks::RuntimeState*, int)::{lambda(auto:1&)#1}::operator()<starrocks:workgroup:YieldContext>(starrocks:workgroup:YieldContext&) const [clone .isra.0] @ 0xa2a87bf starrocks:workgroupScanExecutor:worker_thread() @ 0x8673f77 starrocks:ThreadPool:dispatch_thread() @ 0x866ac70 starrocks:🧵:supervise_thread(void*) @ 0x14ec2808b2ea start_thread @ 0x14ec28110500 __clone3
r
The error in your logs indicates that the StarRocks Backend (BE) process is crashing because it cannot find or initialize a Java Virtual Machine (JVM). This is required for features like JDBC Catalogs, External Tables, or Java UDFs. Cause The BE process attempted to use a JNI (Java Native Interface) function, but failed with: 
unsupported call jni function, JAVA_HOME is required
Check failed: _env != nullptr couldn't got a JNIEnv
Because the 
JAVA_HOME
environment variable is missing or incorrectly configured, the BE cannot load the necessary Java libraries. When a query (like the one in your log: 
query_id: 019e63e6...
) tried to use the JDBCScanner, the system hit a fatal check and aborted (
SIGABRT
). How to Fix 1. Identify your JDK path: Find the absolute path where the JDK is installed on your BE machine (e.g., 
/usr/lib/jvm/java-11-openjdk
). Ensure it is a JDK, not just a JRE. 2. Configure 
be.conf
: Edit your 
be/conf/be.conf
file and add the 
JAVA_HOME
variable:
Copy code
bash
    JAVA_HOME = /path/to/your/jdk
3. Alternative (Startup Script): Alternatively, you can export 
JAVA_HOME
at the beginning of the 
be/bin/start_be.sh
script:
Copy code
bash
    export JAVA_HOME=/path/to/your/jdk
4. Verify 
libjvm.so
visibility: The BE needs to find 
libjvm.so
. Usually, setting 
JAVA_HOME
in 
be.conf
is enough, as StarRocks will look for it in 
$JAVA_HOME/lib/server
or 
$JAVA_HOME/jre/lib/amd64/server
. 5. Restart the BE: After making the changes, restart the BE process:
Copy code
bash
    bin/stop_be.sh
    bin/start_be.sh --daemon
Summary of what happened A query was initiated (likely against a JDBC Catalog) which required the BE to spin up a JVM instance. Since 
JAVA_HOME
wasn't set, the JNI environment failed to initialize, and the BE "failed fast" by crashing to avoid inconsistent states its dependency requirement. References • faq/Deploy_faq.md • deployment/environment_configurations.md • administration/management/BE_configuration.md • data_source/catalog/jdbc_catalog.md • deployment/deploy_manually.md • sql-reference/sql-functions/JAVA_UDF.md
l
@Rocky my current two starrocks server run on DC site, can i install one new starrocks server on DR site, and have a cluster of 3 server, where my bandwith between DC-DR is 10 GB/s
r
While a 10 GB/s bandwidth is excellent, deploying a single StarRocks cluster stretched across two sites (2 nodes in DC, 1 node in DR) is generally not recommended for a production disaster recovery (DR) strategy. Here is a breakdown of why this architecture is problematic and what you should consider instead. 1. The Quorum Problem (High Availability Risk) StarRocks' Frontend (FE) nodes use a consensus protocol (BDBJE/Raft) to manage metadata. This requires a majority of nodes to be alive for the cluster to function. * Total nodes: 3 * Majority needed: 2 * Scenario: If your main DC site goes down, you lose 2 nodes. The 1 remaining node in the DR site cannot form a majority (1 out of 3). * Result: Even though your DR node is running, the cluster will stop working because it cannot elect a leader. This defeats the primary purpose of a DR site. 2. Latency vs. Bandwidth Even with 10 GB/s bandwidth, the network latency (RTT) between your DC and DR sites is typically much higher than within a single local network. * Write Performance: StarRocks usually writes data to multiple replicas (default is 3). In a stretched cluster, every data load must wait for the DR node to acknowledge the write over the cross-site link. High latency will significantly slow down your ingestion speed. * Query Performance: Queries often "shuffle" data between nodes. If one node is across a high-latency link, the entire query must wait for that data transfer, leading to poor and inconsistent query performance. 3. Data Distribution Issues StarRocks attempts to balance data across all BE nodes. Without explicit "rack-aware" configuration (which is complex to manage in a 2+1 setup), the cluster might place 2 of 3 replicas in the DC and 1 in the DR. If the DC fails, you lose the 2 replicas, and even if the cluster could stay up, you would have incomplete data availability for many tablets. ────────── Recommended DR Strategy Instead of one "stretched" cluster, the standard best practice for StarRocks is to maintain two separate clusters: 1. Primary Cluster (DC): A 3-node (or more) cluster for your daily operations. 2. Standby Cluster (DR): A separate cluster in your DR site. 3. Data Synchronization: * Backup and Restore: Use StarRocks' 
BACKUP
and 
RESTORE
commands to sync data via shared object storage (like S3, MinIO, or HDFS). * Cross-cluster Data Migration Tool: Use the StarRocks migration tool or StarRocks' "Sync" features to replicate tables from the Primary to the Standby cluster. * External Loading: Point your data loading pipelines (e.g., Flink, Routine Load) to both clusters simultaneously or trigger a secondary load to the DR site. Summary If you proceed with a 3-node stretched cluster, you will gain a third node for compute, but you will not gain true site-level Disaster Recovery, and you will likely see a significant decrease in system performance due to inter-site latency. References • deployment/plan_cluster.md • administration/cluster_snapshot.md • administration/management/resource_management/Replica.md • faq/Deploy_faq.md Deploy_faq) References • administration/data_migration_tool.md • administration/cluster_snapshot.md • administration/management/resource_management/Replica.md • faq/Exporting_faq.md
l
@Rocky my oracle external table as below: -- dmapp_link.dtm_customer_ld_summary_posted2_link definition CREATE EXTERNAL TABLE 
dtm_customer_ld_summary_posted2_link
( 
SYS_RUN_DATE
datetime NULL COMMENT "", 
ld_no
varchar(20) NULL COMMENT "", 
day_int_posted
decimal(38, 20) NULL COMMENT "", 
day_od_posted
decimal(38, 20) NULL COMMENT "", 
next_payoff_amount
decimal(38, 20) NULL COMMENT "", 
next_od_po_amt
decimal(38, 20) NULL COMMENT "", 
paid_tern
decimal(38, 20) NULL COMMENT "", 
paid_term_user
decimal(38, 20) NULL COMMENT "", 
MIN_AMT_MUST_COLLECTED_BOM
decimal(38, 20) NULL COMMENT "", 
OD_TO_EOM_AMT
decimal(38, 20) NULL COMMENT "" ) ENGINE=JDBC PROPERTIES ( "resource" = "DMAPP_JDBC", "table" = "DMAPP.dtm_customer_ld_summary" ); i can query this table as: select a.SYS_RUN_DATE, a.ld_no, next_payoff_amount, next_od_po_amt, day_int_posted, day_od_posted, paid_tern, paid_term_user, MIN_AMT_MUST_COLLECTED_BOM, OD_TO_EOM_AMT from dmapp_link.dtm_customer_ld_summary_posted2_link a where a.SYS_RUN_DATE = '08Dec25' but when i run update from this query , i got error: UPDATE dmapp.dtm_customer_ld_summary SET next_payoff_amount = n.next_payoff_amount, next_od_po_amt = n.next_od_po_amt, day_int_posted = n.day_int_posted, day_od_posted = n.day_od_posted, paid_tern = n.paid_tern, paid_term_user = n.paid_term_user, MIN_AMT_MUST_COLLECTED_BOM = n.MIN_AMT_MUST_COLLECTED_BOM, OD_TO_EOM_AMT = n.OD_TO_EOM_AMT FROM (select a.SYS_RUN_DATE, a.ld_no, next_payoff_amount, next_od_po_amt, day_int_posted, day_od_posted, paid_tern, paid_term_user, MIN_AMT_MUST_COLLECTED_BOM, OD_TO_EOM_AMT from dmapp_link.dtm_customer_ld_summary_posted2_link a where a.SYS_RUN_DATE = '08Dec25') n WHERE dmapp.dtm_customer_ld_summary.sys_run_date = n.sys_run_date AND dmapp.dtm_customer_ld_summary.ld_no = n.ld_no AND dmapp.dtm_customer_ld_summary.sys_run_date =date'2025-12-08'; SQL Error [5609] [22001]: Data truncation: open JDBCScanner failed, error: java.sql.SQLDataException: ORA-01861: literal does not match format string at oracle.jdbc.driver.T4CTTIoer11.processError(T4CTTIoer11.java:509) at oracle.jdbc.driver.T4CTTIoer11.processError(T4CTTIoer11.java:461) at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:1104) at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:553) at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:269) at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:655) at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:270) at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:91) at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:807) at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:983) at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1168) at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3666) at oracle.jdbc.driver.T4CPreparedStatement.executeInternal(T4CPreparedStatement.java:1426) at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3713) at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeQuery(OraclePreparedStatementWrapper.java:1167) at com.zaxxer.hikari.pool.ProxyPreparedStatement.executeQuery(ProxyPreparedStatement.java:52) at com.zaxxer.hikari.pool.HikariProxyPreparedStatement.executeQuery(HikariProxyPreparedStatement.java) at com.starrocks.jdbcbridge.JDBCScanner.open(JDBCScanner.java:96) Caused by: Error : 1861, Position : 221, Sql = SELECT SYS_RUN_DATE, ld_no, day_int_posted, day_od_posted, next_payoff_amount, next_od_po_amt, paid_tern, paid_term_user, MIN_AMT_MUST_COLLECTED_BOM, OD_TO_EOM_AMT FROM DMAPP.dtm_customer_ld_summary WHERE (SYS_RUN_DATE = '2025-12-08 000000') AND(SYS_RUN_DATE = '08Dec25'), OriginalSql = SELECT SYS_RUN_DATE, ld_no, day_int_posted, day_od_posted, next_payoff_amount, next_od_po_amt, paid_tern, paid_term_user, MIN_AMT_MUST_COLLECTED_BOM, OD_TO_EOM_AMT FROM DMAPP.dtm_customer_ld_summary WHERE (SYS_RUN_DATE = '2025-12-08 000000') AND(SYS_RUN_DATE = '08Dec25'), Error Msg = ORA-01861: literal does not match format string at oracle.jdbc.driver.T4CTTIoer11.processError(T4CTTIoer11.java:513) ... 17 more : BE:10002 Data truncation: open JDBCScanner failed, error: java.sql.SQLDataException: ORA-01861: literal does not match format string at oracle.jdbc.driver.T4CTTIoer11.processError(T4CTTIoer11.java:509) at oracle.jdbc.driver.T4CTTIoer11.processError(T4CTTIoer11.java:461) at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:1104) at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:553) at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:269) at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:655) at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:270) at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:91) at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:807) at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:983) at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1168) at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3666) at oracle.jdbc.driver.T4CPreparedStatement.executeInternal(T4CPreparedStatement.java:1426) at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3713) at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeQuery(OraclePreparedStatementWrapper.java:1167) at com.zaxxer.hikari.pool.ProxyPreparedStatement.executeQuery(ProxyPreparedStatement.java:52) at com.zaxxer.hikari.pool.HikariProxyPreparedStatement.executeQuery(HikariProxyPreparedStatement.java) at com.starrocks.jdbcbridge.JDBCScanner.open(JDBCScanner.java:96) Caused by: Error : 1861, Position : 221, Sql = SELECT SYS_RUN_DATE, ld_no, day_int_posted, day_od_posted, next_payoff_amount, next_od_po_amt, paid_tern, paid_term_user, MIN_AMT_MUST_COLLECTED_BOM, OD_TO_EOM_AMT FROM DMAPP.dtm_customer_ld_summary WHERE (SYS_RUN_DATE = '2025-12-08 000000') AND(SYS_RUN_DATE = '08Dec25'), OriginalSql = SELECT SYS_RUN_DATE, ld_no, day_int_posted, day_od_posted, next_payoff_amount, next_od_po_amt, paid_tern, paid_term_user, MIN_AMT_MUST_COLLECTED_BOM, OD_TO_EOM_AMT FROM DMAPP.dtm_customer_ld_summary WHERE (SYS_RUN_DATE = '2025-12-08 000000') AND(SYS_RUN_DATE = '08Dec25'), Error Msg = ORA-01861: literal does not match format string at oracle.jdbc.driver.T4CTTIoer11.processError(T4CTTIoer11.java:513) ... 17 more : BE:10002
r
The error 
ORA-01861: literal does not match format string
 occurs because StarRocks is pushing down your filters directly to Oracle, and Oracle cannot implicitly convert the string 
'08Dec25'
into a 
DATE
type based on its current 
NLS_DATE_FORMAT
settings. In your trace, you can see the generated SQL sent to Oracle: 
WHERE (SYS_RUN_DATE = '2025-12-08 00:00:00') AND (SYS_RUN_DATE = '08Dec25')
Oracle is likely failing on 
'08Dec25'
(or both) because it expects a specific format. Recommended Fix: Standardize Date Literals You should use the standard ISO format (
YYYY-MM-DD
) or the 
DATE
keyword in both parts of your query. This helps StarRocks and the JDBC driver pass a compatible format to Oracle. Rewrite your query like this:
Copy code
sql
UPDATE dmapp.dtm_customer_ld_summary
SET next_payoff_amount = n.next_payoff_amount,
    next_od_po_amt = n.next_od_po_amt,
    day_int_posted = n.day_int_posted,
    day_od_posted = n.day_od_posted,
    paid_tern = n.paid_tern,
    paid_term_user = n.paid_term_user,
    MIN_AMT_MUST_COLLECTED_BOM = n.MIN_AMT_MUST_COLLECTED_BOM,
    OD_TO_EOM_AMT = n.OD_TO_EOM_AMT
FROM (
    SELECT SYS_RUN_DATE, ld_no, next_payoff_amount, next_od_po_amt, day_int_posted,
           day_od_posted, paid_tern, paid_term_user, MIN_AMT_MUST_COLLECTED_BOM, OD_TO_EOM_AMT
    FROM dmapp_link.dtm_customer_ld_summary_posted2_link
    -- Use standard YYYY-MM-DD format here
    WHERE SYS_RUN_DATE = '2025-12-08' 
) n
WHERE dmapp.dtm_customer_ld_summary.sys_run_date = n.sys_run_date
  AND dmapp.dtm_customer_ld_summary.ld_no = n.ld_no
  AND dmapp.dtm_customer_ld_summary.sys_run_date = DATE '2025-12-08';
Advanced Fix: Force Oracle Session Format If the issue persists because Oracle's default environment is very strict, you can modify your JDBC Resource to set the 
NLS_DATE_FORMAT
automatically for every connection StarRocks makes. Run an 
ALTER RESOURCE
(or recreate it) to include a 
session_sql
property:
Copy code
sql
ALTER RESOURCE "DMAPP_JDBC" SET PROPERTIES (
    "session_sql" = "ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS'"
);
Why did the SELECT work but the UPDATE fail? When you ran the simple 
SELECT
, StarRocks might have handled the string conversion locally or the pushdown logic differed slightly. In an 
UPDATE
with a 
JOIN
(
FROM
clause), StarRocks creates a more complex execution plan that combines filters from both tables. It pushed both the standardized StarRocks date and your raw string 
'08Dec25'
to Oracle simultaneously, triggering the format conflict. Summary 1. Replace 
'08Dec25'
with 
'2025-12-08'
. 2. Ensure you use the 
DATE
prefix (e.g., 
DATE '2025-12-08'
) to tell StarRocks to treat it as a date object rather than a raw string.
l
@Rocky ALTER RESOURCE "DMAPP_JDBC" SET PROPERTIES ( "session_sql" = "ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24MISS'" ); SQL Error [1064] [42000]: Alter resource statement only support external hive/hudi/iceberg now Alter resource statement only support external hive/hudi/iceberg now
r
You are correct. The error 
Alter resource statement only support external hive/hudi/iceberg now
occurs because the legacy JDBC Resource (the one used for 
ENGINE=JDBC
external tables) has very limited support for the 
ALTER
command. The method you are using (JDBC External Tables with Resources) is now deprecated. To use advanced features like 
session_sql
(which you need to fix the Oracle date format), you should switch to a JDBC Catalog. Solution 1: Use a JDBC Catalog (Recommended) JDBC Catalogs are the modern way to connect to external databases in StarRocks. They support the 
session_sql
property directly. 1. Create the Catalog:
Copy code
sql
    CREATE EXTERNAL CATALOG oracle_catalog
    PROPERTIES (
        "type" = "jdbc",
        "user" = "your_user",
        "password" = "your_password",
        "jdbc_uri" = "jdbc:oracle:thin:@//your_host:1521/your_service",
        "driver_url" = "file:///path/to/ojdbc8.jar",
        "driver_class" = "oracle.jdbc.driver.OracleDriver",
        -- This property will run automatically for every connection
        "session_sql" = "ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS'"
    );
2. Query directly: You no longer need to create "external tables" manually for every Oracle table. You can just query them:
Copy code
sql
    SELECT * FROM oracle_catalog.DMAPP.dtm_customer_ld_summary
    WHERE sys_run_date = '2025-12-08';
Solution 2: Fix the SQL (Quickest Fix) If you cannot change your architecture right now, you must avoid using non-standard date strings like 
'08Dec25'
. Use the ISO standard format (
YYYY-MM-DD
) and explicitly tell Oracle how to read the string using 
TO_DATE
. Change your query to this:
Copy code
sql
UPDATE dmapp.dtm_customer_ld_summary
SET next_payoff_amount = n.next_payoff_amount,
    -- ... other columns ...
FROM (
    SELECT * 
    FROM dmapp_link.dtm_customer_ld_summary_posted2_link
    -- Use TO_DATE to ensure Oracle understands the format exactly
    WHERE SYS_RUN_DATE = TO_DATE('2025-12-08', 'YYYY-MM-DD')
) n
WHERE dmapp.dtm_customer_ld_summary.sys_run_date = n.sys_run_date
  AND dmapp.dtm_customer_ld_summary.ld_no = n.ld_no
  AND dmapp.dtm_customer_ld_summary.sys_run_date = DATE '2025-12-08';
Summary of why the 
ALTER
failed: * Legacy Resources: The 
CREATE EXTERNAL RESOURCE
system is older and doesn't support the 
session_sql
parameter or the 
ALTER
statement for JDBC types. * JDBC Catalogs: Introduced in version 3.0, these are much more robust and are designed to handle session-level configurations like 
NLS_DATE_FORMAT
settings. References • data_source/catalog/jdbc_catalog.md • sql-reference/sql-statements/Resource/ALTER_RESOURCE.md • data_source/External_table.md _table) • sql-reference/sql-statements/Catalog/CREATE_EXTERNAL_CATALOG.md • faq/Sql_faq.md • data_source/External_table.md • sql-reference/sql-statements/Resource/ALTER_RESOURCE.md • data_source/catalog/jdbc_catalog.md • sql-reference/sql-statements/Catalog/CREATE_EXTERNAL_CATALOG.md • faq/Sql_faq.md _FORMAT`. References • data_source/External_table.md • data_source/catalog/jdbc_catalog.md
l
@Rocky i thinks oracle catalog have issue, as when i created a new oracle catalog, i can show databases, but can not select show databases from DMAPP_ORA_CATALOG; --> OK SELECT * FROM DMAPP_ORA_CATALOG.DMAPP.dtm_customer_ld_summary WHERE sys_run_date = '2025-12-08'; -- > SQL Error [5501] [3F000]: Getting analyzing error. Detail message: Unknown database 'dmapp'. Getting analyzing error. Detail message: Unknown database 'dmapp'.
r
The error 
Unknown database 'dmapp'
 occurs because StarRocks converts unquoted identifiers (like database and table names) to lowercase by default. However, Oracle is case-sensitive, and schema names (which StarRocks treats as "databases") are almost always stored in UPPERCASE in the Oracle system catalog. When you run your query, StarRocks is looking for a schema named 
dmapp
(lowercase), but your Oracle schema is likely 
DMAPP
(uppercase). The Fix: Use Backticks To preserve the uppercase name so it matches Oracle's metadata exactly, wrap the schema name in backticks:
Copy code
sql
SELECT * 
FROM DMAPP_ORA_CATALOG.`DMAPP`.dtm_customer_ld_summary 
WHERE sys_run_date = '2025-12-08';
Verification Steps 1. Check the exact case: Run 
SHOW DATABASES FROM DMAPP_ORA_CATALOG;
. Look closely at the 
Database
column in the results. If it shows 
DMAPP
in all caps, you must use backticks or match that case exactly in a case-sensitive context. 2. Use the catalog context: Sometimes it is easier to switch into the catalog first to avoid long identifiers:
Copy code
sql
    SET CATALOG DMAPP_ORA_CATALOG;
    USE `DMAPP`; -- Use backticks here
    SELECT * FROM dtm_customer_ld_summary LIMIT 10;
Why does this happen? * Oracle Side: Oracle stores object names in uppercase by default. A schema named 
DMAPP
is not the same as 
dmapp
. * StarRocks Side: StarRocks follows the MySQL convention where identifiers are lowercased unless quoted. Even if you type 
DMAPP
in your SQL editor, StarRocks internally converts it to 
dmapp
before sending the metadata request to the Oracle JDBC driver. Using `` 
DMAPP
`` tells StarRocks: "Do not lowercase this; send it exactly as written." If the error persists If backticks do not solve it, check if the Oracle user provided in the Catalog properties has the 
SELECT ANY TABLE
or 
CREATE SESSION
privileges, or specifically has access to the 
DMAPP
schema. If the user can't "see" the schema via JDBC metadata calls, StarRocks will report it as unknown. References • data_source/catalog/jdbc_catalog.md • sql-reference/sql-statements/Catalog/CREATE_EXTERNAL_CATALOG.md • administration/management/resource_management/Resource_group.md • administration/Configuration.md _insensitive` setting. Note that this is generally a cluster-start configuration. References • data_source/catalog/jdbc_catalog.md • sql-reference/sql-statements/Database/SHOW_DATABASES.md • sql-reference/sql-statements/Catalog/SET_CATALOG.md • faq/Sql_faq.md • data_source/catalog/jdbc_catalog.md • sql-reference/sql-statements/Catalog/CREATE_EXTERNAL_CATALOG.md • sql-reference/sql-statements/Database/SHOW_DATABASES.md • faq/Sql_faq.md • sql-reference/sql-statements/Catalog/SET_CATALOG.md • faq/Sql_faq.md References • data_source/catalog/jdbc_catalog.md
l
@Rocky no, my oracle is case-insensitive, but issue is on Starrocks oracle catalog. show i swith to jdbc. USE `DMAPP`; -- Use backticks here --> SQL Error [5501] [3F000]: Unknown database 'dmapp' Unknown database 'dmapp'
r
The error 
Unknown database 'dmapp'
 (in lowercase) even when you use backticks indicates a mismatch between how StarRocks stores the metadata and how your query is being analyzed. In StarRocks, identifiers are often lowercased by the FE analyzer unless specific configurations are used, and Oracle metadata is typically returned in UPPERCASE. Even if you use backticks, certain StarRocks versions or global settings (like 
lower_case_table_names
in 
fe.conf
) may still cause issues when matching against the case-sensitive metadata returned by the Oracle JDBC driver. The Solution: Use 
lower_case_meta_names
 The most robust fix for this "Unknown database" issue in a JDBC Catalog is to tell StarRocks to convert all incoming Oracle metadata (schema names and table names) to lowercase automatically. Recreate your catalog with the following property:
Copy code
sql
CREATE EXTERNAL CATALOG DMAPP_ORA_CATALOG
PROPERTIES (
    "type" = "jdbc",
    "user" = "your_user",
    "password" = "your_password",
    "jdbc_uri" = "jdbc:oracle:thin:@//your_host:1521/your_service",
    "driver_url" = "file:///path/to/ojdbc8.jar",
    "driver_class" = "oracle.jdbc.driver.OracleDriver",
    -- For v4.0+: use "lower_case_meta_names" = "true"
    -- For versions < 4.0: use "lower_case_table_names" = "true"
    "lower_case_meta_names" = "true", 
    -- Fix the date format issue here as well
    "session_sql" = "ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS'"
);
Why this works: 1. Metadata Normalization: By setting 
lower_case_meta_names
(or 
lower_case_table_names
in older versions) to 
true
, StarRocks will see Oracle's 
DMAPP
schema as 
dmapp
in its internal cache. 2. Query Matching: Your query 
SELECT * FROM DMAPP_ORA_CATALOG.DMAPP...
will be converted to lowercase by the StarRocks analyzer and will now successfully match the lowercase metadata in the cache. 3. No more backticks: You can now use 
USE dmapp
or query 
dmapp.table_name
without worrying about case sensitivity or quoting. Alternative (If you cannot recreate the catalog): If you don't want to recreate the catalog, you must match the exact case as it appears in 
SHOW DATABASES
. If 
SHOW DATABASES
shows 
DMAPP
, try running:
Copy code
sql
-- Use uppercase for BOTH the catalog name and the database name inside the string/query
SET CATALOG DMAPP_ORA_CATALOG;
USE `DMAPP`;
_Note: If the error message still shows lowercase 
'dmapp'
, it confirms that your FE is forcing lowercase, and the 
lower_case_meta_names
property mentioned above is the only way to resolve it._ Summary of properties for Oracle JDBC Catalog: * 
lower_case_meta_names
: Set to 
true
to avoid "Unknown database/table" errors due to Oracle's uppercase metadata. * 
session_sql
: Set to 
ALTER SESSION SET NLS_DATE_FORMAT...
to solve your original 
ORA-01861
error. References • data_source/catalog/jdbc_catalog.md • administration/management/FE_configuration.md • sql-reference/sql-statements/Catalog/CREATE_EXTERNAL_CATALOG.md • faq/Sql_faq.md • data_source/catalog/jdbc_catalog.md • sql-reference/sql-statements/Catalog/CREATE_EXTERNAL_CATALOG.md • sql-reference/sql-statements/Database/SHOW_DATABASES.md • faq/Sql_faq.md • administration/Configuration.md • faq/Sql_faq.md
l
@Rocky recreate oracle catalog as you guided, but issue is the same USE `DMAPP`; -- Use backticks here --> SQL Error [5501] [3F000]: Unknown database 'dmapp' Unknown database 'dmapp' SELECT * FROM dtm_customer_ld_summary LIMIT 10;
r
This behavior confirms a case-sensitivity mismatch between StarRocks and Oracle's metadata. When you run 
SHOW DATABASES
, StarRocks shows you the raw metadata from Oracle (likely 
DMAPP
 in uppercase). However, when you query it, StarRocks's SQL analyzer automatically converts the identifier to lowercase (
dmapp
) before looking it up. Since 
dmapp
(lower) $\neq$ 
DMAPP
(upper), it fails. Even with backticks, if your StarRocks cluster is configured with certain global settings (like 
lower_case_table_names = 1
in 
fe.conf
), it may force lowercase. The Guaranteed Fix To resolve this, you must force the JDBC Catalog to store and treat all Oracle metadata as lowercase so it matches your queries. 1. Drop the existing catalog:
Copy code
sql
    DROP CATALOG DMAPP_ORA_CATALOG;
2. Recreate it with the lowercase property: Depending on your StarRocks version, the property name varies. Use both to be safe:
Copy code
sql
    CREATE EXTERNAL CATALOG DMAPP_ORA_CATALOG
    PROPERTIES (
        "type" = "jdbc",
        "user" = "your_user",
        "password" = "your_password",
        "jdbc_uri" = "jdbc:oracle:thin:@//your_host:1521/your_service",
        "driver_url" = "file:///path/to/ojdbc8.jar",
        "driver_class" = "oracle.jdbc.driver.OracleDriver",

        -- Forces StarRocks to store Oracle schemas/tables in lowercase
        "lower_case_meta_names" = "true",
        "lower_case_table_names" = "true",

        -- Include your date format fix
        "session_sql" = "ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS'"
    );
3. Manually Refresh the Catalog: Sometimes the internal metadata cache persists even after recreation. Run this to force a clean pull:
Copy code
sql
    REFRESH CATALOG DMAPP_ORA_CATALOG;
4. Test the Query (Lowercase):
Copy code
sql
    -- Now you can use lowercase without quotes/backticks
    USE DMAPP_ORA_CATALOG.dmapp;
    SELECT * FROM dtm_customer_ld_summary LIMIT 10;
Why "as guided" might have failed: * Cache: If you didn't run 
REFRESH CATALOG
, the FE might have been using a cached version of the metadata from the previous attempt. * Property Name: In versions before 3.3, 
lower_case_meta_names
was not yet introduced, and 
lower_case_table_names
was required. In 3.3+, 
lower_case_meta_names
is the standard. * Global Config: If your 
fe.conf
has 
lower_case_table_names = 1
, StarRocks is extremely aggressive about lowercasing. The catalog property is the only way to make the external metadata "meet" the query halfway in lowercase. If it still fails: Check the output of 
SHOW DATABASES FROM DMAPP_ORA_CATALOG;
again. * If it still shows 
DMAPP
 (Uppercase), then the 
lower_case_meta_names
property did not take effect (check for typos). * If it shows 
dmapp
 (Lowercase) but the query fails, ensure you are in the correct catalog context by running 
SET CATALOG DMAPP_ORA_CATALOG;
first. References • data_source/catalog/jdbc_catalog.md • sql-reference/sql-statements/Catalog/REFRESH_CATALOG.md • administration/management/FE_configuration.md • faq/Sql_faq.md • data_source/catalog/jdbc_catalog.md • sql-reference/sql-statements/Catalog/CREATE_EXTERNAL_CATALOG.md • sql-reference/sql-statements/Catalog/SET_CATALOG.md • faq/Sql_faq.md • administration/management/FE_configuration.md
l
@Rocky REFRESH CATALOG DMAPP_ORA_CATALOG; -- > SQL Error [1064] [42000]: Getting syntax error at line 1, column 89. Detail message: No viable statement for input 'REFRESH CATALOG'. Getting syntax error at line 1, column 89. Detail message: No viable statement for input 'REFRESH CATALOG'. show databases from DMAPP_ORA_CATALOG; -- > OK return: DMAPP SELECT * FROM DMAPP_ORA_CATALOG.DMAPP.dtm_customer_ld_summary WHERE sys_run_date = '2025-12-08'; -- > SQL Error [5501] [3F000]: Getting analyzing error. Detail message: Unknown database 'dmapp'. Getting analyzing error. Detail message: Unknown database 'dmapp'. not using oracle catalog, guide me using jdbc table
r
Since the JDBC Catalog is having issues with Oracle's case-sensitive schema names, you can use a JDBC External Table. This method gives you manual control over the mapping and sidesteps the "Unknown database" error by defining the table explicitly in a StarRocks database of your choice. Step 1: Create a JDBC Resource First, create a resource to manage the connection. This is where you define the driver and credentials.
Copy code
sql
CREATE EXTERNAL RESOURCE "oracle_resource"
PROPERTIES (
    "type" = "jdbc",
    "user" = "your_user",
    "password" = "your_password",
    "jdbc_uri" = "jdbc:oracle:thin:@//your_host:1521/your_service",
    "driver_url" = "file:///path/to/ojdbc8.jar", -- Ensure this path is correct on all BEs/FEs
    "driver_class" = "oracle.jdbc.driver.OracleDriver"
);
Step 2: Create the External Table Now, create the table in your default_catalog. You can name the StarRocks table whatever you like. In the 
table
property, specify the Oracle schema and table name exactly as they appear in Oracle (usually uppercase).
Copy code
sql
-- Switch to a local StarRocks database
CREATE DATABASE IF NOT EXISTS dmapp_local;
USE dmapp_local;

CREATE EXTERNAL TABLE dtm_customer_summary (
    sys_run_date DATE,
    -- Define other columns here to match your Oracle table schema
    customer_id BIGINT, 
    summary_data VARCHAR(65533)
) ENGINE=jdbc 
PROPERTIES (
    "resource" = "oracle_resource",
    "table" = "DMAPP.DTM_CUSTOMER_LD_SUMMARY" -- Map exactly to Oracle schema.table
);
Step 3: Query the Table Now you can query the table directly without worrying about catalog or schema case sensitivity:
Copy code
sql
SELECT * 
FROM dtm_customer_summary 
WHERE sys_run_date = '2025-12-08' 
LIMIT 10;
Key Advantages of this Method: 1. Case Control: You explicitly tell StarRocks that the remote table is 
DMAPP.DTM_CUSTOMER_LD_SUMMARY
. It will not attempt to lowercase this string when talking to Oracle. 2. No "Unknown Database" Errors: Since the table lives in a standard StarRocks database (
dmapp_local
), the FE analyzer won't fail to find the schema. 3. Stability: This bypasses the automatic metadata synchronization of Catalogs which can sometimes be finicky with Oracle's uppercase metadata. Why 
REFRESH CATALOG
failed: The 
REFRESH CATALOG
command was introduced in StarRocks v3.3. If you are on an earlier version, that command will return a syntax error. For JDBC Catalogs in older versions, metadata is typically refreshed by dropping and recreating the catalog. References • data_source/External_table.md • sql-reference/sql-statements/Catalog/CREATE_EXTERNAL_CATALOG.md • data_source/catalog/jdbc_catalog.md • faq/Sql_faq.md • administration/management/FE_configuration.md • sql-reference/sql-statements/Catalog/CREATE_EXTERNAL_CATALOG.md • data_source/External_table.md • data_source/catalog/jdbc_catalog.md • faq/Sql_faq.md • sql-reference/sql-statements/Catalog/CREATE_EXTERNAL_CATALOG.md • administration/management/FE_configuration.md • sql-reference/sql-statements/Catalog/CREATE_EXTERNAL_CATALOG.md References
l
@Rocky
Copy code
APPLICATION app ON f.app_code = app.APP_CODE
        WHERE app.CUSTOMER_CODE IS NOT NULL
    )
    -- BƯỠC CUá» I: Chèn và o staging và  loại bá»  các bản ghi Ä Ã£ tá» n tại
    SELECT 
        src.customer_code, src.app_code, src.status, src.action, src.payload, src.created_at, src.created_by, src.source
    FROM FinalData src
    WHERE NOT EXISTS (
        SELECT 1 
        FROM ofs_stg target
        WHERE target.customer_code = src.customer_code
            AND target.app_code = src.app_code
            AND get_json_string(target.payload, '$.drop_code') = src.drop_code_new
    );
    , err=SemanticException: Getting analyzing error. Detail message: Unknown table 'mobilecus.app_tracking_event'., profile=Planner:
   - -- Parser[1] 1ms
   - -- Total[1] 1ms
   -     -- Analyzer[1] 0
   -         -- Lock[1] 0
   -         -- AnalyzeDatabase[1] 0
   -         -- AnalyzeTemporaryTable[1] 0
   -         -- AnalyzeTable[1] 0
  Reason:

 2026-05-27 09:34:17.201+07:00 ERROR (AutoStatistic|54) [HyperQueryJob.executeStatisticsQuery():156] execute statistics query failed, sql: SELECT cast(9 as INT), cast(1723044 as BIGINT), 'LOG_TIMESTAMP', cast(COUNT(1) as BIGINT), cast(COUNT(`LOG_TIMESTAMP`) * 8 as BIGINT), hex(hll_serialize(IFNULL(hll_raw(`LOG_TIMESTAMP`), hll_empty()))), cast(COUNT(*) - COUNT(`LOG_TIMESTAMP`) as BIGINT), IFNULL(MAX(`LOG_TIMESTAMP`), ''), IFNULL(MIN(`LOG_TIMESTAMP`), ''), cast(-1.0 as BIGINT) FROM `cpm`.`af_etl_data_log` partition `af_etl_data_log`, error: Build Exec OlapScanNode fail, scan info is invalid
 com.starrocks.sql.common.StarRocksPlannerException: Build Exec OlapScanNode fail, scan info is invalid
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visitPhysicalOlapScan(PlanFragmentBuilder.java:1006)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visitPhysicalOlapScan(PlanFragmentBuilder.java:461)
	at com.starrocks.sql.optimizer.operator.physical.PhysicalOlapScanOperator.accept(PhysicalOlapScanOperator.java:249)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visit(PlanFragmentBuilder.java:568)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visitPhysicalHashAggregate(PlanFragmentBuilder.java:2283)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visitPhysicalHashAggregate(PlanFragmentBuilder.java:461)
	at com.starrocks.sql.optimizer.operator.physical.PhysicalHashAggregateOperator.accept(PhysicalHashAggregateOperator.java:303)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visit(PlanFragmentBuilder.java:568)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visitPhysicalDistribution(PlanFragmentBuilder.java:2540)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visitPhysicalDistribution(PlanFragmentBuilder.java:461)
	at com.starrocks.sql.optimizer.operator.physical.PhysicalDistributionOperator.accept(PhysicalDistributionOperator.java:75)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visit(PlanFragmentBuilder.java:568)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visitPhysicalHashAggregate(PlanFragmentBuilder.java:2283)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visitPhysicalHashAggregate(PlanFragmentBuilder.java:461)
	at com.starrocks.sql.optimizer.operator.physical.PhysicalHashAggregateOperator.accept(PhysicalHashAggregateOperator.java:303)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visit(PlanFragmentBuilder.java:568)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.translate(PlanFragmentBuilder.java:474)
	at com.starrocks.sql.plan.PlanFragmentBuilder.createPhysicalPlan(PlanFragmentBuilder.java:271)
	at com.starrocks.sql.StatementPlanner.createQueryPlanWithReTry(StatementPlanner.java:413)
	at com.starrocks.sql.StatementPlanner.plan(StatementPlanner.java:154)
	at com.starrocks.statistic.StatisticExecutor.executeDQL(StatisticExecutor.java:746)
	at com.starrocks.statistic.StatisticExecutor.executeStatisticDQL(StatisticExecutor.java:702)
	at com.starrocks.statistic.hyper.HyperQueryJob.executeStatisticsQuery(HyperQueryJob.java:148)
	at com.starrocks.statistic.hyper.HyperQueryJob.queryStatistics(HyperQueryJob.java:97)
	at com.starrocks.statistic.HyperStatisticsCollectJob.collect(HyperStatisticsCollectJob.java:117)
	at com.starrocks.statistic.StatisticExecutor.collectStatistics(StatisticExecutor.java:573)
	at com.starrocks.statistic.NativeAnalyzeJob.run(NativeAnalyzeJob.java:238)
	at com.starrocks.statistic.StatisticAutoCollector.runJobs(StatisticAutoCollector.java:98)
	at com.starrocks.statistic.StatisticAutoCollector.runAfterCatalogReady(StatisticAutoCollector.java:75)
	at com.starrocks.common.util.FrontendDaemon.runOneCycle(FrontendDaemon.java:78)
	at com.starrocks.common.util.Daemon.run(Daemon.java:98)
Caused by: com.starrocks.common.StarRocksException: 1723050have no alive replicas
	at com.starrocks.planner.OlapScanNode.addScanRangeLocations(OlapScanNode.java:685)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visitPhysicalOlapScan(PlanFragmentBuilder.java:1000)
	... 30 more
2026-05-27 09:34:17.203+07:00 ERROR (AutoStatistic|54) [HyperQueryJob.executeStatisticsQuery():156] execute statistics query failed, sql: SELECT cast(9 as INT), cast(1723044 as BIGINT), 'SYS_RUN_DATE', cast(COUNT(1) as BIGINT), cast(COUNT(`SYS_RUN_DATE`) * 8 as BIGINT), hex(hll_serialize(IFNULL(hll_raw(`SYS_RUN_DATE`), hll_empty()))), cast(COUNT(*) - COUNT(`SYS_RUN_DATE`) as BIGINT), IFNULL(MAX(`SYS_RUN_DATE`), ''), IFNULL(MIN(`SYS_RUN_DATE`), ''), cast(-1.0 as BIGINT) FROM `cpm`.`af_etl_data_log` partition `af_etl_data_log`, error: Build Exec OlapScanNode fail, scan info is invalid
 com.starrocks.sql.common.StarRocksPlannerException: Build Exec OlapScanNode fail, scan info is invalid
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visitPhysicalOlapScan(PlanFragmentBuilder.java:1006)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visitPhysicalOlapScan(PlanFragmentBuilder.java:461)
	at com.starrocks.sql.optimizer.operator.physical.PhysicalOlapScanOperator.accept(PhysicalOlapScanOperator.java:249)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visit(PlanFragmentBuilder.java:568)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visitPhysicalHashAggregate(PlanFragmentBuilder.java:2283)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visitPhysicalHashAggregate(PlanFragmentBuilder.java:461)
	at com.starrocks.sql.optimizer.operator.physical.PhysicalHashAggregateOperator.accept(PhysicalHashAggregateOperator.java:303)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visit(PlanFragmentBuilder.java:568)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visitPhysicalDistribution(PlanFragmentBuilder.java:2540)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visitPhysicalDistribution(PlanFragmentBuilder.java:461)
	at com.starrocks.sql.optimizer.operator.physical.PhysicalDistributionOperator.accept(PhysicalDistributionOperator.java:75)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visit(PlanFragmentBuilder.java:568)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visitPhysicalHashAggregate(PlanFragmentBuilder.java:2283)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visitPhysicalHashAggregate(PlanFragmentBuilder.java:461)
	at com.starrocks.sql.optimizer.operator.physical.PhysicalHashAggregateOperator.accept(PhysicalHashAggregateOperator.java:303)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visit(PlanFragmentBuilder.java:568)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.translate(PlanFragmentBuilder.java:474)
	at com.starrocks.sql.plan.PlanFragmentBuilder.createPhysicalPlan(PlanFragmentBuilder.java:271)
	at com.starrocks.sql.StatementPlanner.createQueryPlanWithReTry(StatementPlanner.java:413)
	at com.starrocks.sql.StatementPlanner.plan(StatementPlanner.java:154)
	at com.starrocks.statistic.StatisticExecutor.executeDQL(StatisticExecutor.java:746)
	at com.starrocks.statistic.StatisticExecutor.executeStatisticDQL(StatisticExecutor.java:702)
	at com.starrocks.statistic.hyper.HyperQueryJob.executeStatisticsQuery(HyperQueryJob.java:148)
	at com.starrocks.statistic.hyper.HyperQueryJob.queryStatistics(HyperQueryJob.java:97)
	at com.starrocks.statistic.HyperStatisticsCollectJob.collect(HyperStatisticsCollectJob.java:117)
	at com.starrocks.statistic.StatisticExecutor.collectStatistics(StatisticExecutor.java:573)
	at com.starrocks.statistic.NativeAnalyzeJob.run(NativeAnalyzeJob.java:238)
	at com.starrocks.statistic.StatisticAutoCollector.runJobs(StatisticAutoCollector.java:98)
	at com.starrocks.statistic.StatisticAutoCollector.runAfterCatalogReady(StatisticAutoCollector.java:75)
	at com.starrocks.common.util.FrontendDaemon.runOneCycle(FrontendDaemon.java:78)
	at com.starrocks.common.util.Daemon.run(Daemon.java:98)
Caused by: com.starrocks.common.StarRocksException: 1723050have no alive replicas
	at com.starrocks.planner.OlapScanNode.addScanRangeLocations(OlapScanNode.java:685)
	at com.starrocks.sql.plan.PlanFragmentBuilder$PhysicalPlanTranslator.visitPhysicalOlapScan(PlanFragmentBuilder.java:1000)
	... 30 more
r
The logs you provided show two distinct and serious issues: one related to your SQL query and another related to the health of your StarRocks cluster. Issue 1: 
Unknown table 'mobilecus.app_tracking_event'
 This is the same case-sensitivity problem we discussed previously. * Cause: StarRocks is searching for a database named 
mobilecus
(lowercase) and a table named 
app_tracking_event
(lowercase). If these are coming from your Oracle Catalog, they likely exist as 
MOBILECUS
and 
APP_TRACKING_EVENT
in Oracle. * The Fix: 1. Ensure you have set the correct catalog context: 
SET CATALOG <your_oracle_catalog_name>;
. 2. Check the actual names with 
SHOW TABLES FROM mobilecus;
. If the names appear in UPPERCASE, you must either: * Use backticks with uppercase: `` 
MOBILECUS
.
APP_TRACKING_EVENT
``. * OR (Recommended): Recreate your Oracle Catalog with 
"lower_case_meta_names" = "true"
as guided in the previous step so that StarRocks can find them using lowercase names. ────────── Issue 2: 
have no alive replicas
(Cluster Health Error) The stack trace showing 
com.starrocks.common.StarRocksException: 1723050 have no alive replicas
is a critical backend error. It means StarRocks cannot find any healthy copies of the data for the tablet 
1723050
in the table 
cpm.af_etl_data_log
. This is why your background statistics and likely your queries are failing. How to troubleshoot this: 1. Check Backend (BE) Status: Run this to see if any of your worker nodes are down:
Copy code
sql
    SHOW BACKENDS;
Look at the 
Alive
column. If any are 
false
, you must restart those BE processes. 2. Check Tablet Health: Check the specific tablet mentioned in the error to see where its replicas are supposed to be:
Copy code
sql
    SHOW TABLET 1723050;
3. Check for Disk Issues: If backends are alive but replicas are missing, check if a disk is full on your BE nodes. StarRocks will mark tablets as unavailable if the disk reaches the high-water mark. 4. Fixing the "No Alive Replicas" error: * If BEs are down: Restart the BE services. Once they reconnect to the FE, the replicas should become "alive" again. * If data is physically lost: You may need to drop the affected partition or table and re-load the data. To see which partition is affected:
Copy code
sql
        SHOW TABLET 1723050; -- The output will show the 'PartitionId'
Summary of Next Steps 1. Fix Cluster Health first: Run 
SHOW BACKENDS;
. If nodes are down, your queries will keep failing regardless of the SQL syntax. 2. Address Case Sensitivity: If you are using the Oracle Catalog, use the 
lower_case_meta_names
property to stop the "Unknown table" errors. If you switched to JDBC External Tables (as guided in the last response), ensure you used the exact Oracle uppercase names in the 
PROPERTIES("table" = "...")
definition. ..)` section)`.
2 Views
Open in Slack
PreviousNext
Powered by