資料庫減少最佳方法

『壹』 怎樣減少oracle資料庫

其實每個項目需求不一樣，肯定處理方法不一樣。
你說IO/cpu/內存這些，其實屬於資料庫調優的部分，最簡單的辦法就是找瓶頸。
哪方面是瓶頸，就優化哪方面，就像木桶一樣，盡量把最短的板子拉長。

因為資料庫本身不可能做到絕對完美，只能說在當前需求，當前資源的情況下盡量做到最好。
要真說精髓，那就是隨機應變吧。

多注意Top 5 events ， 盡量消除等待事件，降低物理讀，降低硬解析等等。。

『貳』 SQL 2008的資料庫文件太大，如何減小啊

收縮資料庫

一般情況下，SQL資料庫的收縮並不能很大程度上減小資料庫大小，其主要作用是收縮日誌大小，應當定期進行此操作以免資料庫日誌過大
1、設置資料庫模式為簡單模式：打開SQL企業管理器，在控制台根目錄中依次點開Microsoft SQL Server-->SQL Server組-->雙擊打開你的伺服器-->雙擊打開資料庫目錄-->選擇你的資料庫名稱（如論壇資料庫Forum）-->然後點擊右鍵選擇屬性-->選擇選項-->在故障還原的模式中選擇「簡單」，然後按確定保存
2、在當前資料庫上點右鍵，看所有任務中的收縮資料庫，一般裡面的默認設置不用調整，直接點確定
3、收縮資料庫完成後，建議將您的資料庫屬性重新設置為標准模式，操作方法同第一點，因為日誌在一些異常情況下往往是恢復資料庫的重要依據

『叄』 wordpress 怎樣減少資料庫讀取量

#1，若您的WordPress版本為2.3及以前，可採用如下方法令系統自動緩存內部調用函數，而完全不用擔心緩存對系統交互性的影響（如延遲等）。
Step1：在WordPress安裝目錄下的wp-content文件夾下創建名為cache的目錄，屬性設置為755，如下圖：

Step2：打開WordPress安裝根目錄下的wp-config.php文件，在其尾端加入define('ENABLE_CACHE', true);，如下圖：

保存後上傳更新文件，刷新頁面後，可發現新創建的cache文件夾中生成了如下文件：

緩存的是一些不需要經常修改的文件，如分類名稱、存檔日期等。該緩存方法名為object緩存，並不緩存網頁，而傳統的wp-cache調用是緩存網頁的，會影響網頁的交互實時性，使用戶體驗些許變差。

#2，若您的WordPress版本為2.5及以上版本，由於新版WP取消了object緩存功能可以使用將所有待查數據都存入資料庫options表（一般的默認名稱為wp_options）的方法，大幅度減少資料庫查詢次數。ThinkAgain的解釋如下：
默認WP有10個數據表，wp_posts和comments主要存儲文章內容和評論，
其它的幾個包括term等存儲了目錄和標簽等等。這里不細談。wp_options用來存儲Wordpress以及插件運行時所涉及的配置等。且WP會在
運行時自動讀取該表的內容。換句話說，因為WP已經預讀這部分內容，所以直接調用wp_options內的數據是不會產生資料庫查詢的。（http://www.thinkagain.cn/archives/969.html）
方法：假如要緩存的是分類名稱調用表單，則寫functions.php如下代碼：
function cache_category(){
$cached = get_option('multicolor_cache_category');
if($cached){
echo $cached;
}else{
$cached = cache_collapsible_list_cats();
echo "Update cache";
echo $cached;
}
}
add_action('publish_post', 'cache_collapsible_list_cats');
當然，這顯得很復雜，不過ThinkAgain說，WP2.6也是可以使用object自動緩存功能的，請等待他更新的方法。

#3，由於WordPress的內部永久鏈接調用函數為了追求老版插件的最大兼容性所以較啰嗦，比較耗費查詢次數，可在functions.php寫入如下代碼，大幅度減少查詢次數（均適用）
function revised_permalink($post, $leavename=false) {
$rewritecode = array(
'%year%',
'%monthnum%',
'%day%',
'%hour%',
'%minute%',
'%second%',
$leavename? '' : '%postname%',
'%post_id%',
'%category%',
'%author%',
$leavename? '' : '%pagename%',
);
if ( empty($post->ID) ) return FALSE;
if ( $post->post_type == 'page' )
return get_page_link($post->ID, $leavename);
elseif ($post->post_type == 'attachment')
return get_attachment_link($post->ID);
$permalink = get_option('permalink_structure');
if ( '' != $permalink && !in_array($post->post_status, array('draft', 'pending')) ) {
$unixtime = strtotime($post->post_date);
$category = '';
if ( strpos($permalink, '%category%') !== false ) {
$cats = get_the_category($post->ID);
if ( $cats )
usort($cats, '_usort_terms_by_ID'); // order by ID
$category = $cats[0]->slug;
if ( $parent=$cats[0]->parent )
$category = get_category_parents($parent, FALSE, '/', TRUE) . $category;
// show default category in permalinks, without
// having to assign it explicitly
if ( empty($category) ) {
$default_category = get_category( get_option( 'default_category' ) );
$category = is_wp_error( $default_category ) ? '' : $default_category->slug;
}
}
$author = '';
if ( strpos($permalink, '%author%') !== false ) {
$authordata = get_userdata($post->post_author);
$author = $authordata->user_nicename;
}
$date = explode(" ",date('Y m d H i s', $unixtime));
$rewritereplace =
array(
$date[0],
$date[1],
$date[2],
$date[3],
$date[4],
$date[5],
$post->post_name,
$post->ID,
$category,
$author,
$post->post_name,
);
$permalink = get_option('home') . str_replace($rewritecode, $rewritereplace, $permalink);
$permalink = user_trailingslashit($permalink, 'single');
return apply_filters('post_link', $permalink, $post);
} else { // if they're not using the fancy permalink option
$permalink = get_option('home') . '/?p=' . $post->ID;
return apply_filters('post_link', $permalink, $post);
}
}
點擊下面的鏈接下載修改好的文件，請解壓後上傳或粘貼到您原來的文件中。此方法文章頁查詢次數至少可降低10。

注意：如果您原來的插件有諸如下面的代碼，並且您的永久鏈接方式為postname而不是postid，請修改
$sql = "SELECT ID, post_title, comment_count,post_date, post_content FROM $tableposts WHERE post_status = 'publish' ";
為
$sql = "SELECT ID, post_name, post_title,
comment_count,post_date, post_content FROM $tableposts WHERE
post_status = 'publish' ";

至此您的資料庫查詢次數將減小為個位數，繁忙時訪問速度提高較顯著，速度應當與直接生成靜態文件時的情況差距不大，但互動性絲毫不減。

『肆』 如何壓縮減少資料庫的大小

直接用acdsee的編輯器模式,點幾保存就可以了,它會跳出一個窗口,問你要不要壓縮,你點壓縮就行了,大小可以自己控制

『伍』 怎樣減少ACCESS資料庫大小

我的下面一些經驗可以為你的問題提供答案。
常規辦法：
1）刪除不必要的數據和無用的ACCESS資料庫對象例如表、查詢、窗體和模塊等；
2）壓縮資料庫
ACCESS2003壓縮舉例：打開資料庫，點擊菜單（工具）——資料庫實用工具——壓縮和修復資料庫

非常規辦法：
ACCESS資料庫經過一段時間添加、更改和刪除資料庫對象後會產生很多代碼及資料庫對象碎片和垃圾，對於這些東西常規辦法是無法清除的。這也是為什麼你的ACCESS數據刪除很多數據後，大小不變的原因所在。

怎麼辦呢？可以這樣做：先建立一個同名空白資料庫，放在另一個文件夾下，接著打開該空白資料庫，導入原資料庫全部有用的對象（包括：表、窗體、查詢、模塊、頁、宏，無用的不要導入）

ACCESS2003導入對象舉例：文件——獲取外部數據——導入 ，打開「導入」對話框選擇需要縮小的資料庫後，點擊導入按鈕，打開「導入對象」對話框 選擇全部有用的資料庫對象，例如表、窗體等等後點擊「確定」按鈕 完成導入全部資料庫對象。
經過上述過程後，所有的資料庫垃圾都會被清除掉。再對其進行一次壓縮操作，ACCESS資料庫將會處在理論上最小狀態。

『陸』 伺服器資料庫一般怎樣減少資源消耗

您好！您可以重新考慮數據中心布線措施以提高能源效率。

（1）消除電纜擁塞

電纜擁塞是電纜沒有進行有效管理的常見問題，這可能會造成一系列負面影響。首先，電纜擁塞可能阻止設備上的冷空氣進入，導致硬體過熱並可能發生故障。電纜擁塞還可能阻止熱空氣從機櫃出來進入熱通道，並可能導致熱空氣擴散到冷通道冷卻系統中，從而浪費電能，同時降低了製冷效率。IBM公司調查表明，數據中心布線基礎設施的改進，比如消除電纜擁塞，可以節省15％到40％的能源成本。

（2）採用更小的密度電纜

為了防止機櫃擁塞，增強空氣流動，促進更有效的散熱冷卻，採用到密度較小電纜比採用笨重的電纜更輕、更靈活。

（3）依靠線纜管理器

構建更高能效的香港伺服器的主要因素是：採用水平和垂直電纜管理器，防止氣道堵塞設備，並簡化新設備的安裝和連接，其中包括更好地管理較長的電纜，確定電纜布線路徑，並在移動、添加和更改（MAC）時節省時間。

（4）安裝盲板

通過用盲板填充額外的機櫃空間，以確保熱通道與冷通道分離。其結果消除了熱空氣與冷空氣的混合，提高電能的利用率。

（5）限制機櫃中的設備

在單個機櫃中盡量減少光纖通道設備和盲板的數量，以便限制終端的數量。這樣就可以減少布線，以免阻塞機櫃內和周圍的氣流。

（6）絞合電纜

預端接的導向中繼線確保了卓越的性能，因為它們專門適用於當今最流行的導向器級交換機中的光纖通道交換模塊。其每個接頭應交錯排列，以適應每個埠，消除電纜的鬆弛，防止櫃體堵塞，同時增強氣流。

布線基礎設施在數據中心的設計中起著關鍵作用，但往往被忽視，而通過採取這些措施，數據中心管理人員不僅將為更加節能的數據中心鋪平道路，而且還可能獲得更高的投資回報率以及總擁有成本的改進。

文章來自互聯數據「重新考慮數據中心布線措施以提高能源效率」。

『柒』 sql 2008資料庫文件太大，怎麼樣盡量縮小它的大小呢求高手指教

這個在設計資料庫的時候就要考慮，1.
圖片、附件盡量不要存在資料庫中，可以把圖片、附件放在硬碟上，存圖片、附件的文件路徑。2.保存大文本盡量不要用text、ntext，因為這個兩個都是在資料庫里創建一個文件來保存數據，你後面刪除的數據文件也不會刪除的。我暫時想到的就這么多了，有了再補充。

『捌』 怎樣給訪問量過大的mysql資料庫減壓

單機MySQL資料庫的優化
一、伺服器硬體對MySQL性能的影響

①磁碟尋道能力（磁碟I/O），我們現在上的都是SAS15000轉的硬碟。MySQL每秒鍾都在進行大量、復雜的查詢操作，對磁碟的讀寫量可想而知。
所以，通常認為磁碟I/O是制約MySQL性能的最大因素之一，對於日均訪
問量在100萬PV以上的Discuz!論壇，由於磁碟I/O的制約，MySQL的性能會非常低下！解決這一制約因素可以考慮以下幾種解決方案：
使用RAID1+0磁碟陣列，注意不要嘗試使用RAID-5，MySQL在RAID-5磁碟陣列上的效率不會像你期待的那樣快。
②CPU 對於MySQL應用，推薦使用DELL R710，E5620 @2.40GHz（4 core）* 2 ，我現在比較喜歡DELL R710，也在用其作Linuxakg 虛擬化應用；
③物理內存對於一台使用MySQL的Database Server來說，伺服器內存建議不要小於2GB，推薦使用4GB以上的物理內存，不過內存對於現在的伺服器而言可以說是一個可以忽略的問題，工作中遇到高端伺服器基本上內存都超過了32G。
我們工作中用得比較多的資料庫伺服器是HP DL580G5和DELL R710，穩定性和性能都不錯；特別是DELL R710，我發現許多同行都是採用它作資料庫的伺服器，所以重點推薦下。

二、MySQL的線上安裝我建議採取編譯安裝的方法，這樣性能上有較大提升，伺服器系統我建議用64bit的Centos5.5，源碼包的編譯參數會默
認以Debgu模式生成二進制代碼，而Debug模式給MySQL帶來的性能損失是比較大的，所以當我們編譯准備安裝的產品代碼時，一定不要忘記使用「—
without-debug」參數禁用Debug模式。而如果把—with-mysqld-ldflags和—with-client-ldflags二
個編譯參數設置為—all-static的話，可以告訴編譯器以靜態方式編譯和編譯結果代碼得到最高的性能。使用靜態編譯和使用動態編譯的代碼相比，性能
差距可能會達到5%至10%之多。我參考了簡朝陽先生的編譯參數，特列如下，供大家參考
./configure
–prefix=/usr/local/mysql –without-debug –without-bench
–enable-thread-safe-client –enable-assembler –enable-profiling
–with-mysqld-ldflags=-all-static –with-client-ldflags=-all-static
–with-charset=latin1 –with-extra-charset=utf8,gbk –with-innodb
–with-csv-storage-engine –with-federated-storage-engine
–with-mysqld-user=mysql –without-我是怎麼了ded-server
–with-server-suffix=-community
–with-unix-socket-path=/usr/local/mysql/sock/mysql.sock
三、MySQL自身因素當解決了上述伺服器硬體制約因素後，讓我們看看MySQL自身的優化是如何操作的。對 MySQL自身的優化主要是對其配置文件my.cnf中的各項參數進行優化調整。下面我們介紹一些對性能影響較大的參數。
下面，我們根據以上硬體配置結合一份已經優化好的my.cnf進行說明：
#vim /etc/my.cnf
以下只列出my.cnf文件中[mysqld]段落中的內容，其他段落內容對MySQL運行性能影響甚微，因而姑且忽略。
[mysqld]
port = 3306
serverid = 1
socket = /tmp/mysql.sock
skip-locking
#避免MySQL的外部鎖定，減少出錯幾率增強穩定性。
skip-name-resolve
#禁止MySQL對外部連接進行DNS解析，使用這一選項可以消除MySQL進行DNS解析的時間。但需要注意，如果開啟該選項，則所有遠程主機連接授權都要使用IP地址方式，否則MySQL將無法正常處理連接請求！
back_log = 384

#back_log參數的值指出在MySQL暫時停止響應新請求之前的短時間內多少個請求可以被存在堆棧中。
如果系統在一個短時間內有很多連接，則需要增大該參數的值，該參數值指定到來的TCP/IP連接的偵聽隊列的大小。不同的操作系統在這個隊列大小上有它自
己的限制。 試圖設定back_log高於你的操作系統的限制將是無效的。默認值為50。對於Linux系統推薦設置為小於512的整數。
key_buffer_size = 384M
#key_buffer_size指定用於索引的緩沖區大小，增加它可得到更好的索引處理性能。對於內存在4GB左右的伺服器該參數可設置為256M或384M。注意：該參數值設置的過大反而會是伺服器整體效率降低！
max_allowed_packet = 4M
thread_stack = 256K
table_cache = 614K
sort_buffer_size = 6M
#查詢排序時所能使用的緩沖區大小。注意：該參數對應的分配內存是每連接獨占，如果有100個連接，那麼實際分配的總共排序緩沖區大小為100 × 6 ＝ 600MB。所以，對於內存在4GB左右的伺服器推薦設置為6-8M。
read_buffer_size = 4M
#讀查詢操作所能使用的緩沖區大小。和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享。
join_buffer_size = 8M
#聯合查詢操作所能使用的緩沖區大小，和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享。
myisam_sort_buffer_size = 64M
table_cache = 512
thread_cache_size = 64
query_cache_size = 64M

#指定MySQL查詢緩沖區的大小。可以通過在MySQL控制台觀察，如果Qcache_lowmem_prunes的值非常大，則表明經常出現緩沖不
夠
的情況；如果Qcache_hits的值非常大，則表明查詢緩沖使用非常頻繁，如果該值較小反而會影響效率，那麼可以考慮不用查詢緩
沖；Qcache_free_blocks，如果該值非常大，則表明緩沖區中碎片很多。
tmp_table_size = 256M
max_connections = 768
#指定MySQL允許的最大連接進程數。如果在訪問論壇時經常出現Too Many Connections的錯誤提 示，則需要增大該參數值。
max_connect_errors = 1000
wait_timeout = 10
#指定一個請求的最大連接時間，對於4GB左右內存的伺服器可以設置為5-10。
thread_concurrency = 8
#該參數取值為伺服器邏輯CPU數量*2，在本例中，伺服器有2顆物理CPU，而每顆物理CPU又支持H.T超線程，所以實際取值為4*2=8；這個目前也是雙四核主流伺服器配置。
skip-networking
#開啟該選項可以徹底關閉MySQL的TCP/IP連接方式，如果WEB伺服器是以遠程連接的方式訪問MySQL資料庫伺服器則不要開啟該選項！否則將無法正常連接！
table_cache=1024
#物理內存越大，設置就越大。默認為2402,調到512-1024最佳
innodb_additional_mem_pool_size=4M
#默認為2M
innodb_flush_log_at_trx_commit=1
#設置為0就是等到innodb_log_buffer_size列隊滿後再統一儲存，默認為1
innodb_log_buffer_size=2M
#默認為1M
innodb_thread_concurrency=8
#你的伺服器CPU有幾個就設置為幾，建議用默認一般為8
key_buffer_size=256M
#默認為218，調到128最佳
tmp_table_size=64M
#默認為16M，調到64-256最掛
read_buffer_size=4M
#默認為64K
read_rnd_buffer_size=16M
#默認為256K
sort_buffer_size=32M
#默認為256K
thread_cache_size=120
#默認為60
query_cache_size=32M
※值得注意的是：
很多情況需要具體情況具體分析
一、如果Key_reads太大，則應該把my.cnf中Key_buffer_size變大，保持Key_reads/Key_read_requests至少1/100以上，越小越好。
二、如果Qcache_lowmem_prunes很大，就要增加Query_cache_size的值。

很多時候我們發現，通過參數設置進行性能優化所帶來的性能提升，可能並不如許多人想像的那樣產生質的飛躍，除非是之前的設置存在嚴重不合理的情況。我們
不能將性能調優完全依託於通過DBA在資料庫上線後進行的參數調整，而應該在系統設計和開發階段就盡可能減少性能問題。
【51CTO獨家特稿】如果單MySQL的優化始終還是頂不住壓力時，這個時候我們就必須考慮MySQL的高可用架構（很多同學也愛說成是MySQL集群）了，目前可行的方案有：
一、MySQL Cluster
優勢：可用性非常高，性能非常好。每份數據至少可在不同主機存一份拷貝，且冗餘數據拷貝實時同步。但它的維護非常復雜，存在部分Bug，目前還不適合比較核心的線上系統，所以這個我不推薦。
二、DRBD磁碟網路鏡像方案

優勢：軟體功能強大，數據可在底層快設備級別跨物理主機鏡像，且可根據性能和可靠性要求配置不同級別的同步。IO操作保持順序，可滿足資料庫對數據一致
性的苛刻要求。但非分布式文件系統環境無法支持鏡像數據同時可見，性能和可靠性兩者相互矛盾，無法適用於性能和可靠性要求都比較苛刻的環境，維護成本高於
MySQL Replication。另外，DRBD也是官方推薦的可用於MySQL高可用方案之一，所以這個大家可根據實際環境來考慮是否部署。
三、MySQL Replication

在實際應用場景中，MySQL
Replication是使用最為廣泛的一種提高系統擴展性的設計手段。眾多的MySQL使用者通過Replication功能提升系統的擴展性後，通過
簡單的增加價格低廉的硬體設備成倍
甚至成數量級地提高了原有系統的性能，是廣大MySQL中低端使用者非常喜歡的功能之一，也是許多MySQL使用者選擇MySQL最為重要的原因。
比較常規的MySQL Replication架構也有好幾種，這里分別簡單說明下
MySQL Replication架構一：常規復制架構--Master-slaves，是由一個Master復制到一個或多個Salve的架構模式，主要用於讀壓力大的應用資料庫端廉價擴展解決方案，讀寫分離，Master主要負責寫方面的壓力。
MySQL Replication架構二：級聯復制架構，即Master-Slaves-Slaves,這個也是為了防止Slaves的讀壓力過大，而配置一層二級 Slaves，很容易解決Master端因為附屬slave太多而成為瓶勁的風險。
MySQL Replication架構三：Dual Master與級聯復制結合架構，即Master-Master-Slaves，最大的好處是既可以避免主Master的寫操作受到Slave集群的復制帶來的影響，而且保證了主Master的單點故障。
以上就是比較常見的MySQL replication架構方案，大家可根據自己公司的具體環境來設計 ，Mysql 負載均衡可考慮用LVS或Haproxy來做，高可用HA軟體我推薦Heartbeat。

MySQL
Replication的不足：如果Master主機硬體故障無法恢復，則可能造成部分未傳送到slave端的數據丟失。所以大家應該根據自己目前的網路
規劃，選擇自己合理的Mysql架構方案，跟自己的MySQL
DBA和程序員多溝涌，多備份（備份我至少會做到本地和異地雙備份），多測試，數據的事是最大的事，出不得半點差錯

『玖』 什麼是資料庫中的數據冗餘如何消除數據冗餘

數據冗餘指數據之間的重復，也可以說是同一數據存儲在不同數據文件中的現象。可以說增加數據的獨立性和減少數據冗餘為企業范圍信息資源管理和大規模信息系統獲得成功的前提條件。

數據冗餘會妨礙資料庫中數據的完整性(integrality)，也會造成存貯空間的浪費。盡可能地降低數據冗餘度，是資料庫設計的主要目標之一。關系模式的規范化理淪(以下稱NF理論)的主要思想之一就是最小冗餘原則，即規范化的關系模式在某種意義上應該冗餘度最小。

但是，NF理論沒有標準的概念可用，按等價原則，在有或沒有泛關系假設(universal relation assumption)等不同前提下，冗餘的定義可能有好幾種。

數據的應用中為了某種目的採取數據冗餘方式。

1、重復存儲或傳輸數據以防止數據的丟失。

2、對數據進行冗餘性的編碼來防止數據的丟失、錯誤，並提供對錯誤數據進行反變換得到原始數據的功能。

3、為簡化流程所造成額數據冗餘。

4、為加快處理過程而將同一數據在不同地點存放。

5、為方便處理而使同一信息在不同地點有不同的表現形式。

6、大量數據的索引，一般在資料庫中經常使用。

7、方法類的信息冗餘。

8、為了完備性而配備的冗餘數據。

9、規則性的冗餘。根據法律、制度、規則等約束進行的。

10、為達到其他目的所進行的冗餘。