原创 Oracle統計信息(三)—— 動態採樣(動態統計信息)與 多列統計信息

一、 動態採樣 Dynamic Sampling 1. 引入原因 oracle默認認爲where條件中出現的各列彼此是沒有關聯的,以此估算出的基數值可能不準,導致選錯執行計劃。 例如學生表有10000行,要查詢9月出生並且是處女座的人數,

原创 Oracle merge into 爲何只能update不能insert ?

一、 問題描述 開發反饋遇到一個奇怪的問題,使用merge語句時只能update但不能insert,簡化後語句如下 create table tmp0521("id" int,"state" int); merge into tmp0

原创 將global的索引改成分區索引

今天有人在QQ上問,如何將global的索引改成分區索引?由於在同一個列上不能建不同名的索引,不然會報錯: SQL> create index ind_tab2_1 on tab2(a); Index created.   SQL> c

原创 檢查pg中所有分區表

pg 10由於沒有hash分區,而pg_pathman一直都是支持多種分區的。所以如果某些pg 11以前的系統,可能會混合部署pg原生分區和pg_pathman。要檢查這種混合部署環境中的分區情況,可以用下面的sql: select b

原创 影響數據庫性能與穩定性的幾個重要參數

今天談談下面這幾個參數對數據庫性能和穩定性的影響: cursor_sharing:遊標共享 _optim_peek_user_binds:綁定變量窺視 _optimizer_adaptive_cursor_sharing:自適應遊標共享(

原创 NBU 異機恢復Oracle操作步驟

一、 準備工作 1.  DBA 恢復服務器安裝與原庫相同版本的操作系統、數據庫軟件、NBU客戶端 雙向開通到NBU備份服務器的1556、13724、13720、13782、13790端口的防火牆策略(應該只要1556和13724,但爲避免

原创 關於直方圖(histogram)使用的一個特殊案例

有客戶反映,一個選擇性很好的字段(保存完整路徑的文件名)filename,定義爲varchar2(200),字段的前面大部分是相同的(路徑相同),做等值查詢時(where filename='xxxxxxxx'),沒有使用索引,而是使用了

原创 Oracle 使用coe_xfr_sql_profile.sql遷移執行計劃

前面 Oracle 如何不改變SQL爲其綁定構造的執行計劃 介紹了不改變sql語句而替換其執行計劃的方法,但有一個問題是裏面的方法都需要執行計劃和目標sql在庫中cache或AWR中存在,否則無法使用。   一、 問題背景 來看這樣一個場

原创 警惕Oracle數據庫性能“隱形殺手”——Direct Path Read

一、 簡介 Oracle 的11g版本正式發佈到今天已經10年有餘,最新版本也已經到了20c,但是Direct Path Read(直接路徑讀)導致性能問題的案例仍時有發生,很多12c的用戶還是經常遇到這個問題,所以有必要把這個事情再跟大

原创 OS Watcher (OSW) 安裝、啓動及開機自啓動配置

根據操作系統版本分爲兩種,Linux 6之前、Linux 6及之後。 一、 Linux 6之前的OSW 1. 下載地址 文檔 ID 301137.1(目前已不再提供下載)。可以網上搜,或者從其他安裝了osw的服務器打包oswbb目錄,到目

原创 Local index or Global index?

某物流客戶系統查詢快遞單的SQL,IO消耗爲TOP 1: SQL如下: select id,op_code, to_char(create_time, :"SYS_B_1") as create_time,... from T_EXP_

原创 必須通過改寫SQL才能提升性能的一些情況

這篇文章介紹了一些需要通過改寫才能提高性能的SQL寫法,也是對本人以前公衆號改寫相關文章的一個總結(也有新內容)。同時也對網絡上流傳的一些不太準確的說法給予糾正。改寫的首要任務是等價,其次纔是性能的提高,不等價的改寫危害更大。希望能對大家

原创 根因分析-oracle數據庫突發性能問題,誰來背這個鍋

數據庫突發性能問題,有時可能通過重啓應用、重新收集統計信息、重啓數據庫等方法得到臨時解決,但是,如何把故障根本原因找到,避免故障再次發生,是問題得到完美閉環的一個關鍵步驟(當然,能夠快速恢復業務也是非常關鍵的一環)。這也是很多對業務穩定性

原创 oracle 索引無法被使用的N種情況以及應對方法

有時我們創建了字段上的索引,但是通過執行計劃卻發現索引並沒有被使用,還是會使用全表掃描。隨着表上數據量的增長,性能會越來越差。如果不能查明原因,就只能盲目的靠不斷擴容硬件來緩解(不是解決)這類問題,投資巨大,收益甚微。有時實在沒辦法,只能

原创 oracle 快速判斷表是否有數據 / 超過n行數據

一、 問題背景 業務反饋需要做一個判斷,如果表中b='xxx'的行數>=1000,則採用邏輯A,否則採用邏輯B。代碼的語句直接是 select count(*) from tab where b=:b -- 執行約7s 但是tab表是個