作者: Maclean Liu, post on May 26th, 2011 事情是这样的，客户有一套核心的10g业务数据库，需要针对个别大表删除2年前的归档数据，这些表都是普通的堆表(heap table)，没有使用分区或其他技术。因为考虑到不能影响在线业务，所以不能使用insert append/rename的方式来加速删除，只能老老实实地在匿名PL/SQL块里通过rowid批量删除数据，虽然慢一些但还是能接受的,具体的PL/SQL块如下:
DECLARE CURSOR table_name_cur IS SELECT /*+ FULL(a) */ a.rowid from table_name a where time_column<required_date table_name_rec table_name_cur%ROWTYPE; row_number number; BEGIN row_number :=0; OPEN table_name_cur; LOOP FETCH table_name_cur INTO table_name_rec; IF table_name_cur%NOTFOUND THEN commit; EXIT; END IF; delete from table_name WHERE rowid = table_name_rec.rowid; row_number := row_number + 1; if (mod (row_number,1000) =0) then . . . → Read More: SQL调优:Clustering Factor影响数据删除速度一例
作者: Maclean Liu, post on April 25th, 2011 之前有用户在AWR中定位到问题SQL语句后想要了解该SQL statement的具体执行计划，于是就用AWR报告中得到的SQL ID去V$SQL等几个动态性能视图中查询，但发现V$SQL或V$SQL_PLAN视图都已经找不到对应SQL ID的记录，一般来说这些语句已经从shared pool共享池中被替换出去了。
这个时候我们可以尝试使用DBMS_XPLAN.DISPLAY_AWR存储过程来将Oracle Automatic Workload Repository自动负载仓库中记录的SQL语句相关信息抽取出来，如:
SQL> set linesize 200 pagesize 2000; SQL> select * from global_name; GLOBAL_NAME ——————————————————————————– oracledatabase12g.com SQL> select /* extract_me */ count(*) from maclean; COUNT(*) ———- 9564 SQL> select sql_id from v$sql where sql_text like ‘%extract_me%’ and sql_text not like ‘%like%’; SQL_ID ————- 8vff23q8qp9fj SQL> exec dbms_workload_repository.create_snapshot; PL/SQL . . . → Read More: Extract SQL Plan from AWR
作者: Maclean Liu, post on March 25th, 2011 Sql Tuning Advisor是10g以后出现的一个十分有用的调优工具，大多数情况下我们可以通过dbconsole或者Grid Control的web界面调用SQL Advisor；但如果系统中没有配置dbconsole或者Grid Control的话，我们则需要通过手动调用DBMS_SQLTUNE PL/SQL程序包来使用该特性。这里我列出一个针对单个SQL语句Autotune的脚本，具体脚本:
begin DBMS_SQLTUNE.drop_tuning_task(‘&task_name’); end; / DECLARE my_task_name VARCHAR2(30); my_sqltext CLOB; my_sqlid varchar2(30); BEGIN my_sqlid := ‘&sqlid’; my_task_name := dbms_sqltune.create_tuning_task(sql_id => my_sqlid, scope => ‘COMPREHENSIVE’, time_limit => 300, task_name => ‘&task_name’, description => ‘comment’ ); END; / BEGIN dbms_sqltune.execute_tuning_task(task_name => ‘&task_name’); END; / SELECT status FROM USER_ADVISOR_TASKS WHERE task_name = . . . → Read More: Utilize Sql Tuning Advisor from Script
作者: Maclean Liu, post on March 22nd, 2011 在10g以后我们可以通过利用gather_plan_statistics提示来了解更多的SQL执行统计信息，具体使用方法如下：
SQL> set linesize 150 SQL> set pagesize 2000 SQL> set autotrace traceonly exp SQL> select avg(SALARY),DEPARTMENT_NAME from employees e,departments d where e.DEPARTMENT_ID=d.DEPARTMENT_ID group by DEPARTMENT_NAME; Execution Plan ———————————————————- Plan hash value: 3294250112 ——————————————————————————————— | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ——————————————————————————————— | 0 | SELECT STATEMENT . . . → Read More: Gather more plan statistics by gather_plan_statistics hint
作者: Maclean Liu, post on March 19th, 2011 周五在一家客户的调优会议中讨论了一个由于统计信息陈旧导致SQL执行计划偏差的问题，这是一个10g的库并且禁用了自动收集统计信息的定时作业GATHER_STATS_JOB；当问及应用程序开发商为何要禁用自动统计信息收集时，开发商的一位工程师说因为该库的数据量较大，考虑到该JOB每天都会将所有大表统计一遍可能要花费大量时间所以予以停用。
这里就存在一个问题，GATHER_STATS_JOB自动统计作业是每次打开都会将数据库中所有的对象的统计信息都收集一遍吗？细心的朋友一定会发觉实际上该JOB的运行时间是时长时短的，同时绝对不是如这位开发工程师所说的会每天都重复统计所有表。
10g的官方文档中对该GATHER_STATS_JOB描述为”The Scheduler runs this job when the maintenance window is opened. By default, the maintenance window opens every night from 10 P.M. to 6 A.M. and all day on weekends.The stop_on_window_close attribute controls whether the GATHER_STATS_JOB continues when the maintenance window closes. The default setting for the stop_on_window_close attribute is TRUE, causing Scheduler . . . → Read More: Does GATHER_STATS_JOB gather all objects’ stats every time?
作者: Maclean Liu, post on March 13th, 2011 redo重做日志是Oracle数据库恢复(recovery)的基础；但在很多情况下可以通过禁用重做日志的产生来加速SQL语句的完成，也就是我们所说的可nologging化的操作，这些操作大多是或串行的或并行的数据载入。
那么哪些操作是允许被nologging化的呢？首先需要注意的是普通的DML操作，即:常规insert,update,和delete(以及merge)总是不能被nologging执行的。但以下SQL语句则可以以nologging选项执行：
direct load (SQL*Loader) direct load INSERT (using APPEND hint) CREATE TABLE … AS SELECT CREATE INDEX ALTER TABLE … MOVE PARTITION ALTER TABLE … SPLIT PARTITION ALTER INDEX … SPLIT PARTITION ALTER INDEX … REBUILD ALTER INDEX … REBUILD PARTITION INSERT, UPDATE, and DELETE on LOBs in NOCACHE NOLOGGING mode stored out of . . . → Read More: Oracle中可以nologging执行的操作
作者: Maclean Liu, post on February 20th, 2011 Question:某客户的应用做过变更（短链变长链），现cpu利用率较之前有明显改善，参见附件中的awr报告。想咨询一下sql语句的执行时间，cpu Time等指标，是否会受到短链变长链影响，因为从awr报告看，性能有明显改善。
Load Profile 变更前:
Per Second Per Transaction Redo size: 244,606.59 13,269.94 Logical reads: 5,964.59 323.58 Block changes: 1,278.41 69.35 Physical reads: 339.03 18.39 Physical writes: 35.30 1.92 User calls: 693.44 37.62 Parses: 241.46 13.10 Hard parses: 0.16 0.01 Sorts: 97.93 5.31 Logons: 16.05 0.87 Executes: 617.55 33.50 Transactions: 18.43
变更后:
Per Second Per . . . → Read More: 应用长短链接变更对于Oracle数据库性能的影响
作者: Maclean Liu, post on February 18th, 2011 并不是所有的SQL operations都是可并行化的；不少人认为sort merge join这种排序合并操作是不能并行化的，这显示是一种错误的认识。有了这样一个列表你就可以更好地理解Oracle中的Parallel Execution了：
Parallel Query: Table scan Nested loop join Sort merge join NOT IN GROUP BY Hash join SELECT DISTINCT UNION and UNION ALL Aggregation PL/SQL functions called from SQL ORDER BY DDL: CREATE TABLE AS SELECT CREATE INDEX Rebuild index Move partition Split partition DML: UPDATE on partitioned table DELETE on . . . → Read More: Oracle中可被并行化执行的SQL操作
|
|
最新评论