Lý Thành
05/22/2026, 2:48 AMdim_date_link (
SKP_DAY int(11) NULL COMMENT "",
Date datetime NULL COMMENT "",
Month varchar(50) NULL COMMENT "",
Week varchar(50) NULL COMMENT "",
MONTH_AXIS varchar(50) NULL COMMENT "",
WEEK_AXIS varchar(50) NULL COMMENT "",
ORDER_MONTH decimal(20, 8) NULL COMMENT "",
ORDER_WEEK decimal(20, 8) NULL COMMENT "",
FYEAR varchar(50) NULL COMMENT "",
FMONTH varchar(50) NULL COMMENT "",
FWEEK varchar(50) NULL COMMENT "",
FDATE varchar(50) NULL COMMENT "",
CMFLAT varchar(50) NULL COMMENT "",
DATATYPE varchar(50) NULL COMMENT "",
DATA_TYPE_ORDER int(11) NULL COMMENT "",
DATATYPE_FIX varchar(50) NULL COMMENT ""
) ENGINE=JDBC
PROPERTIES (
"resource" = "DM_FIN_JDBC",
"table" = "DM_FIN.dim_date"
);
SQL Error [1064] [42000]: open JDBCScanner failed, error: java.sql.SQLSyntaxErrorException: ORA-00936: missing expression
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 : 936, Position : 31, Sql = SELECT * FROM (SELECT skp_day, date, month, week, month_axis, week_axis, order_month, order_week, fyear, fmonth, fweek, fdate, cmflat, datatype, data_type_order, datatype_fix FROM DM_FIN.dim_date) WHERE ROWNUM <= 200, OriginalSql = SELECT * FROM (SELECT skp_day, date, month, week, month_axis, week_axis, order_month, order_week, fyear, fmonth, fweek, fdate, cmflat, datatype, data_type_order, datatype_fix FROM DM_FIN.dim_date) WHERE ROWNUM <= 200, Error Msg = ORA-00936: missing expression
at oracle.jdbc.driver.T4CTTIoer11.processError(T4CTTIoer11.java:513)
... 17 more
: BE:10002
open JDBCScanner failed, error: java.sql.SQLSyntaxErrorException: ORA-00936: missing expression
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 : 936, Position : 31, Sql = SELECT * FROM (SELECT skp_day, date, month, week, month_axis, week_axis, order_month, order_week, fyear, fmonth, fweek, fdate, cmflat, datatype, data_type_order, datatype_fix FROM DM_FIN.dim_date) WHERE ROWNUM <= 200, OriginalSql = SELECT * FROM (SELECT skp_day, date, month, week, month_axis, week_axis, order_month, order_week, fyear, fmonth, fweek, fdate, cmflat, datatype, data_type_order, datatype_fix FROM DM_FIN.dim_date) WHERE ROWNUM <= 200, Error Msg = ORA-00936: missing expression
at oracle.jdbc.driver.T4CTTIoer11.processError(T4CTTIoer11.java:513)
... 17 more
: BE:10002Rocky
05/22/2026, 2:48 AMORA-00936: missing expression is occurring because one of your column names, Date, is a reserved keyword in Oracle.
In the generated SQL shown in your error log:
SELECT * FROM (SELECT skp_day, date, month, ... FROM DM_FIN.dim_date) ...
The StarRocks JDBC scanner is sending the column name date to Oracle without double quotes. Oracle's parser expects a date literal or expression after the keyword date, and when it finds a comma instead, it throws the "missing expression" error.
Recommended Solutions
1. Use a JDBC Catalog (Best Practice)
The ENGINE=JDBC external table syntax is deprecated. For modern StarRocks versions (v3.0+), you should use a JDBC Catalog. JDBC Catalogs are more robust, support better predicate pushdown, and handle identifier quoting more correctly for specific databases like Oracle.
Oracle support in JDBC Catalogs was significantly improved in v3.2.9 and v3.3.1.
sql
-- 1. Create the Catalog
CREATE EXTERNAL CATALOG oracle_catalog
PROPERTIES (
"type" = "jdbc",
"user" = "your_user",
"password" = "your_password",
"jdbc_uri" = "jdbc:oracle:thin:@//host:port/service",
"driver_url" = "<https://repo1.maven.org/maven2/com/oracle/database/jdbc/ojdbc8/19.3.0.0/ojdbc8-19.3.0.0.jar>",
"driver_class" = "oracle.jdbc.driver.OracleDriver"
);
-- 2. Query directly
SELECT * FROM oracle_catalog.DM_FIN.dim_date;
2. Create an Oracle View (Workaround)
If you must use the ENGINE=JDBC external table, you can avoid the keyword conflict by creating a view in your Oracle database that renames the problematic column.
* In Oracle:
sql
CREATE VIEW DM_FIN.v_dim_date AS
SELECT SKP_DAY, "Date" AS CALENDAR_DATE, Month, ...
FROM DM_FIN.dim_date;
* In StarRocks:
Update your table definition to point to v_dim_date and change the column name to CALENDAR_DATE.
3. Upgrade StarRocks
This was a known issue where the JDBC scanner did not consistently quote identifiers for non-MySQL databases. A fix (#67690) was implemented recently to ensure reserved keywords are properly quoted (e.g., as "date") when sent to Oracle. If you are on an older version of StarRocks, upgrading to the latest maintenance release of v3.2 or v3.3 should resolve this.
Why this happens with ENGINE=JDBC
The deprecated JDBC external table requires StarRocks column names to match the remote table names exactly. Because StarRocks (and the older JDBC bridge) does not automatically wrap these names in double quotes for the Oracle-side query, any column named DATE, ORDER, or CHECK will trigger syntax errors in Oracle.
References
• sql-reference/sql-statements/keywords.md
• data_source/External_table.mdLý Thành
05/22/2026, 2:52 AMENGINE=JDBC external table syntax is deprecated. For modern StarRocks versions (v3.0+), you should use a JDBC Catalog. JDBC Catalogs are more robust, support better predicate pushdown, and handle identifier quoting more correctly for specific databases like Oracle.
Oracle support in JDBC Catalogs was significantly improved in v3.2.9 and v3.3.1.
sql
-- 1. Create the Catalog
CREATE EXTERNAL CATALOG oracle_catalog
PROPERTIES (
"type" = "jdbc",
"user" = "your_user",
"password" = "your_password",
"jdbc_uri" = "jdbc:oracle:thin:@//host:port/service",
"driver_url" = "<https://repo1.maven.org/maven2/com/oracle/database/jdbc/ojdbc8/19.3.0.0/ojdbc8-19.3.0.0.jar>",
"driver_class" = "oracle.jdbc.driver.OracleDriver"
);
-- 2. Query directly
SELECT * FROM oracle_catalog.DM_FIN.dim_date;
SQL Error [5501] [3F000]: Getting analyzing error. Detail message: Unknown database 'dm_fin'.
Getting analyzing error. Detail message: Unknown database 'dm_fin'.Rocky
05/22/2026, 2:53 AMUnknown database 'dm_fin' usually occurs because StarRocks converts unquoted identifiers to lowercase by default, but Oracle stores schema and table names in UPPERCASE.
When you run SELECT * FROM oracle_catalog.DM_FIN.dim_date, StarRocks's analyzer looks for a database (schema) named dm_fin. Since Oracle likely has it stored as DM_FIN, the lookup fails.
How to Fix
1. Use Double Quotes for Casing
Wrap the schema and table names in double quotes to preserve the uppercase letters:
sql
SELECT * FROM oracle_catalog."DM_FIN"."DIM_DATE";
(Note: Use the exact casing that exists in Oracle for both the schema and the table name.)
2. Verify the Names
Run the following commands to see exactly how StarRocks perceives the Oracle metadata:
sql
-- See the list of schemas (databases)
SHOW DATABASES FROM oracle_catalog;
-- See the list of tables in that schema
SHOW TABLES FROM oracle_catalog."DM_FIN";
3. (Optional) Set Default Catalog/Database
To simplify your queries and avoid long paths, you can switch your session context:
sql
SET CATALOG oracle_catalog;
USE "DM_FIN";
SELECT * FROM "DIM_DATE" LIMIT 10;
Important Version Note
Oracle support in JDBC catalogs was officially added/stabilized in:
* v3.2.9+
* v3.3.1+
If you are on an earlier version, you may encounter issues with metadata discovery or data type mapping. If SHOW DATABASES returns an empty list, verify that your StarRocks cluster version meets these requirements and that the JDBC user has permissions to view the DM_FIN schema.
References
• data_source/catalog/jdbc_catalog.md
• data_source/feature-support-data-lake-analytics.md
• sql-reference/System_limit.md
• administration/management/FE_configuration.md
• release_notes/release-3.2.mdLý Thành
05/22/2026, 3:01 AMRocky
05/22/2026, 3:01 AMUSE command does not support the catalog.database format. Since you already successfully ran SET CATALOG DM_FIN_DTM;, you only need to specify the database (schema) name.
Correct Syntax
sql
SET CATALOG DM_FIN_DTM;
USE "DM_FIN";
Explanation
1. SET CATALOG: Switches your session context to the specific catalog.
2. USE: Switches the context to a database inside the current catalog. It expects a single identifier, not a dot-separated path.
3. Quotes: Since Oracle schemas are typically stored in uppercase, keep using the double quotes "DM_FIN" to ensure StarRocks sends the exact casing to Oracle.
After running these two commands, you can query your table directly:
sql
SELECT * FROM "dim_date" LIMIT 10;
_(If dim_date is also uppercase in Oracle, use "DIM_DATE" in the SELECT as well.)_
References
• sql-reference/sql-statements/data-definition/USE.md
• sql-reference/sql-statements/data-definition/SET_CATALOG.mdLý Thành
05/22/2026, 3:02 AMRocky
05/22/2026, 3:02 AMThe correct syntax is: USE 'CATALOG catalog_name' is a hint StarRocks provides when it suspects you are trying to switch catalogs using the USE command (which is reserved for switching databases/schemas within a catalog).
This typically happens if the schema name you provided ("DM_FIN") is not found in the current catalog, and StarRocks is guessing you might have meant to switch to a catalog with that name.
To resolve the context issues, use the fully qualified name (three-part name) in your query. This is the most reliable method as it bypasses the need for SET CATALOG or USE commands entirely.
1. The Reliable Way (Fully Qualified Name)
Instead of switching context, query the table directly using `catalog.schema.table`:
sql
SELECT * FROM DM_FIN_DTM."DM_FIN"."DIM_DATE" LIMIT 10;
_(Ensure the catalog name DM_FIN_DTM matches exactly what you used in CREATE EXTERNAL CATALOG.)_
2. If you prefer USE, check your Schema name
If you want to use USE, you must ensure you are first in the correct catalog and then use the exact casing of the Oracle schema. In Oracle, schemas are almost always UPPERCASE.
sql
-- Step 1: Switch to the catalog
SET CATALOG DM_FIN_DTM;
-- Step 2: Verify the exact name of the schema as seen by StarRocks
SHOW DATABASES;
-- Step 3: Use the exact name from the list above (wrapped in quotes)
USE "DM_FIN";
-- Step 4: Query the table (usually uppercase in Oracle)
SELECT * FROM "DIM_DATE" LIMIT 10;
Why your previous attempts failed:
* USE DM_FIN_DTM."DM_FIN";: Failed because USE in some StarRocks versions prefers the catalog and database to be unquoted or specifically formatted.
* USE "DM_FIN";: Failed with the "USE CATALOG" hint because StarRocks couldn't find a database named DM_FIN in your current catalog context. This usually means either:
1. The SET CATALOG command didn't persist or failed.
2. The Oracle user doesn't have permissions to see the DM_FIN schema.
3. The schema name in Oracle is slightly different (e.g., lowercase or has trailing spaces, though rare).
Summary Checklist
1. Run SHOW CATALOGS; to confirm DM_FIN_DTM exists.
2. Run SHOW DATABASES FROM DM_FIN_DTM; to confirm "DM_FIN" is visible.
3. If visible, use the three-part name DM_FIN_DTM."DM_FIN"."DIM_DATE" to avoid all syntax ambiguity.
References
• data_source/catalog/jdbc_catalog.md
• sql-reference/sql-statements/Database/USE.md
• sql-reference/sql-statements/Catalog/SET_CATALOG.md
• data_source/catalog/catalog_overview.md
References
• sql-reference/sql-statements/Database/USE.md
• data_source/catalog/unified_catalog.md
• sql-reference/sql-statements/Catalog/SET_CATALOG.md
• data_source/catalog/iceberg/iceberg_catalog.md
• data_source/catalog/hive_catalog.md
• data_source/catalog/deltalake_catalog.md
• data_source/catalog/hudi_catalog.md
• data_source/catalog/catalog_overview.mdLý Thành
05/22/2026, 3:05 AMRocky
05/22/2026, 3:05 AMSHOW and USE commands differently than the standard SELECT statements.
The error Unexpected input '.' in your SHOW TABLES command indicates that your parser expects only a database name after FROM, and does not yet support the catalog.database shorthand for that specific command.
To resolve this and successfully query your Oracle tables, follow these steps:
1. The Most Reliable Query Method (Direct Path)
Instead of switching context, use the fully qualified three-part name in your SELECT. This bypasses the need for USE or SHOW commands:
sql
-- Pattern: catalog_name."SCHEMA_NAME"."TABLE_NAME"
SELECT * FROM DM_FIN_DTM."DM_FIN"."DIM_DATE" LIMIT 10;
*Note: Oracle schemas and tables are almost always UPPERCASE. Ensure you use double quotes to preserve that casing.*
2. Correct way to use SHOW TABLES
If you want to see the tables in that specific schema, you must first switch the catalog context and then run the command on the database name alone:
sql
SET CATALOG DM_FIN_DTM; -- OK
-- Verify you are in the correct catalog
SELECT current_catalog();
-- Check the exact casing of the schema name
SHOW DATABASES;
-- Use the schema name exactly as it appears in the list above
SHOW TABLES FROM "DM_FIN";
3. Fixing the USE Command
If USE "DM_FIN" failed with a syntax error or a "USE CATALOG" hint, it typically means the database name wasn't recognized in the current catalog.
* Check for quotes: If the schema name is uppercase in Oracle, you must use double quotes: USE "DM_FIN";.
* Verify Catalog Context: Ensure you haven't lost your session context. If you are using a GUI like DBeaver or Navicat, they sometimes open new sessions for each tab, losing the SET CATALOG setting.
* Try the dot-syntax for USE: Some versions support USE catalog.database but without quotes on the catalog:
sql
USE DM_FIN_DTM."DM_FIN";
4. Querying Metadata via information_schema
If SHOW commands continue to fail, you can query the StarRocks metadata directly:
sql
SELECT TABLE_NAME
FROM information_schema.tables
WHERE TABLE_CATALOG = 'DM_FIN_DTM'
AND TABLE_SCHEMA = 'DM_FIN';
Summary of common causes:
* Case Sensitivity: Oracle stores names in UPPERCASE. StarRocks defaults to lowercase. Always use double quotes for Oracle schema/table names (e.g., "DM_FIN").
* Session State: Tools like DBeaver can sometimes drop the SET CATALOG context. Using the three-part name DM_FIN_DTM."DM_FIN"."DIM_DATE" in every query is the safest practice.
* Version Limitation: If SHOW TABLES FROM catalog.db fails with a dot error, your FE version requires you to SET CATALOG first.
References
• sql-reference/sql-statements/table_bucket_part_index/SHOW_TABLES.md
• sql-reference/sql-statements/Database/USE.md
• data_source/catalog/jdbc_catalog.md
• sql-reference/sql-statements/Catalog/SET_CATALOG.md
References
• sql-reference/sql-statements/Database/USE.md
• data_source/catalog/unified_catalog.md
• sql-reference/sql-statements/Catalog/SET_CATALOG.md
• data_source/catalog/iceberg/iceberg_catalog.mdLý Thành
05/22/2026, 3:17 AMENGINE=JDBC external table, you can avoid the keyword conflict by creating a view in your Oracle database that renames the problematic column.
* In Oracle:
sql
CREATE VIEW DM_FIN.v_dim_date AS
SELECT SKP_DAY, "Date" AS CALENDAR_DATE, Month, ...
FROM DM_FIN.dim_date;Rocky
05/22/2026, 3:18 AMENGINE=JDBC approach (the older external table method), you will need to follow three steps: creating the Oracle view, setting up a StarRocks Resource, and finally creating the StarRocks External Table.
1. Oracle View (As you started)
This is a good workaround for problematic column names or casing in Oracle.
sql
-- In Oracle
CREATE OR REPLACE VIEW DM_FIN.V_DIM_DATE AS
SELECT
SKP_DAY,
"Date" AS CALENDAR_DATE, -- Renaming the reserved word "Date"
"Month" AS CALENDAR_MONTH
FROM DM_FIN.dim_date;
2. Create the JDBC Resource in StarRocks
Before creating the table, StarRocks needs a "Resource" to store the connection details.
sql
CREATE EXTERNAL RESOURCE "oracle_resource"
PROPERTIES (
"type" = "jdbc",
"user" = "your_username",
"password" = "your_password",
"jdbc_uri" = "jdbc:oracle:thin:@//your_host:1521/your_service_name",
"driver_url" = "<https://repo1.maven.org/maven2/com/oracle/database/jdbc/ojdbc8/19.3.0.0/ojdbc8-19.3.0.0.jar>",
"driver_class" = "oracle.jdbc.driver.OracleDriver"
);
_Note: Ensure your BE nodes can reach the driver_url or place the JAR manually in lib/jdbc_drivers on all BEs._
3. Create the External Table in StarRocks
Now, create the table that points to your Oracle view. Note that the column names in StarRocks should match the aliases you created in the Oracle view.
sql
CREATE EXTERNAL TABLE dim_date_jdbc (
skp_day BIGINT,
calendar_date DATE, -- Maps to "Date" alias from view
calendar_month INT -- Maps to Month
) ENGINE=jdbc
PROPERTIES (
"resource" = "oracle_resource",
"table" = "DM_FIN.V_DIM_DATE" -- Use the Oracle View name (usually UPPERCASE)
);
Why your Catalog SHOW commands failed earlier
The error Unexpected input '.' occurred because metadata commands like SHOW TABLES and USE in your StarRocks version do not support the dot-notation (catalog.database).
To use the JDBC Catalog successfully without the View workaround, you would have to avoid the dot in those specific commands:
1. SET CATALOG DM_FIN_DTM;
2. USE "DM_FIN"; (Only the database name, quoted for case sensitivity)
3. `SELECT skp_day, date FROM dim_date;` (In the Catalog, you can often escape the keyword using backticks `` ` ``).
However, the JDBC External Table method you chose is a solid way to have a "fixed" schema that hides Oracle's complexity.
References
• data_source/External_table.md
• sql-reference/sql-statements/data-definition/CREATE_RESOURCE.md
• sql-reference/sql-statements/keywords.md
References
• data_source/catalog/jdbc_catalog.md
• data_source/catalog/catalog_overview.md
• table_design/table_design.mdLý Thành
05/22/2026, 3:44 AMdbt run failed at 011247.151792 after 13.72 seconds
011247 Sending event: {'category': 'dbt', 'action': 'invocation', 'label': 'end', 'context': [<snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x7f93ec923980>, <snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x7f93eade8ef0>, <snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x7f93ece3cbf0>]}
011247 Flushing usage events
011257 An error was encountered while trying to flush usage events
[2026-05-22, 011257 UTC] {taskinstance.py:3313} ERROR - Task failed with exception
Traceback (most recent call last):
File "/home/airflow/.local/lib/python3.12/site-packages/airflow/models/taskinstance.py", line 768, in _execute_task
*result = _execute_callable(context=context, *execute_callable_kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/airflow/.local/lib/python3.12/site-packages/airflow/models/taskinstance.py", line 734, in _execute_callable
return ExecutionCallableRunner(
^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/airflow/.local/lib/python3.12/site-packages/airflow/utils/operator_helpers.py", line 252, in run
*return self.func(*args, *kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/airflow/.local/lib/python3.12/site-packages/airflow/models/baseoperator.py", line 424, in wrapper
*return func(self, *args, *kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/airflow/.local/lib/python3.12/site-packages/airflow/operators/python.py", line 238, in execute
return_value = self.execute_callable()
^^^^^^^^^^^^^^^^^^^^^^^
File "/home/airflow/.local/lib/python3.12/site-packages/airflow/operators/python.py", line 256, in execute_callable
*return runner.run(*self.op_args, *self.op_kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/airflow/.local/lib/python3.12/site-packages/airflow/utils/operator_helpers.py", line 252, in run
*return self.func(*args, *kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/airflow/dags/bags/finance-etl-data/airflow_dags/transform_framework/dbt_transform_dag_creator.py", line 148, in _run_dbt_task
dh.run_command(dbt_cmd, tmp_dir=temp_project_path, env_vars=os.environ.copy())
File "/opt/airflow/dags/bags/finance-etl-data/airflow_dags/transform_framework/dbt_helper.py", line 62, in run_command
raise subprocess.CalledProcessError(return_code, command)
subprocess.CalledProcessError: Command '['/home/airflow/.local/bin/dbt', 'run', '--debug', '--vars', '{"run_date": "2026-05-21"}', '--select', 'dpd_endmonth_card_hist', '--project-dir', '/tmp/dbt_run_bfco2744/transform_framework/dbt_projects/dm_fin_dbt', '--profiles-dir', '/tmp/dbt_run_bfco2744/transform_framework/dbt_projects/dm_fin_dbt']' returned non-zero exit status 1.
[2026-05-22, 011257 UTC] {taskinstance.py:907} DEBUG - Task Duration set to 66.771141Rocky
05/22/2026, 3:44 AM1064 (HY000): Tablet lost replicas, indicates that StarRocks cannot find a healthy copy (replica) of the data needed to perform your DELETE operation.
Specifically, your log shows BeReplicaSize:0, quorum:1, which means StarRocks requires at least 1 healthy replica to proceed, but currently sees zero available. This usually happens because the Backend (BE) node hosting that specific piece of data is down, disconnected, or the data on it is corrupted.
Immediate Troubleshooting Steps
1. Check Backend Status
The most common cause is a crashed BE node (often due to OOM or disk issues). Run this in your StarRocks console:
sql
SHOW BACKENDS;
* Look at the Alive column. If any are false, you need to restart those BE processes.
* Check the DiskUsed column to ensure no disks are 100% full.
2. Inspect the Broken Tablet
You can see exactly where the problem lies for the tablet mentioned in your log (1719093):
sql
SHOW TABLET 1719093;
* Copy the SQL command found in the DetailCmd column of the result and run it.
* In the output of that detailed command, look for the State and IsBad columns. If IsBad is true, that replica is corrupted.
3. Check Overall Cluster Health
See if other tables are affected:
sql
SHOW PROC '/statistic';
* Look for UnhealthyTabletNum. If this is greater than 0, the cluster is currently struggling to maintain data redundancy.
How to Fix
1. Restart Backends: If any BE is down, restart it. StarRocks will automatically try to recover and synchronize the "lost" replicas once the node is back online.
2. Trigger a Manual Repair: If the nodes are all alive but the tablet is still "lost," you can tell the Frontend to prioritize repairing this table:
sql
ADMIN REPAIR TABLE dm_fin.dpd_endmonth_card_hist;
3. Check Replication Property: If this table was created with "replication_num" = "1", you have no redundancy. Any single BE failure will cause this error. For production, it is highly recommended to use a replication number of 3.
* To check: SHOW CREATE TABLE dm_fin.dpd_endmonth_card_hist;
* To increase (if you have enough BE nodes):
sql
ALTER TABLE dm_fin.dpd_endmonth_card_hist SET ("replication_num" = "3");
Summary of the dbt failure
The dbt run failed because it attempted an incremental update (which involves a DELETE + INSERT pattern), but the DELETE failed immediately because it couldn't reach the data shard (tablet) on the storage layer. Once you resolve the BE/Tablet health issue, the dbt job should succeed without any changes to the code.
References
• administration/management/resource_management/Replica.mdLý Thành
05/22/2026, 6:58 AMsales_code_hist (
MONTH varchar(100) NOT NULL COMMENT "",
SALES_CODE varchar(100) NULL COMMENT "",
CLASS varchar(100) NULL COMMENT "",
NO varchar(100) NULL COMMENT "",
HR_CODE varchar(100) NULL COMMENT "",
CHANNEL varchar(100) NULL COMMENT "",
SALES_NAME varchar(100) NULL COMMENT "",
CONTRACT_TYPE varchar(100) NULL COMMENT "",
CONTRACT_DATE date NULL COMMENT "",
SALES_STATUS varchar(100) NULL COMMENT "",
TEAM_NAME varchar(100) NULL COMMENT "",
TEAM_LEADER_NAME varchar(100) NULL COMMENT "",
TEAM_LEADER_CODE varchar(100) NULL COMMENT "",
SUPERVISOR_NAME varchar(100) NULL COMMENT "",
SUPERVISOR_CODE varchar(100) NULL COMMENT "",
UH_NAME varchar(100) NULL COMMENT "",
UH_CODE varchar(100) NULL COMMENT "",
RSM_NAME varchar(100) NULL COMMENT "",
RSM_CODE varchar(100) NULL COMMENT "",
HEAD_NAME varchar(100) NULL COMMENT "",
HEAD_CODE varchar(50) NULL COMMENT "",
REGION varchar(100) NULL COMMENT "",
SUB_REGION varchar(100) NULL COMMENT "",
PROVINCE varchar(100) NULL COMMENT "",
SUB_PROVINCE varchar(100) NULL COMMENT "",
RESIGNATION_DATE date NULL COMMENT "",
MODIFY_DATE date NULL COMMENT ""
) ENGINE=OLAP
DUPLICATE KEY(MONTH)
order by (MONTH, SALES_CODE)
DISTRIBUTED BY HASH(MONTH) BUCKETS 4
PROPERTIES (
"compression" = "LZ4",
"fast_schema_evolution" = "true",
"replicated_storage" = "true",
"replication_num" = "1"
);
what wrongRocky
05/22/2026, 6:59 AMCREATE TABLE statement: a syntax error regarding the ORDER BY clause and a data distribution risk.
1. Syntax Error: DUPLICATE KEY vs ORDER BY
In StarRocks, the sort order of a table is defined by its keys. You are trying to use both DUPLICATE KEY and ORDER BY, which causes a conflict or a syntax error depending on your version:
* Before StarRocks v3.3: The ORDER BY clause is not supported inside the CREATE TABLE statement. You must define your sorting columns using DUPLICATE KEY(...) only.
* StarRocks v3.3 and later: While ORDER BY was introduced to simplify syntax, you should not use both. If both are present, DUPLICATE KEY is ignored.
The Fix: Remove the ORDER BY line and put all sorting columns inside DUPLICATE KEY.
2. Data Skew Risk: DISTRIBUTED BY HASH
You are distributing data by MONTH. Since your table seems to be a history table (sales_code_hist), you likely have many rows for the same month.
* Problem: All data for a single month will be sent to the same bucket (and same BE node). This creates a "hotspot" (data skew), where one node works hard while others stay idle.
* The Fix: Add a high-cardinality column (like SALES_CODE) to the distribution hash to spread data evenly across the cluster.
──────────
Corrected SQL
sql
CREATE TABLE `sales_code_hist` (
`MONTH` varchar(100) NOT NULL COMMENT "",
`SALES_CODE` varchar(100) NULL COMMENT "",
`CLASS` varchar(100) NULL COMMENT "",
-- ... other columns ...
`MODIFY_DATE` date NULL COMMENT ""
) ENGINE=OLAP
-- Combined the order into the Duplicate Key definition
DUPLICATE KEY(`MONTH`, `SALES_CODE`)
-- Added SALES_CODE to distribution to prevent data skew
DISTRIBUTED BY HASH(`MONTH`, `SALES_CODE`) BUCKETS 4
PROPERTIES (
"compression" = "LZ4",
"fast_schema_evolution" = "true",
"replicated_storage" = "true",
-- WARNING: replication_num=1 means no high availability.
-- If one node fails, you will get the "Tablet lost replicas" error again.
"replication_num" = "1"
);
Key Recommendations:
1. Replication: Since you just experienced a Tablet lost replicas error in your previous dbt run, do not use "replication_num" = "1" in production. Use 3 to ensure the table remains available even if a node goes down.
2. Sort Order: Always put the columns used in your WHERE clauses (like MONTH) first in the DUPLICATE KEY list for the best performance.
3. Buckets: 4 buckets is very small. If this table grows over 10GB, consider increasing the bucket count or using DISTRIBUTED BY HASH(...) BUCKETS AUTO.
References
• sql-reference/sql-statements/table_bucket_part_index/CREATE_TABLE.md
• table_design/StarRocks_table_design.md
• table_design/data_distribution/Data_distribution.md
References
• sql-reference/sql-statements/table_bucket_part_index/CREATE_TABLE.md
• table_design/StarRocks_table_design.mdLý Thành
05/22/2026, 7:00 AMSALES_CODE have null data