Time of Update: 2018-12-05
1 定義 用於分析oracle追蹤檔案並且可按需產生一個更加清晰合理的輸出結果的可執行工具 2 喜好設定F:\>tkprofUsage: tkprof tracefile outputfile [explain= ] [table= ] [print= ] [insert= ] [sys= ] [sort= ] table=schema.tablename Use 'schema.tablename' with
Time of Update: 2018-12-05
有人說,沒有索引, 拿什麼來保證約束?姑且不論這話的對錯,但約束的實現(除了not null),很多都是通過索引來快速定位約束的地方。unique約束會自動建立索引,pk也是。也因此,約束的很多問題總是和索引纏綿一起。 相關視圖: dba_constraints dba_cons_columns not null約束比較特別點。not null的索引類型和check約束一樣,都是C。只有not
Time of Update: 2018-12-05
下面3條語句,旨在重新整理oracle的緩衝。這裡總結一下。 1)alter system flush global context 說明: 對於多層架構的,如:應用伺服器和資料區塊伺服器通過串連池進行通訊,對於串連池的這些資訊被保留在SGA中,這條語句便是把這些串連資訊清空。 2)alter system flush shared_pool 將使library cache和data dictionary
Time of Update: 2018-12-05
以Oracle Net看,資料庫伺服器可能也是用戶端 因為tnsnames.ora可以有伺服器的描述 也就是,只有監聽器才會一直是伺服器 執行個體:監聽=n:m ㈠ 雙監聽器的好處: ① 用戶端容錯移轉--CF ② 用戶端負載平衡--CLB
Time of Update: 2018-12-05
雖然本博文旨在引導大家生產環境如何建立分區 但千萬別被一些所謂的設計指南、特別是一些絕對值建議而把自己作繭自縛 生產環境當慎獨! 不過、照葫蘆畫瓢、總比沒葫蘆亂畫一通要強吧 那麼、我們從分區索引和分區表來展開 ㈠ 分區索引的設計指南 ① 如果表分區欄位正好是索引欄位或者其首碼、例如:t表分區欄位是a、 則a正好是索引欄位(a)、或者正好是索引欄位(a,o)的首碼、 則此時應該建立為Local
Time of Update: 2018-12-05
㈠ 直接路徑載入和buffer cache 直接路徑插入的資料不經過buffer cache,從PGA直接把資料格式化成Oracle塊 然後由普通的Oracle Server Process進程把資料區塊寫入資料檔案 因為不經過buffer cache,所以不需要DBWn介入 假如有表a,現要將a中的資料插入表b,在普通的插入下,需先將a的資料區塊I/O到buffer cache
Time of Update: 2018-12-05
在傳統的undo管理員模式中,oracle對undo和data block是一視同仁。這樣大致會有三種弊端: 1)事務開始時,存放事務表的段頭不在記憶體,server process需要將此i/o上來 2)存放舊值的復原塊不在記憶體 3)rollback或者CR讀的時候,所需的復原塊被DBWn寫到磁碟,oracle也需將此i/o,可能會產生大量的consistent gets和physical reads 由此,我們知道,undo會產生redo,又會寫undo
Time of Update: 2018-12-05
分區方案設計和實施是一門追求綜合平衡、充滿辯證統一的哲學、 也是經驗和技術不斷積累的藝術 然而、實際項目中、卻漏洞頻出、導致海量資料頃刻坍塌 ㈠ 目標方面的誤區 ① 問題分析 在很多分區設計方案、其指導思想往往只考慮部分目標 特別是過分在意設計對效能的需求 而對分區在資料生命週期、資料備份恢複、高可用性等方面置若罔聞 ② 正確策略
Time of Update: 2018-12-05
資料存放在資料檔案中,其屬性會隨著儲存而確定,這些屬性包括:在哪個資料檔案?屬於哪個對象?所在的資料區塊?行號? 將這些屬性合并起來就構成了oracle的ROWID。 所以,rowid詳細的記錄了資料在磁碟上的位置。簡單講,也叫行地址。 ROWID可分:物理和邏輯。除了IOT使用邏輯ROWID,其他類型的表使用物理ROWID。 ROWID也可分:受限和擴充。8i之後使用擴充rowid。 下面介紹擴充rowid。 擴充rowid,採用64
Time of Update: 2018-12-05
1 定義 oracle的壞塊可分為物理壞塊和邏輯壞塊。壞塊損壞資訊類似為: ORA-01578: ORACLE data block corrupted (file # 6, block # 11) ORA-01110: data file 6: '/u01/app/oracle/oradata/orcl/tbs01.dbf'
Time of Update: 2018-12-05
體繫結構和備份恢複原理1 oracle database 最重要的是online redo log 類比法 controlfile :公司高管 datafile :生產車間 online redo log:財務處 注釋: system資料表空間是第一生產車間; 當公司高管換了,財務處也需要換;2 shared pool主要包括: library cache:放代碼(sql,pl/sql,java) data dictionary cache:放資料字典
Time of Update: 2018-12-05
動態採樣的統計資訊不會記錄到視圖,有時候分析過的表也會參與評估 對CBO有效,因為RBO不需要統計資訊,所以動態採樣沒意義 ㈠ 動態採樣的作用 ① 10G開始,RBO徹底退出了曆史舞台,CBO依賴的是充分的統計分析資訊 但是並不是每個使用者都會非常認真、及時地去對每個表做分析
Time of Update: 2018-12-05
x$表是資料庫的核心部分,這些表用於追蹤內部資料庫資訊,鑑效組資料庫正常運行。x$表是加密命名的,而且oracle不做文檔說明。oracle通過這些x$表建立起其他大量視圖提供使用者查詢管理資料庫之用。************************************~(@^_^@)~******************************************************
Time of Update: 2018-12-05
感覺cardinality翻譯成基數很不好,誤導科技工程人員! 我覺得最初翻譯這詞的翻譯者就沒有理解它本身的意思,所以字典上就會誤導很多人 基數給人的感覺是集合的全部,比如說我國人口基數大,有13億 而cardinality應該是給集合應用某種條件後的輸出數 比如條件是月收入在一萬以上,那麼如果我國有1000萬人達到,那麼這1000萬就是相對13億cardinality
Time of Update: 2018-12-05
大綱:LSNRCTL> helpThe following operations are availableAn asterisk (*) denotes a modifier or extended command:start stop status services version reload save_config
Time of Update: 2018-12-05
⑴ free 一個常見的問題是: 我的應用程式,伺服器,使用者以及系統進程等正在使用多少記憶體? 或者 現在多少記憶體可用?如果正在啟動並執行進程使用的記憶體大於可用RAM,則需要將這些進程移到交換區 因此,一個補充的問題是: 正在使用多少交換區空間? free命令將回答所有這些問題。
Time of Update: 2018-12-05
㈠ Histograms 柱狀圖?長條圖?其實這倆是一個概念,在這裡Think直接用histograms來稱呼 histograms可以這麼理解就是一個列上數值的大致分布的密度(density)和範圍(range) 通俗一些就是CBO用histgrams來更加準確的判斷按照某個條件對每一列查詢能返回多少記錄 histograms有兩種類型
Time of Update: 2018-12-05
oracle這碗飯不好吃,幾多風險,幾多建議。1 基於時間點的不完全恢複,需要對控制檔案洗腦,撕掉賬本(重做日誌),重新印刷賬本,這是條沒有回頭的路,需要保護現場,為自己留條後路。切記將整個資料庫先進行備份,即便是幾個T。過程如下: 1)shutdown immediate 2)startup mount 3)對整個資料庫進行cp。 4)。。。。。。。。(接下來的步驟大家都懂的,就不嘮叨了) 2 整理rman較合理的初始備份方案
Time of Update: 2018-12-05
㈠ 三大功能 ① 搜集和刪除索引、表和簇的統計資訊 ② 驗證表、索引和簇的結構 ③ 評鑑表和簇和行遷移和行連結 針對analyze的搜集和刪除統計資訊功能而言 Oracle推薦使用DBMS_STATS包來代替analyze搜集最佳化資訊 DBMS_STATS可以並行的搜集資訊,可以搜集分區表的全域資訊 進一步來說,CBO只會使用DBMS_STATS包所統計出來的資訊 ㈡ 先決條件 ①
Time of Update: 2018-12-05
之前也寫過一篇10046的文章:10046簡介 今天,Think想和大家一起共同深入去理解一下Oracle的這些調試事件 10046事件是SQL_TRACE的擴充,被戲稱為"吃了興奮劑的SQL_TRACE" 有效追蹤層級: ① 0級:SQL_TRACE=FASLE ② 1級:SQL_TRACE=TRUE,這是預設層級 ③ 4級:1級+綁定變數 ④ 8級:4級+等待事件