項目測評DIA：專注Defi生態(tài)領域的預言機系統(tǒng)

下面我對這個項目做個評測，讓大家可以對DIA有個全面認識。

創(chuàng)新互聯(lián)2013年開創(chuàng)至今，是專業(yè)互聯(lián)網(wǎng)技術服務公司，擁有項目成都網(wǎng)站制作、成都網(wǎng)站建設網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元射洪做網(wǎng)站,已為上家服務,為射洪各地企業(yè)和個人服務,聯(lián)系電話:18980820575

一、立項分析（A）

區(qū)塊鏈可以通過智能合約安全透明的進行鏈上交互。但區(qū)塊鏈不是脫離現(xiàn)實的烏托邦，區(qū)塊鏈終究需要和現(xiàn)實世界的數(shù)據(jù)進行交互。

區(qū)塊鏈上的許多場景下，智能合約應用都必須要獲取鏈外信息源，進行鏈內外數(shù)據(jù)交互，才能觸發(fā)其邏輯判斷。例如，區(qū)塊鏈上的去中心化交易市場系統(tǒng)、去中心化的保險系統(tǒng)、各種預測市場系統(tǒng)、航班晚點的即時賠償系統(tǒng)等等，都需要及時獲取鏈外實時真實數(shù)據(jù)以觸發(fā)執(zhí)行智能合約。智能合約無法自行訪問鏈下數(shù)據(jù)，所以引用來自外部的某個數(shù)據(jù)源。

我們把鏈上（區(qū)塊鏈）與鏈下（現(xiàn)實世界）中的信息橋梁稱之為預言機（Oracles），通過預言機能夠把信息從鏈下傳遞到鏈上，傳遞現(xiàn)實世界的信息并與區(qū)塊鏈進行交互。

如果沒有預言機，那么將無法實現(xiàn)信息的傳遞，將無法實現(xiàn)區(qū)塊鏈與現(xiàn)實世界的大規(guī)模結合和應用，阻礙了區(qū)塊鏈落地。預言機是區(qū)塊鏈領域必不可少的中間件，是大量區(qū)塊鏈智能合約連接到現(xiàn)實世界的數(shù)據(jù)的“中介”，未來將有百億美元的空間。

近年來大火的DeFI同樣需要安全的中間軟件才能連接到鏈上和鏈下數(shù)據(jù)。由于整個分布式生態(tài)系統(tǒng)依賴于預言機（Oracle)，并且其對數(shù)據(jù)的需求呈指數(shù)級增長，因此整個應用程序都面臨預言機漏洞。

目前市場上份額最多和市值最高的預言機項目是 Chainlink，一度沖進了市值前十，LINK的去中心化主要依靠代幣經(jīng)濟激勵和信譽體系建立良性循環(huán)的生態(tài)系統(tǒng)，預言機的觸發(fā)需要通過轉賬來實現(xiàn)，缺點在于所有投票都走鏈上導致 Gas 費用較高。

除了 Chainlink 以外，傳統(tǒng)去中心化預言機項目還有 DOS、Tellor 和 Band 等，其技術邏輯大同小異，大多是走鏈下收集數(shù)據(jù)，鏈上驗證的路徑。這類預言機的核心問題是驗證依賴第三方，抗攻擊性較弱。前段時間，一家叫做Zeus Capital的公司發(fā)布了一篇長達60頁的Chainlink做空報告，指出LINK節(jié)點存在中心化、不透明，代幣的經(jīng)濟模型存在問題等。

當前市場上主要預言機產(chǎn)品在很大程度上不透明、不統(tǒng)一、不準確且難以擴展等問題，這與DeFI所代表的安全、透明等價值不相適應。一款真正適應DeFI領域能夠為去中心化金融提供數(shù)據(jù)支撐的預言機項目迫在眉睫。

二、技術特點（BBB）

今天介紹的DIA正是能夠解決現(xiàn)有預言機問題的項目。DIA的官網(wǎng)是這樣介紹的：金融智能合約生態(tài)系統(tǒng)中開放金融數(shù)據(jù)的生態(tài)系統(tǒng)。

DIA的目標是讓數(shù)據(jù)分析師，數(shù)據(jù)提供者和數(shù)據(jù)用戶一起使用平臺的功能。DIA在各種來源的鏈下數(shù)據(jù)與鏈上智能合約之間建立了可靠且可驗證的橋梁，可用于構建各種金融dApp。簡單理解就是DIA是專門為DeFi生態(tài)領域打造的預言機系統(tǒng)。

預言機的模式比較簡單，核心有兩方面，一方面是如何去中心化的對獲取數(shù)據(jù)的真實度進行博弈，另一方面是對提交優(yōu)質數(shù)據(jù)的用戶提供激勵。

前面說過現(xiàn)在的預言機龍頭Chainlink，Chainlink 預言機是通過在鏈上合約與鏈下分布式節(jié)點之間進行工單分配協(xié)作，通過獎懲機制、聲譽合約和聚合模型（聚合多數(shù)據(jù)源的數(shù)據(jù)）的方式，進行數(shù)據(jù)的請求和反饋。但是這種方式得到的數(shù)據(jù)沒有很強的安全背書，核心是因為如果出現(xiàn)上傳者合謀作惡，那么受到懲罰將會是有一定延遲的，并且數(shù)據(jù)已經(jīng)投入使用，一切都晚了。

而DIA系統(tǒng)的運行步驟是這樣的：

1、數(shù)據(jù)收集機制直接從交易所API和公共來源等各種來源獲取收集數(shù)據(jù)。

2、數(shù)據(jù)host在DIA服務器上，在鏈上哈希加密。方法源代碼和scraper代碼都記錄在Github上。推送可通過API和預言機獲得。多方博弈設定強獎懲制度，從而使價格是在鏈上形成的，已經(jīng)是礦工們通過博弈生成的事實。數(shù)據(jù)庫層可以靈活地處理各種不同類型的數(shù)據(jù)流，從高頻交易api到高性能鍵值存儲中永不更改和可訪問的數(shù)據(jù)。

3、分布式金融協(xié)議和指數(shù)供應方及他方可以直接接入數(shù)據(jù)流,使用DIA的restapi和Oracle系統(tǒng)來分發(fā)收集和聚合的數(shù)據(jù)。

DIA 的工作原理主要包括數(shù)據(jù)請求、數(shù)據(jù)提交、驗證、數(shù)據(jù)存儲和通過 Oracle 或 API 訪問數(shù)據(jù)這五個方面。應用了這種模式的 DIA預言機具備更好的去中心化程度、更真實的數(shù)據(jù)、更強的穩(wěn)定性，以及更高的攻擊成本。

像MakerDao，Synthetix，Ampleforth之類的DeFI平臺特別容易受到預言機漏洞的攻擊。由于這些平臺被設想為可滿足各種金融需求的自主金融協(xié)議，因此它們嚴重依賴透明，準確的價格預言。

DIA 的數(shù)據(jù)來源是透明的，每個人都可以公開訪問。市場參與者可以提供、分享和使用金融、數(shù)字資產(chǎn)數(shù)據(jù)，DIA 的使命是實現(xiàn)金融數(shù)據(jù)的民主化。直接通過API或預言機訪問數(shù)據(jù)，將DIA直接連接到計算代理或任何其他分布式金融（分布式）應用程序。

DIA 平臺利用加密貨幣的經(jīng)濟激勵模式來獲取和驗證數(shù)據(jù)。DeFI平臺將遷移到透明且可審核的第三方解決方案，以確保其核心產(chǎn)品的可持續(xù)性。

三、通證經(jīng)濟及Bonding curve(BBB)

在整個運行過程中，DIA作為治理代幣能夠發(fā)揮重要作用。DIA代幣可用于為數(shù)據(jù)收集、數(shù)據(jù)驗證 、對與協(xié)會有關的決定進行投票提供資金，也用于激勵平臺本身的開發(fā)，使分散的社區(qū)能夠自主運行DIA平臺。DIA獨特地滿足了這些需求。

DIA有四方面的作用，激勵、驗證、治理和value增值。

社區(qū)可以通過為數(shù)據(jù)清洗的公共獎勵提供資金、有效算法的開發(fā)、系統(tǒng)漏洞的發(fā)現(xiàn)等獲得獎勵。

DIA目前沒有上線交易所，馬上要開始眾籌。DIA的信息如下：

總發(fā)行量：2億枚

官網(wǎng)：diadata.org

私募：1000萬枚（5%）

公募：3000萬枚（15%）

公募形式：Bonding curve

這里介紹一下什么是Bonding curve，這個參與模式任何人都可以參與“聯(lián)合曲線分配”。聯(lián)合曲線是公開發(fā)售設計的一種創(chuàng)新類型，精心設計的智能合約可以自動創(chuàng)建 DIA 市場，當從合約中購買代幣時，每個代幣的價格都會增加，而在售回時會降低。因此實際上，交易是由轉讓批次中每個代幣的平均價格和市場上代幣的數(shù)量決定的。通過聯(lián)合曲線出售將在 Gnosis 協(xié)議 Mesa DEX 上提供流動性。

開始時間：2020年8月3日歐洲中部時間15點（北京時間21點）；

結束時間：2020年8月18日歐洲中部時間3點（北京時間9點）；

持續(xù)時間：約14天

支持貨幣：ETH，DAI，USDC

初始價格：0.05美元

初始供應：3000萬

受限制的國家：美國，伊朗等

DIA團隊將于歐洲中部時間8月3日星期一下午3點（北京時間晚上9點）發(fā)布DIA兌換頁面。兌換鏈接將在DIA token網(wǎng)站()中發(fā)布。

可以通過IMTOKEN等錢包或MetaMask參與，在相應兌換界面中將ETH與USDT轉換為錨定WETH或USDC，推薦去Balancer DEX兌換DIA。這一步驟相信大家都會，我就不啰嗦了。

四、團隊分析（BB）

通過官網(wǎng)的消息可以查詢到DIA的團隊情況。

1、Michael Weber – Association Chairman 協(xié)會主席

Michael于2014年創(chuàng)立了Bonsum＆Goodcoin，這是一種由區(qū)塊鏈驅動的用戶忠誠度解決方案，是有史以來第一個定性的“ Good”數(shù)字貨幣，該貨幣在2016年成功出售。他是一位加密貨幣資深人士和連續(xù)創(chuàng)業(yè)者，他曾在野村兄弟，瑞士的InsureTech和德國的跨國公司Bertelsmann Michaels擔任投資銀行家，數(shù)據(jù)分析師和衍生品交易員，他的專業(yè)知識使他對德國的金融法律框架和數(shù)字化有了深刻的了解。Michael還是NGO Hostwriter.org的活躍董事會成員和bitEasy的聯(lián)合創(chuàng)始人。

2、Paul Claudius – Association Board 協(xié)會董事

Paul也是一位連續(xù)企業(yè)家和加密貨幣投資者。他在各種戰(zhàn)略事務和國際增長計劃方面擁有超過10年的經(jīng)驗，在歐洲范圍內擴展業(yè)務。在創(chuàng)立DIA之前，他曾是位于柏林的nu3集團歐洲總監(jiān)，將數(shù)百萬個電子商務業(yè)務轉變?yōu)榇怪闭系钠放啤?Paul的職業(yè)生涯開始于紐約的BNP Paribas企業(yè)發(fā)展和美因河畔法蘭克福的AXA私募股權。

保羅是bitEasy的創(chuàng)始人，曾為多家醫(yī)療技術，物聯(lián)網(wǎng)和電子商務初創(chuàng)企業(yè)提供咨詢和投資。

3、Martin Hobler – Association Board 協(xié)會董事

Martin是一位成功的互聯(lián)網(wǎng)企業(yè)家，在營銷，銷售和策略方面擁有多年的專業(yè)知識。Martin此前曾在一級方程式和ATP網(wǎng)球運動中擔任 體育 經(jīng)理，曾與拉科斯特，沃斯坦納和其他國際品牌合作。作為互聯(lián)網(wǎng)先驅，馬丁還幫助建立了柏林移動導航公司Gate 5，該公司后來被成功出售給了諾基亞。

整體來看，DIA團隊的主要成員都長期從業(yè)于區(qū)塊鏈領域，對區(qū)塊鏈技術有著深厚的見解。團隊目前能查到有12名成員，所有成員都在領英上可查，真實性較高。

核心成員更是區(qū)塊鏈領域里的連續(xù)創(chuàng)業(yè)者，還有金融行業(yè)的背景。DIA團隊是一個技術扎實、區(qū)塊鏈和金融行業(yè)資源較豐富的團隊。

五、社區(qū)社群（B）

Dia官網(wǎng)列示的官方用戶社區(qū)渠道主要有telegram、Medium 主頁、和 Twitter。

1.telegram

電報群有3430名支持者，人數(shù)一般，發(fā)言比較積極，主要是針對項目ICO的情況進行討論。

2.Medium

有155個支持者，人數(shù)雖然不多，但最新的發(fā)布內容是7月29日，信息更新比較及時，最新一篇文章主要內容是如何獲得DIA。

3.Twitter

4.Google 趨勢

選取「DIADATA」詞條進行查詢，沒有足夠的搜索量。

預言機在區(qū)塊鏈領域占據(jù)著樞紐的地位。尤其是當前市場上主要預言機產(chǎn)品在很大程度上不透明、不統(tǒng)一、不準確且難以擴展等問題，這與DeFI所代表的安全、透明等價值不相適應。

DIA的目標是讓數(shù)據(jù)分析師，數(shù)據(jù)提供者和數(shù)據(jù)用戶一起使用平臺的功能。DIA在各種來源的鏈下數(shù)據(jù)與鏈上智能合約之間建立了可靠且可驗證的橋梁，可用于構建各種金融dApp。任何旨在提供有關數(shù)字資產(chǎn)或金融市場的準確信息的人都可以從DIA平臺獲取高度可靠的數(shù)據(jù)。DIA核心團隊都是區(qū)塊鏈領域里的連續(xù)創(chuàng)業(yè)者，一個技術扎實、區(qū)塊鏈和金融行業(yè)資源較豐富的團隊。這些都將成為DIADATA的發(fā)展提供巨大的支持。

DIA的解決方案是通過創(chuàng)建分布式 Oracle 網(wǎng)絡來解決這個問題。雖然預言機領域前景很好，但實現(xiàn)難度也較高。DIA還存在宣傳不夠、社區(qū)活躍度較低等問題,有待進一步加強。

問個問題，怎么預測一下，Oracle數(shù)據(jù)庫能承受多少連接數(shù)

你寫個腳本，腳本里主要是一個循環(huán)，循環(huán)里做的事情包括：

1、連接數(shù)據(jù)庫

2、數(shù)據(jù)庫里面sleep一段時間。

然后把循環(huán)的數(shù)量不斷增加。直到報錯。類似不能連接之類的，這個時候就表示不能再連接了。

當然實際情況會比這個連接數(shù)小很多。因為這個測試的連接畢竟沒有做什么事情。

但是可以在此過程中，測試一下cpu的利用以及內存的利用。

ORACLE使用expdp導出庫時，預估的大小和實際導出的大小相差很大是什么原因？

你有大量的空BLOCKS所致，數(shù)據(jù)庫無數(shù)據(jù)。

expdp有壓縮模式、不壓縮模式兩種：

不壓縮模式就是數(shù)據(jù)有多少，文件就有多大，速度快，這是以空間換時間。

壓縮模式導出文件會比不壓縮模式小1/3～2/3，但是導出速度會慢些，這是以時間換空間。

如何進行大數(shù)據(jù)分析及處理？

大數(shù)據(jù)的分析從所周知，大數(shù)據(jù)已經(jīng)不簡簡單單是數(shù)據(jù)大的事實了，而最重要的現(xiàn)實是對大數(shù)據(jù)進行分析，只有通過分析才能獲取很多智能的，深入的，有價值的信息。那么越來越多的應用涉及到大數(shù)據(jù)，而這些大數(shù)據(jù)的屬性，包括數(shù)量，速度，多樣性等等都是呈現(xiàn)了大數(shù)據(jù)不斷增長的復雜性，所以大數(shù)據(jù)的分析方法在大數(shù)據(jù)領域就顯得尤為重要，可以說是決定最終信息是否有價值的決定性因素?；谌绱说恼J識，大數(shù)據(jù)分析普遍存在的方法理論有哪些呢？1. 可視化分析。大數(shù)據(jù)分析的使用者有大數(shù)據(jù)分析專家，同時還有普通用戶，但是他們二者對于大數(shù)據(jù)分析最基本的要求就是可視化分析，因為可視化分析能夠直觀的呈現(xiàn)大數(shù)據(jù)特點，同時能夠非常容易被讀者所接受，就如同看圖說話一樣簡單明了。2. 數(shù)據(jù)挖掘算法。大數(shù)據(jù)分析的理論核心就是數(shù)據(jù)挖掘算法，各種數(shù)據(jù)挖掘的算法基于不同的數(shù)據(jù)類型和格式才能更加科學的呈現(xiàn)出數(shù)據(jù)本身具備的特點，也正是因為這些被全世界統(tǒng)計學家所公認的各種統(tǒng)計方法（可以稱之為真理）才能深入數(shù)據(jù)內部，挖掘出公認的價值。另外一個方面也是因為有這些數(shù)據(jù)挖掘的算法才能更快速的處理大數(shù)據(jù)，如果一個算法得花上好幾年才能得出結論，那大數(shù)據(jù)的價值也就無從說起了。3. 預測性分析。大數(shù)據(jù)分析最終要的應用領域之一就是預測性分析，從大數(shù)據(jù)中挖掘出特點，通過科學的建立模型，之后便可以通過模型帶入新的數(shù)據(jù)，從而預測未來的數(shù)據(jù)。4. 語義引擎。非結構化數(shù)據(jù)的多元化給數(shù)據(jù)分析帶來新的挑戰(zhàn)，我們需要一套工具系統(tǒng)的去分析，提煉數(shù)據(jù)。語義引擎需要設計到有足夠的人工智能以足以從數(shù)據(jù)中主動地提取信息。5.數(shù)據(jù)質量和數(shù)據(jù)管理。大數(shù)據(jù)分析離不開數(shù)據(jù)質量和數(shù)據(jù)管理，高質量的數(shù)據(jù)和有效的數(shù)據(jù)管理，無論是在學術研究還是在商業(yè)應用領域，都能夠保證分析結果的真實和有價值。大數(shù)據(jù)分析的基礎就是以上五個方面，當然更加深入大數(shù)據(jù)分析的話，還有很多很多更加有特點的、更加深入的、更加專業(yè)的大數(shù)據(jù)分析方法。大數(shù)據(jù)的技術數(shù)據(jù)采集：ETL工具負責將分布的、異構數(shù)據(jù)源中的數(shù)據(jù)如關系數(shù)據(jù)、平面數(shù)據(jù)文件等抽取到臨時中間層后進行清洗、轉換、集成，最后加載到數(shù)據(jù)倉庫或數(shù)據(jù)集市中，成為聯(lián)機分析處理、數(shù)據(jù)挖掘的基礎。數(shù)據(jù)存?。宏P系數(shù)據(jù)庫、NOSQL、SQL等?；A架構：云存儲、分布式文件存儲等。數(shù)據(jù)處理：自然語言處理(NLP，Natural Language Processing)是研究人與計算機交互的語言問題的一門學科。處理自然語言的關鍵是要讓計算機”理解”自然語言，所以自然語言處理又叫做自然語言理解(NLU，Natural Language Understanding)，也稱為計算語言學(Computational Linguistics。一方面它是語言信息處理的一個分支，另一方面它是人工智能(AI, Artificial Intelligence)的核心課題之一。統(tǒng)計分析：假設檢驗、顯著性檢驗、差異分析、相關分析、T檢驗、方差分析、卡方分析、偏相關分析、距離分析、回歸分析、簡單回歸分析、多元回歸分析、逐步回歸、回歸預測與殘差分析、嶺回歸、logistic回歸分析、曲線估計、因子分析、聚類分析、主成分分析、因子分析、快速聚類法與聚類法、判別分析、對應分析、多元對應分析（最優(yōu)尺度分析）、bootstrap技術等等。數(shù)據(jù)挖掘：分類（Classification）、估計（Estimation）、預測（Prediction）、相關性分組或關聯(lián)規(guī)則（Affinity grouping or association rules）、聚類（Clustering）、描述和可視化、Description and Visualization）、復雜數(shù)據(jù)類型挖掘(Text, Web ,圖形圖像，視頻，音頻等)模型預測：預測模型、機器學習、建模仿真。結果呈現(xiàn)：云計算、標簽云、關系圖等。大數(shù)據(jù)的處理1. 大數(shù)據(jù)處理之一：采集大數(shù)據(jù)的采集是指利用多個數(shù)據(jù)庫來接收發(fā)自客戶端（Web、App或者傳感器形式等）的數(shù)據(jù)，并且用戶可以通過這些數(shù)據(jù)庫來進行簡單的查詢和處理工作。比如，電商會使用傳統(tǒng)的關系型數(shù)據(jù)庫MySQL和Oracle等來存儲每一筆事務數(shù)據(jù)，除此之外，Redis和MongoDB這樣的NoSQL數(shù)據(jù)庫也常用于數(shù)據(jù)的采集。在大數(shù)據(jù)的采集過程中，其主要特點和挑戰(zhàn)是并發(fā)數(shù)高，因為同時有可能會有成千上萬的用戶來進行訪問和操作，比如火車票售票網(wǎng)站和淘寶，它們并發(fā)的訪問量在峰值時達到上百萬，所以需要在采集端部署大量數(shù)據(jù)庫才能支撐。并且如何在這些數(shù)據(jù)庫之間進行負載均衡和分片的確是需要深入的思考和設計。2. 大數(shù)據(jù)處理之二：導入/預處理雖然采集端本身會有很多數(shù)據(jù)庫，但是如果要對這些海量數(shù)據(jù)進行有效的分析，還是應該將這些來自前端的數(shù)據(jù)導入到一個集中的大型分布式數(shù)據(jù)庫，或者分布式存儲集群，并且可以在導入基礎上做一些簡單的清洗和預處理工作。也有一些用戶會在導入時使用來自Twitter的Storm來對數(shù)據(jù)進行流式計算，來滿足部分業(yè)務的實時計算需求。導入與預處理過程的特點和挑戰(zhàn)主要是導入的數(shù)據(jù)量大，每秒鐘的導入量經(jīng)常會達到百兆，甚至千兆級別。3. 大數(shù)據(jù)處理之三：統(tǒng)計/分析統(tǒng)計與分析主要利用分布式數(shù)據(jù)庫，或者分布式計算集群來對存儲于其內的海量數(shù)據(jù)進行普通的分析和分類匯總等，以滿足大多數(shù)常見的分析需求，在這方面，一些實時性需求會用到EMC的GreenPlum、Oracle的Exadata，以及基于MySQL的列式存儲Infobright等，而一些批處理，或者基于半結構化數(shù)據(jù)的需求可以使用Hadoop。統(tǒng)計與分析這部分的主要特點和挑戰(zhàn)是分析涉及的數(shù)據(jù)量大，其對系統(tǒng)資源，特別是I/O會有極大的占用。4. 大數(shù)據(jù)處理之四：挖掘與前面統(tǒng)計和分析過程不同的是，數(shù)據(jù)挖掘一般沒有什么預先設定好的主題，主要是在現(xiàn)有數(shù)據(jù)上面進行基于各種算法的計算，從而起到預測（Predict）的效果，從而實現(xiàn)一些高級別數(shù)據(jù)分析的需求。比較典型算法有用于聚類的Kmeans、用于統(tǒng)計學習的SVM和用于分類的NaiveBayes，主要使用的工具有Hadoop的Mahout等。該過程的特點和挑戰(zhàn)主要是用于挖掘的算法很復雜，并且計算涉及的數(shù)據(jù)量和計算量都很大，常用數(shù)據(jù)挖掘算法都以單線程為主。整個大數(shù)據(jù)處理的普遍流程至少應該滿足這四個方面的步驟，才能算得上是一個比較完整的大數(shù)據(jù)處理。End.

如何提高Oracle數(shù)據(jù)庫數(shù)據(jù)查詢的命中率

影響命中率的因素有四種：字典表活動、臨時段活動、回滾段活動、表掃描， 應用DBA可以對這四種因素進行分析，找出數(shù)據(jù)庫命中率低的癥結所在。 1)字典表活動 當一個SQL語句第一次到達Oracle內核時數(shù)據(jù)庫對SQL語句進行分析，包含在查詢中的數(shù)據(jù)字典對象被分解，產(chǎn)生SQL執(zhí)行路徑。如果SQL語句指向一個不在SGA中的對象?表或視圖，Oracle執(zhí)行SQL語句到數(shù)據(jù)典中查詢有關對象的信息。數(shù)據(jù)塊從數(shù)據(jù)字典表被讀取到SGA的數(shù)據(jù)緩存中。由于每個數(shù)據(jù)字典都很小，因此，我們可緩存這些表以提高對這些表的命中率。但是由于數(shù)據(jù)字典表的數(shù)據(jù)塊在SGA中占據(jù)空間，當增加全部的命中率時，它們會降低表數(shù)據(jù)塊的可用空間， 所以若查詢所需的時間字典信息已經(jīng)在SGA緩存中，那么就沒有必要遞歸調用。 2)臨時段的活動 當用戶執(zhí)行一個需要排序的查詢時，Oracle設法對內存中排序區(qū)內的所有行進行排序，排序區(qū)的大小由數(shù)據(jù)庫的init.ora文件的數(shù)確定。如果排序區(qū)域不夠大，數(shù)據(jù)庫就會在排序操作期間開辟臨時段。臨時段會人為地降低OLTP(online transaction processing）應用命中率,也會降低查詢進行排序的性能。如果能在內存中完成全部排序操作，就可以消除向臨時段寫數(shù)據(jù)的開銷。所以應將SORT_AREA_SIZE設置得足夠大，以避免對臨時段的需要。這個參數(shù)的具體調整方法是:查詢相關數(shù)據(jù)，以確定這個參數(shù)的調整。 select * from v$sysstat where name='sorts(disk)'or name='sorts(memory); 大部分排序是在內存中進行的，但還有小部分發(fā)生在臨時段， 需要調整 值，查看init.ora文件的 SORT_AREA_SIZE值，參數(shù)為：SORT_AREA_SIZE＝65536;將其調整到SORT_AREA_SIZE＝131072、這個值調整后，重啟ORACLE數(shù)據(jù)庫即可生效。 3)回滾段的活動 回滾段活動分為回滾活動和回滾段頭活動。對回滾段頭塊的訪問會降低應用的命中率， 對OLTP系統(tǒng)命中率的影響最大。為確認是否因為回滾段影響了命中率，可以查看監(jiān)控輸出報表中的“數(shù)據(jù)塊相容性讀一重寫記錄應用” 的統(tǒng)計值，這些統(tǒng)計值是用來確定用戶從回滾段中訪問數(shù)據(jù)的發(fā)生次數(shù)。 4)表掃描 通過大掃描讀得的塊在數(shù)據(jù)塊緩存中不會保持很長時間， 因此表掃描會降低命中率。為了避免不必要的全表掃描，首先是根據(jù)需要建立索引，合理的索引設計要建立人對各種查詢的分析和預測上，筆者會在SQL優(yōu)化中詳細談及；其次是將經(jīng)常用到的表放在內存中，以降低磁盤讀寫次數(shù)。

Oracle表空間容量評估

1.?推薦一個使用平均值估算表空間的腳本：

--不適用windows

with t1 as (

select ss.run_time,ts.name,

decode((round(su.tablespace_usedsize*dt.block_size/1024/1024,2)),null,0,(round(su.tablespace_usedsize*dt.block_size/1024/1024,2))) used_size_mb

from

dba_hist_tbspc_space_usage su,

(select trunc(BEGIN_INTERVAL_TIME) run_time,max(snap_id) snap_id from dba_hist_snapshot

group by trunc(BEGIN_INTERVAL_TIME) ) ss,

v$tablespace ts,

dba_tablespaces dt

where su.snap_id = ss.snap_id

and su.tablespace_id = ts.ts#

and ts.name NOT LIKE '%TEMP%'

and ts.name NOT LIKE '%UNDO%'

and ts.name = dt.tablespace_name order by 2,1),

t2 as (

select e.run_time,e.name,e.used_size_mb,e.used_size_mb - b.used_size_mb growth

from t1 e, t1 b

where e.name = b.name and e.run_time = b.run_time +1),

t5 as (select a.TABLESPACE_NAME,

? ? ? ? a.FILE_NAME,

? ? ? ? a.FILE_ID,

? ? ? ? a.BYTES,

? ? ? ? a.AUTOEXTENSIBLE,

? ? ? ? a.ONLINE_STATUS,

? ? ? ? a.MAXBYTES,

? ? ? ? case

? ? ? ? ? when a.AUTOEXTENSIBLE = 'YES' and

? ? ? ? ? ? ? ? a.ONLINE_STATUS not in ('OFFLINE', 'SYSOFF') then

? ? ? ? ? ? nvl(a.MAXBYTES, 0)

? ? ? ? ? else

? ? ? ? ? ? nvl(a.BYTES, 0)

? ? ? ? end file_max_size

? ? from dba_data_files a

? ? where a.tablespace_name NOT LIKE '%TEMP%'

? ? and a.tablespace_name NOT LIKE '%UNDO%'

? ? ),

t3 as (

select tsz.tablespace_name,

tsz.alloc_size_mb,ave.avg_growth_per_day_mb,ave.avg_growth_per_day_mb*90 projected_growth_for_3mths_mb

from

(select tablespace_name, round(sum(file_max_size)/1024/1024,2) alloc_size_mb? from t5 group by tablespace_name) tsz,

(select name,decode(round(avg(growth),2),null,0.11,0,0.11, round(avg(growth),2)) avg_growth_per_day_mb from t2 group by name) ave

where tsz.tablespace_name = ave.name),

t6 as (select

d.tablespace_name tablespace_name,

round((d.sumbytes/1024/1024),2) total_g ,

round(decode(f.sumbytes,null,0,f.sumbytes)/1024/1024,2) free,

round(((d.sumbytes-f.sumbytes)/1024/1024),6) size_could_be_used,

round((d.sumbytes-decode(f.sumbytes,null,0,f.sumbytes))*100/d.sumbytes,2) used_pct,

(100-round((d.sumbytes-decode(f.sumbytes,null,0,f.sumbytes))*100/d.sumbytes,2))*round((d.sumbytes/1024/1024),2) real_free

from

(select

? tablespace_name,? sum(bytes) sumbytes

from dba_free_space? group by tablespace_name) f,

(select tablespace_name,? ? ? sum(bytes) sumbytes? ?

? from dba_data_files? ? group by tablespace_name) d

where f.tablespace_name(+) = d.tablespace_name)

select t4.tablespace_name,decode(t3.alloc_size_mb,null,0,t3.alloc_size_mb) alloc_sz_mb,

--t6.real_free/round(decode(avg_growth_per_day_mb,null,365,0,365,(t3.avg_growth_per_day_mb)),2) Days_To_Be_Used,

((100-decode(round(t6.size_could_be_used*100/t3.alloc_size_mb,2),null,0,round(t6.size_could_be_used*100/t3.alloc_size_mb,2)))/100*t3.alloc_size_mb)/avg_growth_per_day_mb? Days_To_Be_Used,

round(t6.size_could_be_used*100/t3.alloc_size_mb,4) used_pct_auto,

t6.used_pct used_pct_real

from t3,t6,

(select a.tablespace_name,

round(a.bytes/1024/1024/1024,2) alloc,

round(c.bytes/1024/1024/1024,2) free

from sys.sm$ts_avail a,

sys.sm$ts_free c

where a.tablespace_name = c.tablespace_name(+)

and a.tablespace_name NOT LIKE '%TEMP%'

and a.tablespace_name NOT LIKE '%UNDO%'

) t4

where t4.tablespace_name = t3.tablespace_name(+)

and t4.tablespace_name = t6.tablespace_name(+)

--and ((100-decode(round(t6.size_could_be_used*100/t3.alloc_size_mb,2),null,0,round(t6.size_could_be_used*100/t3.alloc_size_mb,2)))/100*t3.alloc_size_mb)/avg_growth_per_day_mb =30

and ((100-decode(round(t6.size_could_be_used*100/t3.alloc_size_mb,2),null,0,round(t6.size_could_be_used*100/t3.alloc_size_mb,2)))/100*t3.alloc_size_mb)/avg_growth_per_day_mb=0

order by 1;

2.?通過線性回歸參數(shù)預測未來使用量（待補充）：