trace日志默认是关闭的。主要用于分析性能，当出现性能问题时，需临时打开trace日志查看SQL执行计划；
可连上数据库，在数据库中执行set命令打开trace日志：
gbase>set global
gbase_sql_trace=1;
gbase>set global
gbase_sql_trace_level=3;
其中：gbase_sql_trace_level 有1、2、3级，表示trace日志记录信息的详细程度，第3级是最详细的日志内容。日志文件为.trc后缀名的文件中。
Trace日志是根据当前session连接生成的trc日志，故session断开，产生新的trc日志。由于日志内容较大，不方便分析，每次执行sql语句之前建议清空以前的trc日志文件，方法为使用 rm -rf *.trc 删除之前的trace日志。
gcluster层的trace记录SQL的分布式执行计划。可查看SQL语句的计划步骤是3步还是2步，找出执行时间间隔最大的步骤，然后分析是否能应用优化方法进行优化提高性能。
Gnode层的trace日志记录SQL语句的完整执行过程。因为一条SQL语句经gcluster层解析分解执行计划后，会产生很多条SQL语句下发到gnode层，所以在gnode的日志目录下会产生多个.trc日志文件，建议查看执行节点的gnode层的字节数最大的那个.trc文件即可。
一条SQL语句的通用的完整执行流程一般是：
smart
scan -> scan -> join -> aggregation -> sort -> materialization
-> send result
包含聚集和排序操作的时候通常无需单独的物化步骤，物化在聚集和排序过程中已经完成。如果是包含嵌套子查询的复杂SQL，嵌套子查询从内至外递归执行，每一层的执行顺序与上述过程基本相同。
排查性能问题时，就是查看上面步骤具体是哪个步骤耗时长，定位后再分析I/O因素、buffer大小对性能影响等信息，看如何优化能提高性能。
注意说明：
1.
trace日志内容很多，不方便分析，建议在执行sql语句之前清空原日志（或者备份原日志后再清空）。
方法为：每次执行sql前，要使用 rm -rf *.trc 清空之前的trace日志。
2.
技术支持人员无法分析时，可将gcluster层和gnode层的trace日志打包，发送给研发人员做进一步分析。
