數據庫管理員

MHA 線上切換過程MySQL MHA 線上切換是MHA除了自動監控切換換提供的另外一種方式，多用於諸如硬體升級，MySQL資料庫遷移等等。該方式提供快速切換和優雅的阻塞寫入，無關關閉原有伺服器，整個切換過程在0.5-2s 的時間左右，大大減少了停機時間。本文示範了MHA 線上切換並給出了線上切換的基本步驟。1、MHA線上切換方式及要求    $ masterha_master_switch --master_state=alive --conf=/etc/app1.cnf

MySQL 索引及查詢最佳化索引的類型 :Ø 普通索引　　這是最基本的索引類型，沒唯一性之類的限制。Ø 唯一性索引　和普通索引基本相同，但所有的索引列值保持唯一性。Ø 主鍵索引　　主鍵是一種唯一索引，但必須指定為”PRIMARY KEY”。Ø

MySQL explain 分析查詢簡述：使用 EXPLAIN 或DESC關鍵字可以類比最佳化器執行SQL查詢語句，從而知道MySQL是如何處理你的SQL語句的。這可以幫你分析你的 查詢語句 或是 表結構的效能 瓶頸。通過explain命令可以得到：1、表的讀取順序2、表的讀取操作的操作類型3、哪些索引可以使用4、哪些索引被實際使用5、表之間的引用6、每張表有多少行被最佳化器查詢為什麼要使用explain :explain可以協助我們分析 select

Mydumper - MySQLDatabase Backup工具Mydumper 是 MySQL 資料庫伺服器備份工具，它比 MySQL 內建的 mysqldump 快很多。它還有在轉儲的同時擷取遠程伺服器二進位記錄檔的能力。Mydumper 的優勢並行能力 (因此有高速度) 和效能 (高效的代碼避免了耗費 CPU 處理能力的字元集轉換過程)更容易管理輸出 (每個表都對應獨立的檔案，轉儲中繼資料等，便於查看/解析資料)一致性 ：跨線程維護快照, 提供精確的主從日誌定位等。可管理性 ： 支援用

Redis資料到期策略探究通過EXPIRE key seconds命令來設定資料的到期時間。返回1表明設定成功，返回0表明key不存在或者不能成功設定到期時間。在key上設定了到期時間後key將在指定的秒數後被自動刪除。被指定了到期時間的key在Redis中被稱為是不穩定的。當key被DEL命令刪除或者被SET、GETSET命令重設後與之關聯的到期時間會被清除。redis 127.0.0.1:6379> set mykey "test expire"OKredis 127.0.0.1:63

如何診斷RAC環境下sysdate 返回錯誤時間問題最近處理了一些rac環境下訪問sysdate返回錯誤時間的問題，而這種問題往往出現在資料庫連結是通過Listener建立的情況下，而且，大部分情況下都是和時區設定相關的。在這篇文章中我們會針對如何診斷這種問題進行解釋。這篇文章適用於版本11.2.0.2 及以上版本。首先，對問題當中涉及到的知識進行介紹。1. 從版本11.2.0.2 開始Oracle

MySQL 慢查詢簡述：分析MySQL語句查詢效能的方法除了使用 EXPLAIN 輸出執行計畫，還可以讓MySQL記錄下查詢 超過指定時間的語句，我們將超過指定時間的SQL語句查詢稱為“慢查詢”。它能記錄下所有執行超過 long_query_time時間的SQL語句, 幫你找到執行慢的SQL,  方便我們對這些SQL進行最佳化。在最佳化MySQL時，通常需要對資料庫進行分析，常見的分析手段有 慢查詢日誌，EXPLAIN 分析查詢， profiling分析 以及

一次RAC VIP漂移的結果診斷及修複背景概述客戶的10G資料庫VIP出現宕，引起VIP負載到另一個節點事件支援細節04:29:56.378 一號機器VIP 出現 went OFFLINE unexpectedly，當天出現這個VIP漂移的故障後為檢查VIP宕掉的原因，對VIP資源啟動DEBUG 5模式：./crsctl debug log res "orahostname1.vip:5"04:38:36.047 一號節點VIP 出現 went OFFLINE

ORA-00911錯誤 解決執行個體ORA-00911，"911"看著很霸氣的錯誤號碼，雖然我還是Oracle的初學者，但每次碰到一個未見過的ORA錯誤號碼後，都有一種查案的趕腳，根據錯誤號碼、OERR、相關錯誤資訊，判斷錯誤原因以及找到解決方案或替代方案，雖然大部分可能還是參考前輩或官方，但碰到一次後，至少是似曾相識了，再次碰到時即使不記得，大概也能有個方向。話說回來，這個ORA-00911的錯誤，是在一段用JAVA寫的測試案例中碰到的，...private static final

通過Shell指令碼同時監控多個資料庫負載在平時的工作中，需要管理的資料庫還是很多的，因為遠程和許可權的關係，訪問不了一些圖形工具，有時候做檢查的時候感覺都是一個串列的過程，這樣檢查針對性就不夠強了，比如我們不知道在檢查的這個時間範圍內，資料庫的負載是在什麼範圍內，如果有些庫的負載極高，就需要格外注意，進行更有針對性的分析和檢查，要不假設有20個庫需要同時管理，沒有重點，眉毛鬍子一把抓還是很頭疼的。查看資料庫的負載還是一個不錯的指標，我們可以根據這個基準來同時監控多個資料庫，基本能夠在一個大螢幕

Oracle 11g版本EXPDP 的COMPRESSION參數壓縮比堪比“gzip -9”這個壓縮比例可以和作業系統“gzip -9”相媲美，某些特例下有可能比gzip還要高效。體驗之，供參考。1.Oracle 11g中expdp協助頁中關於COMPRESSION參數的描述secooler@secDB /home/oracle$ expdp -help……COMPRESSIONReduce the size of a dump

Redis主從配置及Sentinel搭建redis作為nosql資料庫主流產品之一，現在被廣泛使用，如何保證redis的高可用和故障自動切換，本文介紹了redis的主從配置方法，及故障切換的sentinel搭建。如下：環境說明：server 系統：CentOS 6.5 X64redis軟體說明：2.8.19版本一：配置主從redis1、架構：主庫：172.16.52.130從庫1：172.16.52.131從庫2：172.16.52.1322、主從操作：tar xvf redis-2.8.19.

Oracle之RMAN資料庫在非歸檔模式下的備份和恢複1.資料庫在非歸檔模式下的備份SQL> archive log list;資料庫記錄模式 非存檔模式自動封存 禁用存檔終點 USE_DB_RECOVERY_FILE_DEST最早的聯機日誌序列 3244當前日誌序列 3246RMAN> run2> {3> allocate channel t1 type disk;4> backup database format

crontab導致的頻繁發送郵件的問題今天下午的時候客戶發郵件反饋說，對於某個環境中的檔案系統監控和資料表空間使用方式的郵件收到的比較頻繁，感覺是1個小時發送一次，完全可以3個小時發送一次，接到這個問題後，最直接的聯想就是使用crontab。 結果登入到伺服器端之後查看，得到的結果如下：> crontab -l # Minute    Hour    Month    Day   

通過Shell指令碼查看資料庫資料表空間使用方式對於資料庫中資料表空間查看，想必大家都有很多的指令碼已經在用了，自己也囉嗦一下，分享一個通過shell指令碼查看錶空間使用方式的例子。 指令碼如下：sqlplus -s $DB_CONN_STR@$SH_DB_SID  <<EOF set echo off heading on underline on; column inst_num  heading "Inst Num" 

Linux下配置MySQL主從複製MySQL的主從複製是自己一直想學習的一個實戰經曆，因為Oracle中的主從複製也是需要不少的配置選項，相比來說感覺重量級一些(資料量也重量級)。今天試了一下，在本地的一台Linux虛擬機器上簡單類比了一把，發現還是蠻有趣的。因為也是外行，所以為了快速達到效果，自己看了一個很早的視頻，結果實際操作的時候，有好幾個配置參數都已經沒有了。看來還是需要靜下心來慢慢做，在Windows上配置了一下，因為各種各樣的原因，就是沒有配置出來，個人還是喜歡Linux環境下弄，今

MySQL字元集GBK轉換到UTF8在生產環境中，MySQL資料庫字元集因為各種原因需要升級，比如為了支援漢字，從latin1字元集升級到GBK，後面為了支援多個語言文字，需要將GBK升級到UTF8等。遷移過程網上有很多，我今天主要想講下字元集轉換後，可能對業務產生的影響，我以GBK轉換到UTF8為例說明。主要有兩點：1.漢字在GBK編碼中佔2個位元組，在UTF8編碼中佔3個位元組，而mysql的索引要求總長度不超過767個位元組，因此索引字元數會被縮短(383->255)，特別的，對於唯

冷備下類比rm -rf *.dbf恢複案例關於備份恢複一直是所有關係型資料庫的重頭戲。下面會介紹冷備資料庫，並類比破壞資料檔案進行恢複資料庫，並涉及到其他相關內容。[Oracle@localhost ~]$ cat /etc/RedHat-releaseRed Hat Enterprise Linux Server release 5.5 (Tikanga)SQL> select * from v$version where rownum<2;BANNER--------------

關於Oracle 11g 審計檔案關於審計：Oracle 11g預設啟用的審計選項，AUDIT_TRAIL參數的預設值為DB，表示審計資料將記錄在資料庫中的SYS.AUD$審計字典基表上。而在Oracle 10g中該參數預設值為none，即不啟用審計。Oracle官方宣稱預設啟用的審計日誌不會對絕大多數產品資料庫的效能帶來過大的負面影響，同時Oracle公司還推薦使用基於OS檔案的審計日誌記錄方式(OS audit trail files)。因為在11g中CREATE

記一次Oracle壞塊修複過程昨天接備份同事電話反應在進行RMAN冷備的過程中報如下錯，某個資料表空間備份失敗。RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: ============================