http://starrocks.io logo
Join Slack
Powered by
<@U0A71G31CDV> got this error
# questions-and-troubleshooting
l
@Rocky got this error
r
I'm ready to help! Please paste the error message you're seeing, and let me know what you were trying to do (e.g., running a query, loading data, or configuring a setting) when it occurred.
l
@Rocky does BE crash when query run full memory?
r
In most cases, the BE process does not crash when a query runs out of memory. Instead, StarRocks is designed to cancel the problematic query to protect the stability of the node. 1. Standard Behavior: Query Cancellation StarRocks uses a multi-level memory tracking system to prevent crashes: * Per-Query Limit: Controlled by the session variable 
query_mem_limit
(or 
exec_mem_limit
). If a single query exceeds this limit on a BE, it is terminated with an error: 
Mem usage has exceed the limit of single query
. * Query Pool Limit: Controlled by 
query_max_memory_limit_percent
. If the total memory used by all queries on a BE exceeds this, StarRocks will cancel one or more queries to free up memory. * BE Process Limit (
mem_limit
): By default, this is 90% of the server's RAM. * Soft Limit (80%): The BE starts aggressively reclaiming memory (e.g., clearing PageCache). * Hard Limit (90%): The BE starts cancelling queries to prevent the process from exceeding physical RAM. 2. When a BE Might Crash While StarRocks tries to prevent it, a BE can still crash in specific scenarios: * OS OOM Killer: If the BE process (or other processes on the same machine) consumes all available physical RAM and Swap, the Linux kernel's OOM Killer may kill the 
starrocks_be
process. This is the most common cause of "crashes" due to memory. * Metadata or System Memory: If memory is consumed by things not tracked in the query pool (like massive metadata or memory leaks), the BE might hit the system limit before it can cancel queries. * Large Allocations: Starting in v3.4.3, if the parameter 
abort_on_large_memory_allocation
is set to 
true
, the BE will explicitly call 
abort()
(hard crash) if a single allocation request is suspiciously huge. * Bugs: Extreme memory pressure can sometimes trigger edge-case bugs (like null pointer dereferences or failed allocations in critical code paths) that cause a crash. Troubleshooting If your BE is crashing: 1. Check `be.out`: Look for "Out of memory" or "Killed" messages. 2. Check System Logs: Run 
dmesg -T | grep -i oom
to see if the Linux OOM Killer terminated the process. 3. Monitor Memory: Use 
curl http://<BE_IP>:<BE_HTTP_PORT>/mem_tracker
to see exactly which component is using the most memory. 4. Adjust Limits: If queries are failing frequently, consider increasing 
query_mem_limit
or enabling Intermediate Result Spilling (available in v3.0+) to write data to disk instead of failing. failing queries to disk instead of keeping it in RAM. References • faq/resource_isolation_faq.md • administration/management/BE_configuration.md • administration/management/resource_management/Memory_management.md • faq/Sql_faq.md
l
@Rocky tart time: Tue Dec 16 025201 PM +07 2025, server uptime: 145201 up 4 days, 3:07, 4 users, load average: 0.22, 0.05, 0.02 Run with JEMALLOC_CONF: 'percpu_arenapercpu,oversize threshold0,muzzy_decay_ms5000,dirty decay ms5000,metadata_thpauto,background threadtrue,proftrue,prof activefalse' [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument [warn] Error from accept() call: Invalid argument start time: Tue Dec 16 025225 PM +07 2025, server uptime: 145225 up 4 days, 3:07, 4 users, load average: 0.15, 0.04, 0.01 Run with JEMALLOC_CONF: 'percpu_arenapercpu,oversize threshold0,muzzy_decay_ms5000,dirty decay ms5000,metadata_thpauto,background threadtrue,proftrue,prof activefalse' start time: Tue Mar 10 044609 PM +07 2026, server uptime: 164609 up 88 days, 5:00, 3 users, load average: 0.06, 0.59, 0.68 Run with JEMALLOC_CONF: 'percpu_arenapercpu,oversize threshold0,muzzy_decay_ms5000,dirty decay ms5000,metadata_thpauto,background threadtrue,proftrue,prof activefalse' start time: Mon Mar 16 095533 AM +07 2026, server uptime: 095533 up 93 days, 22:09, 4 users, load average: 0.48, 0.14, 0.04 Run with JEMALLOC_CONF: 'percpu_arenapercpu,oversize threshold0,muzzy_decay_ms5000,dirty decay ms5000,metadata_thpauto,background threadtrue,proftrue,prof activefalse' start time: Wed May 20 053612 PM +07 2026, server uptime: 173612 up 159 days, 5:50, 6 users, load average: 0.47, 2.26, 3.81 Run with JEMALLOC_CONF: 'percpu_arenapercpu,oversize threshold0,muzzy_decay_ms5000,dirty decay ms5000,metadata_thpauto,background threadtrue,proftrue,prof activefalse' start time: Mon Jun 8 024544 PM +07 2026, server uptime: 144544 up 178 days, 2:59, 5 users, load average: 0.04, 1.91, 6.38 Run with JEMALLOC_CONF: 'percpu_arenapercpu,oversize threshold0,muzzy_decay_ms5000,dirty decay ms5000,metadata_thpauto,background threadtrue,proftrue,prof activefalse' start time: Tue Jun 9 031124 PM +07 2026, server uptime: 151124 up 179 days, 3:25, 5 users, load average: 0.16, 4.01, 6.55 Run with JEMALLOC_CONF: 'percpu_arenapercpu,oversize threshold0,muzzy_decay_ms5000,dirty decay ms5000,metadata_thpauto,background threadtrue,proftrue,prof activefalse' start time: Wed Jun 10 020027 PM +07 2026, server uptime: 140027 up 180 days, 2:14, 5 users, load average: 0.38, 5.75, 7.49 Run with JEMALLOC_CONF: 'percpu_arenapercpu,oversize threshold0,muzzy_decay_ms5000,dirty decay ms5000,metadata_thpauto,background threadtrue,proftrue,prof activefalse'
r
Based on the logs you provided from 
be.out
, your StarRocks Backend (BE) process is indeed restarting frequently (on June 8, 9, and 10). The message 
[warn] Error from accept() call: Invalid argument
is a warning from the network library (libevent) used by the BE's HTTP service. This usually occurs when the service is trying to accept a connection while the process is already in the middle of shutting down or crashing. To determine if these restarts are caused by "full memory" (OOM), please check the following: 1. Check for Kernel OOM Killer If the BE process is using too much memory, the Linux kernel might kill it. Run this command on the BE machine:
Copy code
bash
dmesg -T | grep -i "out of memory"
# OR
journalctl -xe | grep -i "oom-killer"
If you see 
Killed process <pid> (starrocks_be)
, then the BE crashed because it exceeded the physical RAM of the server. 2. Check the 
<http://be.INFO|be.INFO>
Log The 
be.out
file only shows startup and crash-loop wrappers. The detailed reason for a failure is usually in the 
<http://be.INFO|be.INFO>
log (located in your BE 
log/
directory). Search for these keywords around the time of the restart: * 
Memory limit exceeded
* 
reached system memory limit
* 
F0
(Fatal log entries) * 
Segmentation fault
3. Analyze the Load and Timing Your logs show the BE restarts almost every 24 hours (around 2:00 PM – 3:00 PM). This pattern suggests: * Daily Peak: A heavy daily report or ETL job might be running at that time, pushing memory over the limit. * Memory Leak: A slow memory leak might be taking ~24 hours to reach the process limit (
mem_limit
). Recommendations 1. Check `be.conf`: Verify the 
mem_limit
setting. By default, it's 90%. If your server has 64GB RAM, the BE will try to use up to ~57GB. If other processes are running on the same machine, this might be too high. 2. Enable Spilling: If queries are consistently hitting memory limits, enable intermediate result spilling to disk (available in v3.0+):
Copy code
sql
    SET GLOBAL enable_spill = true;
3. Check File Descriptors: The 
accept()
error can sometimes relate to reaching the open file limit. Ensure 
ulimit -n
is set to 
65535
or higher. Does it crash when memory is full? As mentioned before, StarRocks usually cancels the query first. If you see a restart without a "Memory limit exceeded" error in the SQL client, it's almost always the OS OOM Killer or a process crash (Segmentation Fault). References • deployment/environment_configurations.md • administration/Meta_recovery.md • faq/Deploy_faq.md • administration/management/BE_configuration.md • sql-reference/sql-functions/string-functions/inet_aton.md
l
@Rocky this server run both FE and BE, so how to set BE memory to lower.
r
To lower the BE memory usage on a server that runs both the FE and BE, you need to modify the 
mem_limit
parameter in the BE configuration file. 1. Modify 
be.conf
 1. Open the BE configuration file: 
conf/be.conf
. 2. Find (or add) the 
mem_limit
parameter. 3. Set it to an absolute value (e.g., 
32G
) or a specific percentage (e.g., 
60%
). Example: If your server has 64GB of RAM and you want to leave ~16GB for the FE and OS, set the BE to use about 40GB:
Copy code
bash
mem_limit = 40G
Or, if you prefer percentages:
Copy code
bash
mem_limit = 60%
2. Why this is important for FE/BE co-location By default, 
mem_limit
is 90%. If both processes are on the same machine: * BE will try to grab 90% of the RAM. * FE (which runs on the JVM) will try to grab the memory specified in its 
JAVA_OPTS
(usually 
-Xmx8g
or more). * Result: The total requested memory exceeds 100%, causing the Linux kernel to trigger the OOM Killer, which usually kills the BE process because it is the largest memory consumer. 3. Check FE Memory Limits While you are at it, ensure the FE doesn't grow too large. Check 
conf/fe.conf
for the 
JAVA_OPTS
line:
Copy code
bash
JAVA_OPTS="-Xmx8192m -XX:+UseG1GC ..."
Make sure the 
-Xmx
value for the FE plus the 
mem_limit
for the BE leaves at least 2–4GB of "breathing room" for the Operating System and PageCache. 4. Apply Changes After saving the file, you must restart the BE process for the changes to take effect:
Copy code
bash
./bin/stop_be.sh
./bin/start_be.sh --daemon
Summary of Memory Logic When you set `mem_limit`: * Soft Limit (80% of 
mem_limit
): BE starts aggressively cleaning up its internal caches. * Hard Limit (90% of 
mem_limit
): BE starts killing queries to prevent a crash. * Physical Limit: If the process actually reaches the limit you set, StarRocks will try to keep it under that cap, preventing the OS from killing the process. References • administration/management/BE_configuration.md • administration/management/resource_management/Memory_management.md • deployment/environment_configurations.md • faq/resource_isolation_faq.md References • administration/management/BE_configuration.md
l
@Rocky this server have 32GB, run both FE and BE, what is best memory setting for BE, as FE is Xmx8192m level Label Parent Limit Current Consumption Peak Consumption 1process25G11G20G2jemalloc_metadataprocessnone308M309M2query_poolprocess22G1701M11G2loadprocess7G1036M3G2compactionprocess25G0257M2schema_changeprocessnone002page_cacheprocessnone5G5G2jit_cacheprocessnone74K74K2cloneprocessnone002consistencyprocess5G002datacacheprocessnone5G5G2replicationprocessnone002metadataprocessnone1119M1151M2updateprocess15G872M1855M
r
Based on your server having 32GB total RAM and the FE using 8GB, your current BE limit of 25GB is too high. When the FE and BE are co-located, the total memory requested ($8\text{GB FE} + 25\text{GB BE} = 33\text{GB}$) exceeds your physical RAM. This is why your BE is likely being killed by the OS. Recommended Setting You should set your BE memory limit to 18G or 20G at most. In `be.conf`:
Copy code
bash
mem_limit = 20G
Why 20GB? Here is the breakdown of your 32GB: * FE (Heap): 8GB (via 
Xmx8192m
). * FE (Non-Heap/Overhead): ~1–2GB (JVM stack, Metaspace, and internal overhead). * OS/System Reserve: 2GB (Required for the Linux kernel and basic services). * BE Limit: 20GB remaining. Analysis of your Mem Tracker data: * Current Process Peak (20G): Your BE has already hit 20GB in the past. Since your FE is also running, at that moment you were using roughly $20\text{ (BE)} + 10\text{ (FE total)} = 30\text{GB}$. This leaves almost no room for the OS, which explains the crashes in your logs. * Caches (10GB): You have 
page_cache
(5GB) and 
datacache
(5GB). If you continue to see memory pressure after setting the limit to 20G, you may need to reduce these in `be.conf`: * 
storage_page_cache_limit = 15%
(roughly 3GB) * 
block_cache_mem_size = 15%
(roughly 3GB) Steps to Fix: 1. Edit 
conf/be.conf
. 2. Change or add 
mem_limit = 20G
. 3. Restart the BE: 
./bin/stop_be.sh
then 
./bin/start_be.sh --daemon
. This change ensures that StarRocks will trigger its own internal memory management (canceling queries or clearing caches) before the Linux kernel decides to kill the entire process.
l
@Rocky when server running BE, FE is inscrease memory to 64GB ram, do i need to restart BE, FE
r
Yes, you must restart both the FE and BE for them to utilize the new 64GB of RAM. Even if you use percentage settings, StarRocks processes typically calculate their memory boundaries at startup. Furthermore, because you are running both on one machine, you should manually update your configurations to take full advantage of the new capacity. Here is the recommended configuration for your new 64GB setup: 1. Update FE (
fe.conf
) Since you now have 64GB, you can safely increase the FE heap to 16GB. This is the standard recommendation for metadata stability. * Edit: 
conf/fe.conf
* Change:
Copy code
bash
    JAVA_OPTS="-Xmx16384m -Xms16384m ..."
(Note: It is recommended to set 
-Xms
and 
-Xmx
to the same value to prevent JVM resizing pauses.) 2. Update BE (
be.conf
) With the FE taking ~16-18GB (heap + overhead) and leaving some room for the OS, you can now increase the BE limit to 40GB. * Edit: 
conf/be.conf
* Change:
Copy code
bash
    mem_limit = 40G
3. Why a restart is mandatory * FE: The JVM memory limit (
-Xmx
) is a hard limit set when the Java process starts. It cannot be changed while the process is running. * BE: Even if 
mem_limit
is set to a percentage (like 
90%
), the BE usually calculates the actual byte limit based on the system's available RAM at the moment it starts. If you "hot-plugged" RAM into a virtual machine, the BE will likely continue using the old limit until it is restarted. * Co-location safety: Restarting ensures that both processes recognize the new boundaries and don't compete for memory, which prevents the "Invalid argument" and "Accept()" errors you saw earlier (which were symptoms of the BE crashing/restarting under pressure). Recommended Restart Sequence: 1. Stop BE: 
./bin/stop_be.sh
2. Stop FE: 
./bin/stop_fe.sh
3. Start FE: 
./bin/start_fe.sh --daemon
4. Start BE: 
./bin/start_be.sh --daemon
References • knowledge/trouble_shooting/fe_memory_problems.md • faq/Others.md • administration/Meta_recovery.md • faq/operation_maintenance_faq.md • deployment/upgrade.md • administration/management/FE_configuration.md • faq/fe_mem_faq.md
l
@Rocky i have a role uw_read_only as follow, but want alter this role to select all table but except table1, 2, 3 CREATE ROLE uw_read_only; -- Grant the privilege to query all tables to the role. GRANT SELECT ON ALL TABLES IN DATABASE uw TO ROLE uw_read_only; -- Grant the privilege to query all views to the role. GRANT SELECT ON ALL VIEWS IN DATABASE uw TO ROLE uw_read_only; -- Grant the privilege to query all materialized views and the privilege to accelerate queries with them to the role. GRANT SELECT ON ALL MATERIALIZED VIEWS IN DATABASE uw TO ROLE uw_read_only;
r
In StarRocks, subset revocation is not supported. If you grant a privilege using the 
ALL TABLES
syntax, you cannot later revoke access to specific tables within that database. The privilege is stored at the database level, and the system does not support "exceptions" or "deny" rules. To achieve your goal of allowing access to all tables except 
table1
, 
table2
, and 
table3
, you must manually manage the grants at the table level. Recommended Steps 1. Revoke the existing broad permissions First, you must remove the broad database-level grants you already applied:
Copy code
sql
REVOKE SELECT ON ALL TABLES IN DATABASE uw FROM ROLE uw_read_only;
REVOKE SELECT ON ALL VIEWS IN DATABASE uw FROM ROLE uw_read_only;
REVOKE SELECT ON ALL MATERIALIZED VIEWS IN DATABASE uw FROM ROLE uw_read_only;
2. Grant permissions to specific tables You must now explicitly list the tables/views you want to allow.
Copy code
sql
-- List all tables EXCEPT table1, table2, table3
GRANT SELECT ON TABLE uw.table4, uw.table5, uw.table6, ... TO ROLE uw_read_only;
Important Considerations * Future Tables: Because you are now granting permissions at the table level, any new tables created in the 
uw
database will not be accessible to this role automatically. You will need to run a 
GRANT
statement for every new table created. * Workaround (Database Separation): If the list of tables is very long or changes frequently, the best practice is to move the sensitive tables (
table1
, 
table2
, 
table3
) into a separate database (e.g., 
uw_private
). Then you can safely use the 
GRANT SELECT ON ALL TABLES IN DATABASE uw TO ROLE uw_read_only;
command for the remaining tables. * Automation: If you have many tables, you can generate the required SQL commands by querying the `information_schema`:
Copy code
sql
    SELECT CONCAT('GRANT SELECT ON TABLE ', table_schema, '.', table_name, ' TO ROLE uw_read_only;')
    FROM information_schema.tables
    WHERE table_schema = 'uw'
      AND table_name NOT IN ('table1', 'table2', 'table3');
References • faq/operation_maintenance_faq.md • administration/user_privs/authorization/User_privilege.md References • faq/operation_maintenance_faq.md • administration/user_privs/authorization/privilege_faq.md • administration/user_privs/authorization/User_privilege.md • administration/user_privs/authorization/privilege_item.md • sql-reference/sql-statements/account-management/REVOKE.md
l
@Rocky SQL Error [5203] [42000]: Access denied; you need (at least one of) the DROP privilege(s) on TABLE dwh_fcc_date for this operation. Please ask the admin to grant permission(s) or try activating existing roles using <set [default] role>. Current role(s): [dmapp_read_only, uw_read_only, role_uw]. Inactivated role(s): [uw_admin]. Access denied; you need (at least one of) the DROP privilege(s) on TABLE dwh_fcc_date for this operation. Please ask the admin to grant permission(s) or try activating existing roles using <set [default] role>. Current role(s): [dmapp_read_only, uw_read_only, role_uw]. Inactivated role(s): [uw_admin].
r
The error message clearly identifies the problem: you have a role named 
uw_admin
 that likely possesses the required 
DROP
privilege, but it is inactivated. In StarRocks, a role assigned to you is not always active by default. To fix this, you have two options: 1. Activate the role for the current session If you only need to perform this operation once, run this command in your SQL editor before running your 
DROP
or 
TRUNCATE
statement:
Copy code
sql
SET ROLE 'uw_admin';
_Note: This will replace your current active roles with 
uw_admin
for this session only._ To keep your existing roles and add `uw_admin`:
Copy code
sql
SET ROLE ALL;
2. Set the role as a Default (Recommended) To ensure 
uw_admin
is always active every time you log in, set it as your default role:
Copy code
sql
SET DEFAULT ROLE 'uw_admin', 'dmapp_read_only', 'uw_read_only', 'role_uw' TO CURRENT_USER;
Or, to make all your assigned roles active by default:
Copy code
sql
SET DEFAULT ROLE ALL TO CURRENT_USER;
Why is this happening? * RBAC (Role-Based Access Control): StarRocks uses an RBAC model where users can have multiple roles. Even if a role is granted to you, it must be "activated" to use the permissions within it. * Missing Privilege: If you activate the role and the error persists, it means even the 
uw_admin
role does not actually have the 
DROP
privilege on that specific table. In that case, an admin would need to run:
Copy code
sql
    GRANT DROP ON TABLE dwh_fcc_date TO ROLE uw_admin;
Summary of your session status: * Active Roles: 
dmapp_read_only
, 
uw_read_only
, 
role_uw
(None of these have DROP rights). * Inactive Role: 
uw_admin
(This one likely has the right, but it's "turned off"). References • administration/user_privs/authorization/privilege_faq.md • administration/user_privs/authorization/User_privilege.md • sql-reference/sql-statements/account-management/SET_DEFAULT_ROLE.md • sql-reference/sql-statements/account-management/SET_ROLE.md off").
l
@Rocky GRANT DROP ALL TABLES IN DATABASE uw TO ROLE uw_admin; corect?
r
Not quite. You are missing the keyword 
ON
. The correct syntax is:
Copy code
sql
GRANT DROP ON ALL TABLES IN DATABASE uw TO ROLE uw_admin;
Key Details: 1. Missing `ON`: The 
ON
keyword is mandatory before specifying the target (e.g., 
ALL TABLES
). 2. Scope: This command grants the privilege to drop any table currently in the 
uw
database, as well as any tables created there in the future. 3. Database Drop: If you also want this role to be able to drop the entire database (not just the tables inside it), you should also run:
Copy code
sql
    GRANT DROP ON DATABASE uw TO ROLE uw_admin;
Important Reminder After running the 
GRANT
command, don't forget that you must have the role activated to use it. Since your previous error showed 
uw_admin
was inactivated, run this to make it active by default:
Copy code
sql
SET DEFAULT ROLE 'uw_admin' TO CURRENT_USER;
References • sql-reference/sql-statements/account-management/GRANT.md • administration/user_privs/authorization/privilege_item.md References • sql-reference/sql-statements/account-management/GRANT.md
l
@Rocky SQL Error [5203] [42000]: Access denied; you need (at least one of) the DROP privilege(s) on TABLE dwh_fcc_date for this operation. Please ask the admin to grant permission(s) or try activating existing roles using <set [default] role>. Current role(s): [dmapp_read_only, uw_read_only, uw_admin, role_uw]. Inactivated role(s): NONE. Access denied; you need (at least one of) the DROP privilege(s) on TABLE dwh_fcc_date for this operation. Please ask the admin to grant permission(s) or try activating existing roles using <set [default] role>. Current role(s): [dmapp_read_only, uw_read_only, uw_admin, role_uw]. Inactivated role(s): NONE.
r
It looks like 
uw_admin
is now active, but you are still getting an "Access denied" error. This usually happens for one of two reasons: 1. The table is in a different database Based on the table name 
dwh_fcc_date
, is it possible that this table is actually in a database named 
dwh
 (or something else) rather than 
uw
? The privilege you granted was specifically for the 
uw
database. If the table is in a different database, you need to grant the privilege for that specific database:
Copy code
sql
-- Check which database the table is actually in
SELECT table_schema FROM information_schema.tables WHERE table_name = 'dwh_fcc_date';

-- Then grant the privilege to the correct database (replace 'dwh' with the actual name)
GRANT DROP ON ALL TABLES IN DATABASE dwh TO ROLE uw_admin;
2. Verify your current privileges To see exactly what privileges the 
uw_admin
role currently has, run this command:
Copy code
sql
SHOW GRANTS FOR ROLE uw_admin;
Look for a line that says 
GRANT DROP ON TABLE ...
. If you don't see it for the database containing 
dwh_fcc_date
, the role doesn't have the permission yet. 3. Are you using a specific Catalog? If you are using an external catalog (like Hive or Iceberg), the grant syntax requires the catalog name:
Copy code
sql
GRANT DROP ON ALL TABLES IN <catalog_name>.uw TO ROLE uw_admin;
Recommendation: Try to qualify the table name with the database name in your command to be sure, for example: 
DROP TABLE uw.dwh_fcc_date;
. If that fails, it confirms the 
uw_admin
role doesn't have the required permission for that specific database. References • sql-reference/sql-statements/account-management/SHOW_GRANTS.md • administration/user_privs/authorization/privilege_item.md • sql-reference/sql-statements/account-management/GRANT.md References • administration/user_privs/authorization/User_privilege.md • sql-reference/sql-statements/account-management/SHOW_GRANTS.md • sql-reference/sys/grants_to_roles.md • sql-reference/sys/role_edges.md • sql-reference/sql-statements/account-management/SHOW_ROLES.md • sql-reference/information_schema/schema_privileges.md
l
@Rocky how to disable a submited task
r
To "disable" or stop a task submitted via the 
SUBMIT TASK
command, you have two main options depending on whether you want to temporarily pause it or remove it entirely. 1. Suspend a Task (v4.1+) If you are on StarRocks v4.1 or later, you can temporarily disable (suspend) a task without deleting it. This stops the scheduler for periodic tasks and kills any currently running instances.
Copy code
sql
ALTER TASK <task_name> SUSPEND;
To re-enable it later:
Copy code
sql
ALTER TASK <task_name> RESUME;
2. Drop (Delete) a Task If you want to stop the task and remove its definition from the system, use the 
DROP TASK
command. This will also automatically cancel any currently running execution (
TaskRun
) of that task.
Copy code
sql
DROP TASK <task_name>;
3. Stop a Specific Running Query (Kill) If you just want to stop the current execution of a task without affecting future scheduled runs (or if you don't want to drop the task definition), you can kill the specific query: 1. Find the 
query_id
or 
connection_id
using:
Copy code
sql
   SHOW PROCESSLIST;
   -- OR check task runs specifically
   SELECT * FROM information_schema.task_runs WHERE status = 'RUNNING';
2. Kill the query:
Copy code
sql
   KILL QUERY <query_id>;
How to find your Task Name If you are unsure of the task name, you can find it by querying the metadata:
Copy code
sql
SELECT * FROM information_schema.tasks;
Summary of other "Task" types: * Routine Load: Use 
PAUSE ROUTINE LOAD FOR <job_name>;
* Pipe: Use 
ALTER PIPE <pipe_name> SUSPEND;
* Analyze/Statistics: Use 
KILL ANALYZE <id>;
References • sql-reference/sql-statements/loading_unloading/ETL/ALTER_TASK.md • sql-reference/sql-statements/loading_unloading/ETL/DROP_TASK.md • sql-reference/sql-statements/cluster-management/nodes_processes/KILL.md References • sql-reference/sql-statements/loading_unloading/ETL/DROP_TASK.md • using_starrocks/Cost_based_optimizer.md • administration/management/compaction.md • sql-reference/sql-statements/cbo_stats/KILL_ANALYZE.md • sql-reference/sql-statements/loading_unloading/CANCEL_LOAD.md • sql-reference/sql-statements/table_bucket_part_index/CANCEL_ALTER_TABLE.md • sql-reference/sql-statements/cluster-management/nodes_processes/KILL.md
l
@Rocky ALTER TABLE starrocks_audit_db__.af_extract_mapping MODIFY COLUMN BATCH_SIZE varchar(10) NULL; this one correct?
r
The syntax you provided is mostly correct, but in StarRocks, 
MODIFY COLUMN
 requires you to be very specific about the column's properties. The basic syntax is:
Copy code
sql
ALTER TABLE starrocks_audit_db__.af_extract_mapping 
MODIFY COLUMN BATCH_SIZE VARCHAR(10) NULL;
Important Requirements: 1. Key Columns: If 
BATCH_SIZE
is a Key column (part of the sort key), you must include the 
KEY
keyword:
Copy code
sql
    ALTER TABLE ... MODIFY COLUMN BATCH_SIZE VARCHAR(10) KEY NULL;
2. Preserving Properties: StarRocks requires you to re-state existing properties (like 
DEFAULT
values or 
COMMENT
) if you want to keep them. If the column currently has a default value, include it in the command:
Copy code
sql
    ALTER TABLE ... MODIFY COLUMN BATCH_SIZE VARCHAR(10) NULL DEFAULT "0";
3. Nullability Restrictions: * You cannot change a column from 
NULL
to 
NOT NULL
. * Changing from 
NOT NULL
to 
NULL
is generally supported. 4. Data Loss: If you are shortening the 
VARCHAR
length (e.g., from 20 to 10), StarRocks will allow it, but any data exceeding the new length will be truncated or cause errors during the schema change process. Recommendation Run this first to see the current full definition of the column:
Copy code
sql
SHOW CREATE TABLE starrocks_audit_db__.af_extract_mapping;
Then, copy the column definition exactly as it appears, change only the 
VARCHAR
length, and use that in your 
ALTER TABLE
statement. References • sql-reference/sql-statements/table_bucket_part_index/ALTER_TABLE.md • sql-reference/sql-statements/table_bucket_part_index/SHOW_CREATE_TABLE.md References • sql-reference/sql-statements/table_bucket_part_index/ALTER_TABLE.md • sql-reference/sql-statements/table_bucket_part_index/CREATE_TABLE.md • table_design/Data_types.md • sql-reference/sql-statements/table_bucket_part_index/SHOW_CREATE_TABLE.md • sql-reference/sql-statements/table_bucket_part_index/ALTER_TABLE_COLUMN_PROPERTIES.md • sql-reference/sql-statements/table_bucket_part_index/ALTER_TABLE_LTSC.md • administration/management/Schema_evolution.md • sql-reference/sql-statements/table_bucket_part_index/RENAME_COLUMN.md -COLUMN) -beta) • administration/User_privilege.md • administration/Privilege_item.md -old) • sql-reference/sql-statements/account-management/GRANT.md • sql-reference/sql-statements/loading_unloading/ETL/SUBMIT_TASK.md • sql-reference/sql-statements/loading_unloading/ETL/ALTER_TASK.md
• sql-reference/sql-statements/loading_unloading/ETL/DROP_TASK.md • sql-reference/sql-statements/cluster-management/nodes_processes/KILL.md • sql-reference/sql-statements/loading_unloading/ROUTINE_LOAD.md • sql-reference/sql-statements/loading_unloading/PAUSE_ROUTINE_LOAD.md • sql-reference/sql-statements/loading_unloading/PIPE.md • sql-reference/sql-statements/loading_unloading/ALTER_PIPE.md • sql-reference/sql-statements/cbo_stats/KILL_ANALYZE.md • sql-reference/sql-statements/loading_unloading/CANCEL_LOAD.md • sql-reference/sql-statements/table_bucket_part_index/CANCEL_ALTER_TABLE.md • sql-reference/information_schema/tasks.md • sql-reference/information_schema/task_runs.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROCESSLIST.md • sql-reference/sql-statements/account-management/SET_DEFAULT_ROLE.md • sql-reference/sql-statements/account-management/SHOW_GRANTS.md • sql-reference/information_schema/tables.md • administration/Privilege_item.md References • sql-reference/sql-statements/table_bucket_part_index/ALTER_TABLE.md
l
how to check show alter table process
@Rocky how to check show alter table process?
r
To check the progress of an 
ALTER TABLE
operation in StarRocks, you use the 
SHOW ALTER TABLE
command. Because StarRocks treats different types of schema changes separately, you need to specify the type of operation you are checking: 1. Check Column Changes (Add, Drop, Modify) If you just ran an 
ALTER TABLE ... MODIFY COLUMN
or 
ADD COLUMN
command, use:
Copy code
sql
SHOW ALTER TABLE COLUMN;
* Progress: Shows the percentage of the data that has been processed. * State: Look for 
FINISHED
(done), 
RUNNING
(in progress), or 
CANCELLED
(failed). 2. Check Bucketing or Schema Optimization (v3.2+) If you are changing the number of buckets or the bucketing method:
Copy code
sql
SHOW ALTER TABLE OPTIMIZE;
3. Check Rollup or Synchronous Materialized Views If you are adding an index or a synchronous MV:
Copy code
sql
SHOW ALTER TABLE ROLLUP;
-- or for Materialized Views specifically
SHOW ALTER MATERIALIZED VIEW;
4. Filter for a Specific Table If your database has many ongoing tasks, you can filter the results by table name:
Copy code
sql
SHOW ALTER TABLE COLUMN 
WHERE TableName = "your_table_name" 
ORDER BY CreateTime DESC 
LIMIT 1;
Important Notes: * Asynchronous: 
ALTER TABLE
operations in StarRocks are asynchronous. The command returns immediately, but the work happens in the background. * One at a time: You can only run one schema change operation on a single table at a time. If you try to start another before the first is 
FINISHED
, you will get a "table's state is not normal" error. * Canceling: If you need to stop an ongoing alter operation, use:
Copy code
sql
    CANCEL ALTER TABLE COLUMN FROM database_name.table_name;
References • sql-reference/sql-statements/table_bucket_part_index/SHOW_ALTER.md • faq/Sql_faq.md • sql-reference/sql-statements/table_bucket_part_index/CANCEL_ALTER_TABLE.md • sql-reference/sql-statements/materialized_view/SHOW_ALTER_MATERIALIZED_VIEW.md References • sql-reference/sql-statements/table_bucket_part_index/SHOW_ALTER.md • faq/Sql_faq.md • sql-reference/sql-statements/materialized_view/SHOW_ALTER_MATERIALIZED_VIEW.md • faq/operation_maintenance_faq.md • administration/data_migration_tool.md • sql-reference/sql-statements/table_bucket_part_index/ALTER_TABLE.md
Open in Slack
PreviousNext
Powered by