# Lakehouse Job History

Through the job history page, you can view detailed information about queries executed in the Lakehouse account over the past 7 days. This page displays a list of historical jobs, including tasks submitted using a JDBC jar, Studio ad-hoc queries, and Studio scheduled tasks.

## Job History

## View History

Click "Compute" in the left navigation bar, then click "Job History" to enter the job history page:

^

## Interface

* Supports searching by job ID generated by SQL jobs
* Supports searching by status
  * Initializing: SQL initialization phase, including operations such as compilation and optimization
  * Cluster Starting: Waiting for the Virtual Cluster to start. If it takes a long time to start, please contact technical support
  * Queued: Job is queued waiting for resources. If it takes a long time, check whether the Virtual Cluster resources are fully occupied and consider scaling up the Virtual Cluster
  * Running: SQL data processing time. You can click into diagnostics to view the time taken by each operator
  * Succeeded: Job has ended. Some jobs may have a cleanup process at this stage, which can take time
* Supports filtering by duration
* Supports filtering by time. Currently, up to 10,000 jobs from the past seven days can be queried
* Supports filtering by the name of the cluster where the job ran
* Supports filtering by the job submitter
* Supports filtering by queryTag
  Users can use the command `set query_tag=""` when submitting SQL to indicate the job source and tag the job, making it easy to filter in this interface.
  * Set query\_tag in the Studio interface, select two SQL statements and execute simultaneously:
  ```SQL
      set query_tag="test";
      select 1;
  ```
  * Add query\_tag in the JDBC URL so that every submitted SQL carries the query\_tag to indicate the source, which can be filtered on the page:
  ```text
  jdbc:clickzetta://demo_instance.cn-shanghai-alicloud.api.clickzetta.com/default?schema=public&query_tag=test

  ```
  * Set query\_tag in Python code:
  ```python
  # Establish connection
  conn = connect(username='',
   password='', 
  service='cn-shanghai-alicloud.api.clickzetta.com', 
  instance='demo_instance',
   workspace='', schema='public', vcluster='DEFAULT') 
  # Execute SQL
  cursor = conn.cursor() 
  my_param["hints"]["query_tag"] ="test"
  cursor.execute('select 1;', parameters=my_param)

  ```
* The default Schema for the job is the context in which the submitted SQL runs, which can be obtained through `select current_schema()`.

## Job Details

Enter the job details to view detailed information about the job.

^

### Stage Interface

SQL execution is divided into stages, which are executed from bottom to top. Clicking on a specific stage will show the specific time consumption of each stage.

^

**Field information is explained as follows**

|                    |                                                                                                                                                                                                                |
| ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Field              | Description                                                                                                                                                                                                    |
| Status             | Indicates the status of the job. Currently includes:&#xA;Queued: Waiting for resources&#xA;Running: Running, the job is processing data&#xA;Succeeded: Job ran successfully&#xA;Failed: Job ran unsuccessfully |
| Start Time         | The start time of the stage. In AP clusters, stages run in parallel                                                                                                                                            |
| End Time           | The end time of the job                                                                                                                                                                                        |
| Duration           | The duration of the stage running                                                                                                                                                                              |
| Spill to Disk      | The size of the data spilled to disk. This parameter indicates whether slow performance is due to insufficient cluster memory resources                                                                        |
| Read from Cache    | In AP clusters, data that has already been read is cached first to accelerate computation                                                                                                                      |
| Contains Operators | Stage                                                                                                                                                                                                          |

### Operator Interface

In the operator interface, you can view the type of each operator and its upstream and downstream dependencies. An operator is a concept in the query plan that represents the specific steps and strategies for executing a query, including data access, transformation, and updates.

^

**Field information is explained as follows**

| Field            | Description                                                                                                                             |
| :--------------- | :-------------------------------------------------------------------------------------------------------------------------------------- |
| Belongs to Stage | The stage corresponding to the operator                                                                                                 |
| Spill to Disk    | The size of the data spilled to disk. This parameter indicates whether slow performance is due to insufficient cluster memory resources |
| Read from Cache  | In AP clusters, data that has already been read is cached first to accelerate computation                                               |
| Total Rows       | The data currently processed by the operator                                                                                            |
| Duration         | Operators run concurrently. The displayed value is the average time of the operator                                                     |
| Field            | Corresponds to the fields in the SQL script                                                                                             |

### Table Mode

Supports switching stages to table mode

^

Supports switching operators to table mode


## Analyzing Failed Jobs

When a job fails to run, you can view the reason for the failure through the details in the job profile. Here are some common failure reasons and solutions:

### SQL Syntax Error

**Error Example**:

```SQL
Execute select * from ttt;
Error: CZLH-42000:[1,15] Semantic analysis exception - table or view not found - uat_demo_project.`public`.ttt
```

**Error code CZLH-42000** indicates an error related to SQL language parsing. `[1,15]` means the error occurred at line 1, column 15 of the SQL. In this example, the reason is that the `ttt` table does not exist.

## Analyzing Slow Running Jobs

Slow running jobs may encounter issues during the compilation phase, the Virtual Cluster startup phase, or the execution phase. Below are analyses and solutions for these phases:

### Compilation Phase

**Issue**: Job status shows "Initializing".

**Possible Causes and Solutions**:

1. **Complex execution plan**: The job may require a long time to optimize. Please be patient — it should not take more than 10 minutes under normal circumstances.
2. **Compilation resources are fully occupied**: If you submit a large number of SQL statements at once, it may lead to insufficient compilation resources. Please reduce the frequency of SQL submissions. If you have a large number of high-concurrency query requirements, please submit a ticket for assistance.

### Virtual Cluster Startup Phase

**Issue**: Job status shows "Cluster Starting". (The current status is that the compute cluster is being started)

### Queued Phase

**Issue**: Job status shows "Queued".

**Possible Causes and Solutions**:

1. **Insufficient computing resources in the current cluster**: You can filter and view the currently running jobs through the interface. A large number of running jobs may be causing resource queuing. You can scale up resources, or terminate large running jobs to free up resources.

### Execution Phase

**Issue**: Job status shows "Running". At this stage you can click in to view the execution status of each operator.

**Possible Causes and Solutions**:

1. **Waiting for resources**: The job may be waiting for resource allocation. Please check the resource usage. If necessary, please submit a ticket for assistance.
2. **Slow data reading speed**: The job may be executing slowly due to slow data reading. Please check the data storage and reading strategy. If necessary, optimize the data storage structure or adjust the reading strategy.

### Share for Diagnosis

After entering the job details page, click the "Share" button to share the job with a third party. Recipients can view the content without logging in.
\:-: ![](.topwrite/assets/image_1740557522715.png =774)
If you have any questions or need further assistance, please copy the link above and contact the Lakehouse team. We will diagnose and resolve the issue for you.

## Viewing Execution Plan and Operator Details

During the execution phase, you can click on a specific operator to query its execution steps and strategies. For example, moving the mouse over a specific operator will highlight the corresponding operator in the SQL. This helps you identify which specific operator is causing the job to run slowly.

^
