[20200324]SQL語句優化的困惑2.txt
[20200324]SQL語句優化的困惑2.txt
--//前幾天寫的http://blog.itpub.net/267265/viewspace-2681575/=>[20200320]SQL語句優化的困惑.txt
--//今天在仔細看,才發現我的分析嚴重錯誤。
--//實際上大量的使用非繫結變數,導致大量的分析還有大量語句沒有很好優化。
1.大量的sql語句沒有使用繫結變數:
SELECT force_matching_signature, COUNT (*)
FROM gv$sql
WHERE PARSING_SCHEMA_NAME = 'OOII' AND sql_text NOT LIKE '%v$sql%'
GROUP BY force_matching_signature
HAVING force_matching_signature <> 0
ORDER BY 2 DESC;
FORCE_MATCHING_SIGNATURE COUNT(*)
------------------------ ----------
12234724059013304283 947
1071793754275225321 946
992788942373700613 922
170325677541164220 847
15867095493683317816 742
3047162561397655970 702
13231292746069278983 631
8605271057674497136 615
13725540604287810943 524
1723926899059683937 517
15412799563593109227 494
11906248150198528834 471
15675074609665662135 388
5903818800448244139 236
9868629658899336069 193
14422749722323563667 186
12664390511952564245 179
14220068335231853764 140
12930486031401074623 121
16525065433651576751 101
...
--//我主要缺乏春節前的awr資料,導致我認為我的優化導致CPU上升,實際上根本不是,另外系統存在大量的垃圾sql語句沒有優化。
2.忽略了疫情在當地基本結束的情況:
--//實際上我自己還忽略一個情況就是疫情在我們當時已經基本結束,前臺業務實際上已經開始抬升。3月9號星期一業務上升很大,也導
--//致我誤認為優化有問題,實際上如果有春節前或者更早的awr資料,CPU的使用還會更高。我現在先修改cursor_sharing=force,應用
--//全部退出。
--//明天繼續觀察看看。
3.大量語句沒有很好的優化,實際上這個問題給沒有使用繫結變數掩蓋了。
--//有一些sql語句居然使用like,講個多少次慎用,無語。
> @ bind_cap 72x02qrhwd3s7 ''
SQL_ID CHILD_NUMBER WAS NAME POSITION MAX_LENGTH LAST_CAPTURED DATATYPE_STRING VALUE_STRING
------------- ------------ --- --------- -------- ---------- ------------------- --------------- -------------
72x02qrhwd3s7 0 YES :SYS_B_0 1 22 2020-03-23 16:11:52 NUMBER 1
YES :SYS_B_1 2 22 2020-03-23 16:11:52 NUMBER 1
YES :SYS_B_2 3 32 2020-03-23 16:11:52 VARCHAR2(32) %03491446%
YES :SYS_B_3 4 22 2020-03-23 16:11:52 NUMBER 102
YES :SYS_B_4 5 22 2020-03-23 16:11:52 NUMBER 223
YES :SYS_B_5 6 22 2020-03-23 16:11:52 NUMBER 4
YES :SYS_B_6 7 22 2020-03-23 16:11:52 NUMBER 35
YES :SYS_B_7 8 22 2020-03-23 16:11:52 NUMBER 36
YES :SYS_B_8 9 22 2020-03-23 16:11:52 NUMBER 37
18 rows selected.
--//今天看到的情況,我還優化幾條sql語句後的情況:
> @ashtop username,sql_id "username='OOII'" trunc(sysdate) trunc(sysdate+1)
Total
Seconds AAS %This USERNAME SQL_ID FIRST_SEEN LAST_SEEN
--------- ------- ------- -------- ------------- ------------------- -------------------
55 .0 17% | OOII 2020-03-24 00:30:38 2020-03-24 09:19:00
39 .0 12% | OOII crbb2spqzdczm 2020-03-24 08:36:49 2020-03-24 09:15:22
26 .0 8% | OOII 02s8t5s2yc9gx 2020-03-24 08:31:13 2020-03-24 08:53:19
26 .0 8% | OOII 1kgy4wjn0ckdw 2020-03-24 08:37:01 2020-03-24 09:15:25
22 .0 7% | OOII 72x02qrhwd3s7 2020-03-24 08:12:47 2020-03-24 09:17:55
22 .0 7% | OOII ck3nrshb15tb4 2020-03-24 01:16:40 2020-03-24 09:11:44
15 .0 5% | OOII 2x8fbny3pxvfu 2020-03-24 08:05:05 2020-03-24 09:15:06
13 .0 4% | OOII 284xbhpcdj6qa 2020-03-24 00:48:39 2020-03-24 09:11:44
12 .0 4% | OOII g9yvgwq7fmd5h 2020-03-24 08:04:02 2020-03-24 08:59:47
6 .0 2% | OOII byvvc43nba2qr 2020-03-24 08:10:14 2020-03-24 08:51:24
5 .0 2% | OOII 3639zfppzp1vk 2020-03-24 01:28:45 2020-03-24 08:29:53
4 .0 1% | OOII 05uqdabhzncdc 2020-03-24 00:50:59 2020-03-24 02:50:48
4 .0 1% | OOII 0d2ndw84bhc6a 2020-03-24 05:39:23 2020-03-24 07:03:55
4 .0 1% | OOII g3a9ff2a5h2pq 2020-03-24 08:09:15 2020-03-24 09:10:50
3 .0 1% | OOII 4hzmgjp8q0tzt 2020-03-24 02:06:48 2020-03-24 06:39:30
3 .0 1% | OOII 98gqc39ujsrvv 2020-03-24 08:39:09 2020-03-24 09:14:20
3 .0 1% | OOII b9mxb1kghymbd 2020-03-24 01:53:01 2020-03-24 09:11:44
2 .0 1% | OOII 1akwygr0fct7j 2020-03-24 09:08:09 2020-03-24 09:08:49
2 .0 1% | OOII 39w37j74gyu0m 2020-03-24 00:18:11 2020-03-24 01:07:11
2 .0 1% | OOII 459f3z9u4fb3u 2020-03-24 02:01:46 2020-03-24 06:19:24
2 .0 1% | OOII 92ankrmctj94q 2020-03-24 03:56:46 2020-03-24 08:42:10
2 .0 1% | OOII 9ahamm7dx5waa 2020-03-24 03:26:29 2020-03-24 08:01:57
2 .0 1% | OOII cna1abuq78rgp 2020-03-24 01:16:40 2020-03-24 06:05:53
2 .0 1% | OOII cpd0s0hbuyuny 2020-03-24 00:13:59 2020-03-24 06:27:00
2 .0 1% | OOII dv7gfycy7kp3z 2020-03-24 08:04:57 2020-03-24 08:47:14
2 .0 1% | OOII g7yzjptxk6z2k 2020-03-24 05:57:08 2020-03-24 08:40:54
1 .0 0% | OOII 015zuc7252hrq 2020-03-24 06:05:53 2020-03-24 06:05:53
1 .0 0% | OOII 0dv541sxka1hr 2020-03-24 03:16:18 2020-03-24 03:16:18
1 .0 0% | OOII 1mdgqv5wjukuy 2020-03-24 01:28:45 2020-03-24 01:28:45
1 .0 0% | OOII 2qj0yfqgfh1as 2020-03-24 01:53:01 2020-03-24 01:53:01
30 rows selected.
--//這樣的程式就是垃圾軟體,失望...
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/267265/viewspace-2682164/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- SQL語句的優化SQL優化
- SQL語句優化SQL優化
- [20200320]SQL語句優化的困惑.txtSQL優化
- SQL Server優化之SQL語句優化SQLServer優化
- SQL 語句的優化方法SQL優化
- MYSQL SQL語句優化MySql優化
- sql語句效能優化SQL優化
- 求助:SQL語句優化SQL優化
- 優化 SQL 語句的步驟優化SQL
- 一個SQL語句的優化SQL優化
- 關於sql語句的優化SQL優化
- 一條sql語句的優化SQL優化
- sql語句的優化案例分析SQL優化
- MySQL之SQL語句優化MySql優化
- SQL語句優化(轉載)SQL優化
- 常用SQL語句優化技巧SQL優化
- Oracle之sql語句優化OracleSQL優化
- 通過分析SQL語句的執行計劃優化SQL語句SQL優化
- 對sql語句的優化問題SQL優化
- 優化SQL 語句 in 和not in 的替代方案優化SQL
- Oracle SQL語句優化之UNIONOracleSQL優化
- SQL語句操作符優化SQL優化
- SQL語句優化技術分析SQL優化
- SQL語句優化方法30例SQL優化
- 一條SQL語句的優化過程SQL優化
- 一次sql語句優化的反思SQL優化
- [zt] 基於索引的SQL語句優化索引SQL優化
- 資料庫效能優化之SQL語句優化資料庫優化SQL
- 淺談mysql配置優化和sql語句優化MySql優化
- SQL優化案例-單表分頁語句的優化(八)SQL優化
- oracle效能問題:sql語句優化OracleSQL優化
- SQL語句優化方法30例(轉)SQL優化
- SQL語句優化--十條經驗SQL優化
- ORACLE SQL語句優化技術分析OracleSQL優化
- 通過SQL PROFILE自動優化SQL語句SQL優化
- SQL Server SQL語句進行優化的基本原則SQLServer優化
- Sql語句本身的優化-定位慢查詢SQL優化
- SQL語句優化的原則與方法QOSQL優化