原创 oracle 11.2.0.4 RAC 安全停庫

作爲一名數據庫管理員,難免有一些機器的停機檢修,主機網絡資源的調整,最基本的一個動作就是停庫,一般看來數據庫停庫不就是shutdown ? 非也,要做到數據庫的安全停庫,一系列的操作和檢查是非常有必要的。下文詳細列舉了oracle11g

原创 數據文件壞塊處理

如果數據庫的底層文件出現了壞塊的情況,通過alert日誌觀察是否有大規模的壞塊,以下討論只有個別壞塊的情況,處理思路是:首先定位壞塊的文件,其次定位壞塊的對象,將改文件上沒有壞塊的對象挪走,避免大規模故障,最後根據壞塊的對象來補償

原创 oracle 11g 鎖處理

運維過程中經常碰到數據庫出現大量的鎖的情況,以下記錄了數據庫鎖處理的詳細過程: 檢查當前的數據庫鎖情況,獲取對應的SID: set line 150 pagesize 30000 select /*+ rule */ INST_I

原创 oracle sys.AUDSES$序列

在RAC環境下,如果logon較多的話,需要加大一個sequence的cache,sys.audses的cache,sys.audses的cache是缺省值20。在RAC環境下,如果logon較爲頻繁的話,這個sequence是必

原创 oracle ORA-32701 hang分析(二)---hugepage優化

上次通過巡檢發現數據庫以下問題: 1. 兩個節點間有大量的gc  詢問應用側開發人員, 整個庫一共三個用戶, UCR、UOP、UQRY, 其中  UCR是所有表的原始創建用戶,  UOP是UCR用戶對應的程序操作用戶, UQRY是一個查詢

原创 mycat常用後端管理命令

首先通過show @@helap; 就可以大致的瞭解Mycat 9066管理端口的常用命令! mysql> show @@help; +------------------------------------------+------

原创 GCC編譯程序出現 undefined reference to `std::ios_base::Init::Init()'問題

在WINDOWS環境的CODE::BLOCKS裏面寫好的測試程序,想拿到Linux裏面試驗一把。報錯: undefined reference to `std::ios_base::Init::Init() 1. 確認是否安裝 gcc-

原创 MySQL 手動清除binlog

新接手的四套庫MySQL庫,採用主從結構。之前配置的夥計備庫的bin log 日誌全部是打開狀態。運維人員反映,空間告警幾次。均手動上去處理。 備庫開啓了bin log 也影響備庫的性能,雖然這四套MySQL庫的壓力不大,但是本着優化的

原创 oracle 11g 靜默安裝

1、版本要求: RHEL6,OEL6 - 6.0及以上 uname -a uname -r 2、安裝目錄要求: 至少10G df -h /oracle 3、內存: 2G以上 grep MemTotal /proc/memin

原创 redis 集羣安裝與配置

1:安裝redis cluster 1):安裝redis-cluster依賴:redis-cluster的依賴庫在使用時有兼容問題,在reshard時會遇到各種錯誤,請按指定版本安裝. (1)確保系統安裝zlib,否則gem instal

原创 MySQL大小寫敏感

Linux下面MySQL5.6的大小寫敏感, 默認值是對大小寫敏感: mysql> show global variables like 'lower_case_table_names'; +-----------------------

原创 CENTOS 7.2 安裝oracle 11.2.0.4 問題小計

提示pdksh包不存在 首先刪除原有的ksh,rpm -qa| grep ksh , 然後rpm -e ksh 下載pdksh wget http://mirror.centos.org/centos/5/os/x86_64/Ce

原创 ora 腳本強化版

#!/bin/sh if [ "$LOGNAME" = "oracle" ]; then SQLPLUS_CMD="/ as sysdba"; else SQLPLUS_CMD="/ as sysdba"; fi case

原创 Linux 7.2 xfs和ext4性能測試

一、說明 紅帽官方版本已經升級到7.2,該版本的標準文件系統已經由EXT4升級到XFS。從操作系統角度來講,爲了獲取更好的支持和服務,此次測試EXT4和XFS的性能區別。 Ext4的文件系統容量達到1EB,而文件容量則達到16TB,這是

原创 oracle ORA-32701 hang分析(一)

今日對某局方的數據庫進行巡檢,發現alert.log日誌裏面有大量的ORA-32701: Possible hangs up to hang ID=57 detected報錯,完整的日誌報錯如下: Sun Dec 13 01:08:12