軟件項目保護方案項目背景及目標項目背景在國家政策的指導和幫忙下，信息化也愈來愈發揮出十分重要的作用。XXXX不斷加大信息化治理工作力度，踴躍實施“上網工程”，大力推動全市局域網建設，加速辦公自動化系統進程，信息技術在改革中發揮了重要的支撐作用，為充分發揮公共職能，增進依法理財、科學理財，提供了重要的信息技術保障。最近幾年來建設各系統隨著數據量的逐年增加，陸續顯現了性能問題，有必要進行數據庫系統的升級及性能優化，以確保應用系統的正常運行，為單位員工提供更好的信息效勞。項目目標對各系統數據庫進行補丁升級效勞，安裝補丁前制定詳細的升級打算和應急回退打算。完成各系統數據庫的性能調優工作。各業務持續性取得有效的保證。需求分析XXXXXXX項目，我公司有連年的行業體會。具有對運維效勞對象進行適時監測、指標分析、和及時修復的能力。Oracle產品日常運行保護項目要緊從如下幾個方面進行：(1).天天對ORACLE數據庫的運行狀態,日記文件,備份情形,數據庫的空間利用情形,系統資源的利用情形進行查看,發覺并解決問題。

(2).每周對數據庫對象的空間擴展情形,數據的增加情形進行監控,對數據庫做健康查看,對數據庫對象的狀態做查看。

(3).查看表空間碎片,提出下一步空間治理打算。對ORACLE數據庫狀態進行一次全面查看。

（4）由于這些數據庫系統承載著XXXX超級重要的業務系統數據，因此在日常保護中需要超級認真，每周、每一個月、每季都需要有相應的巡檢記錄，需要詳細記載以下一些內容：監控數據庫對象的空間擴展情形監控數據量的增加情形系統健康查看，查看以下內容:數據庫對象有效性查看查看是不是有危害到平安策略的問題。查看alert、Sqlnet等日記并歸檔報錯日記分析表和索引查看對數據庫會產生危害的增加速度查看表空間碎片數據庫性能調整預測數據庫以后的性能調整和保護工作后續空間整體運行保護效勞方案Lifekeeper保護驗證LifeKeeper的安裝查看已經安裝的LifeKeeper軟件包，能夠利用命令：rpm–qa|grepstee啟動LifeKeepera) 啟動LifeKeeper效勞器進程若是當前您的系統沒有運行LifeKeeper那么在所有效勞器上以root用戶身份輸入如下命令#/opt/LifeKeeper/bin/lkstartb) 啟動LifeKeeperGUI效勞器進程一樣以root用戶運行命令#/opt/LifeKeeper/bin/lkGUIserverstart注意：以上命令只需運行一次，以后每次系統從頭啟動時，LifeKeeper會自動運行上述進程有關的LifeKeeper軟件的其它治理任務a) 停止LifeKeeper效勞若是需要在效勞器上永久停止LifeKeeper效勞，能夠輸入以下命令$LKROOT/bin/lkstop該命令同時會使所有LifeKeeper愛惜的資源處于退出效勞狀態，若是希望在停止LifeKeeper時維持資源/應用的運行，能夠利用：$LKROOT/bin/lkstop-fb) 查看LifeKeeper進程鍵入以下命令能夠查看當前運行的所有LifeKeeper進程列表ps-ef|grepLifeKeeper啟動LifeKeeperGUI配置工具進入LifeKeeperGUI治理工具能夠通過運行命令：/opt/LifeKeeper/bin/lkGUIapp那么顯現LifeKeeper登錄界面：能夠利用root用戶登錄，也能夠利用新建的用戶進行登錄。檢測LifeKeeper集群運行狀態能夠利用lcdstatus命令對LifeKeeper集群的當前運行狀態進行查看，命令格式：lcdstatus[-q][-d<主機名>]該程序向stdout輸出在LifeKeeper資源層次配置狀態和通信途徑的狀態.選項-q表示輸出采納簡略的形式（建議利用該選項）選項–d表示要查看的主機，缺X查看本機治理LifeKeeper中的資源注意：若是能運行LifeKeeperGUI，那么利用其提供菜單命令執行相應操作；在執行命令行啟動/停止資源前，必然先利用lcdstatus命令確認資源的實際狀態。a) 啟用資源(In-Service)能夠利用命令：./perform_action-t<資源標記名>-arestore將資源標記名所對應的資源在本機上投入效勞（啟動）。若是該資源在命令利用前已經在另一臺機械上處于運行狀態，那么本命令執行的結果相當于執行了一次手工切換！！！若是該資源在命令利用前是處于停止狀態（即在備機上執行本命令），那么本命令執行的結果相當于執行了一次手工切換b) 停止資源(out-of-service)能夠利用命令：./perform_action-t<資源標記名>-aremove將資源標記名所對應的資源在本機上停止效勞。若是該資源在命令利用前已經在另一臺機械上處于運行狀態，那么本命令執行不產生任何結果注意：在執行命令行前后，必然先利用lcdstatus命令確認資源的當前狀態。命令停止/啟動本地的資源命令中的<資源標記名>是區分大小寫的必然要等待命令完成，注意命令的輸出。詳細用法見在線幫忙手冊。SQLSERVER保護運算機系統各類軟、硬件故障、用戶誤操作和歹意破壞是不可幸免的,這些阻礙到數據的正確性乃至造成數據損失、效勞器崩潰等致命后果。數據庫的備份對保證系統的靠得住性具有重要的作用。下面會依照執行強度對保護任務及其相應的程序進行分類描述，執行強度用不同的時刻距離概念，包括天天、每周、每一個月和每季度，能夠成立起良好的保護實務，確保SQLServer數據庫性能和平安。天天的例行保護任務需要數據庫治理員緊密關注的保護任務，最好天天都查看一下，如此能夠確保系統的靠得住性、可用性、運行性能和平安。天天的例行保護任務包括：1、查看是不是所有被請求的SQLServer效勞都正常運行。2、查看日常備份日記中成功、警告或失敗記錄。3、查看Windows事件日記有無錯誤記錄。4、查看SQLServer日記有無平安警告記錄，例如非法登錄。5、執行完全備份或不同備份。6、在設置了完全恢復模型或大容量日恢復模型的數據庫上執行事務日記備份任務。7、核實SQLServer作業沒有失敗。8、查看所有的數據庫文件和事務日記具有適合的磁盤空間大小。9、至少要監控處置器、內存或磁盤計數器沒有顯現瓶頸。每周的例行保護任務關注程度稍遜于天天的例行保護任務，最好每周進行一次例行查看。每周的例行保護任務包括：1、執行完全備份或不同備份。2、查看以前執行的保護打算報告。3、查看數據庫完整性。4、若是需要，執行收縮數據庫任務。5、通過從頭組織索引任務緊縮聚集和非聚集表和視圖。6、通過從頭生成索引任務在數據頁和索引頁從頭組織數據。7、更新所有效戶表和系統表的統計信息8、清除備份、還原、SQLServer代理作業和保護打算等操作的歷史數據。9、若是需要，手動增加數據庫或事務日記文件10、清除執行保護打算殘留下來的文件。每一個月或每季度的保護任務有一些保護打算不需要執行得過于頻繁，能夠每一個月或每一個季度執行一次。可是請不要以為這些任務不需要天天執行就無足輕重，這些任務能夠確保數據庫環境的健康，因此不要輕視以下這些保護任務：1、在測試環境中執行備份還原操作。2、將歷史數據歸檔。3、分析搜集的性能統計數據，與基準值相較較。3、查看并更新保護文檔。4、查看并安裝最新的SQLServer補丁和補丁包。5、若是運行簇、數據庫鏡像或日記傳送，那么監測故障轉移。6、驗證備份和還原進程是不是遵循已概念的效勞品級協議。7、更新SQLServer構建指南。8、更新SQLServer災難恢復文檔。9、更新保護打算列表10、修改治理員口令。11、修改SQLServer效勞帳戶口令。WebLogic保護性能調優設定執行隊列的溢出條件WeblogicServer提供給默許的執行隊列或用戶自概念的執行隊列自概念溢出條件的功能，當知足此溢出條件時，效勞器改變其狀態為“警告”狀態，而且額外的再分派一些線程去向理在隊列中的請求，而達到降低隊列長度的目的。

通過啟動治理操縱臺，在域（如：mydomain）>效勞器>server實例（如：myserver）>ExecuteQueue>>配置下面幾項：

隊列長度：此值表示執行隊列中可容納的最大請求數，默許值是65536，最后不要手動改變此值。

隊列長度閾值百分比：此值表示溢出條件，在此效勞器指出隊列溢出之前能夠達到的隊列長度大小的百分比。

線程數增加：當檢測到溢出條件時，將增加到執行隊列中的線程數量。若是CPU和內存不是足夠的高，盡可能不要改變默許值“0”。因為Weblogic一旦增加后可不能自動縮減，盡管最終可能確實起到了降低請求的作用，但在以后的運行中將影響程序的性能。

最大線程數：為了避免創建過量的線程數量，能夠通過設定最大的線程數進行操縱。

在實際的應用處景中，應依照具體情形適當的調整以上參數。

設定隊列監測行為WeblogicServer能夠自動監測到當一個執行線程變成“阻塞”。變成“阻塞”狀態的執行線程將無法完成當前的工作，也無法再執行新請求。若是執行隊列中的所有執行線程都變成“阻塞”狀態，Weblogicserver可能改變狀態為“警告”或“嚴峻”狀態。若是Weblogicserver變成“嚴峻”狀態，能夠通過NodeManager來自動關閉此效勞器并從頭啟動它。具體請參考：NodeManagerCapabilities文檔。

通過啟動治理操縱臺，在域（如：mydomain）>效勞器>server實例（如：myserver）>配置>調整下可配置下面幾項：

阻塞線程最長時刻：在此效勞器將線程診斷為阻塞線程之前，線程必需持續工作的時刻長度(秒)。默許情形下，WebLogicServer以為線程在持續工作600秒后成為阻塞線程。

阻塞線程計時器距離：WebLogicServer按期掃描線程以查看它們是不是已經持續工作了"阻塞線程最長時刻"字段中指定的時刻長度的距離時刻(秒)。默許情形下，WebLogicServer將現在刻距離設置為600秒。

盡可能利用本地IO庫WebLogicServer有兩套套接字復用器：Java版和本地庫。采納小型本地庫更有效,盡可能激活EnableNativeIO(默許),現在UNIX默許利用CPUs+1個線程,Window下為雙倍CPU。若是系統不能加載本地庫,將會拋出現在只能利用Java套接字復用器,能夠調整socketreaders百分比,默以為33%。該參數能夠在ConsoleServerTuningConfiguration配置欄里設置，配置完，從頭啟動WebLogicServer即可。調整默許執行線程數名稱開發模式產品模式推薦個數ExecuteQueues默認的執行線程為15默認的執行線程為25200在治理操縱臺修改默許執行隊列線程數的步驟如下：若是治理效勞器沒有運行，先啟動。訪問治理操縱臺。展開左側面板的Servers節點，顯示Server列表。右擊Server，在彈出菜單當選擇ViewExecuteQueues，就會在右邊面板顯示有執行隊列的表用來修改。注意：你只能修改默許的執行隊列或用戶概念的執行隊列。在Name列，直接點擊默許執行隊列名稱，顯示配置標簽用來修改執行隊列數。填下適當的線程數。點擊Apply，保留適才的修改。重啟Server，使新的執行隊列設置生效。JDBC調優驅動程序類型選擇Oracle提供thin驅動和oci驅動,從性能上來講,oci驅動強于thin驅動,專門是大數據量的操作。但在簡單的數據庫操作中,性能相差不大,隨著thin驅動的不斷改良,這一弱勢將取得彌補。而thin驅動的移植性明顯強于oci驅動。因此在通常情形下建議利用thin驅動調劑連接池初始容量和最大容量JDBCConnectionPool的調優受制于WebLogicServer線程數的設置和數據庫進程數,游標的大小。通常咱們在一個線程中利用一個連接,因此連接數并非是越多越好,為幸免兩邊的資源消耗，建議設置連接池的最大值等于或略小于線程數。同時為了減少新建連接的開銷,將最小值和最大值設為一致；值等于WebLogicServer的執行線程數。其他配置盡管JDBCConnectionPool提供了很多高級參數,在開發模式下比較有效,但大部份在生產環境下不需調整。那個地址建議最好不要設置測試表,同時TestReservedConnections和TestReleasedConnections也無需勾上。固然若是你的數據庫不穩固,時斷時續,你就可能需要上述的參數打開WEB調優調整WEB應用描述符WEB應用除代碼之外的調優比較簡單,僅僅是對一些WEB應用描述符的調整。第一關閉SessionMonitoringEnabled,僅僅在Cluster環境下設置Session復制(優先利用內存復制),在保證應用正常運行的情形下,設置較短的Session超不時刻。同時生產環境下無需查看Jsp和servlet：JSPPageCheckSecs和ServletReloadCheckSecs均設為-1,關閉JSPKeepGenerated和JSPVerbose對性能也有幫忙。另外，還能夠對jsp進行預編譯,有兩種方式：激活precompile選項；利用事前編譯，建議采納后者。其他調優設置WebLogic文件描述符大小調整第一設置WEB主機系統的ulimit參數為unlimited，然后設置WebLogic中文件描述符的大小。在{WL_HOME}/bea/weblogic/common/bin中打開文件，修改設置文件描述符大小的指令，將默許的：ulimit–n1024修改成：ulimit–n8192保護治理啟動weblogicserver啟動治理效勞器：執行啟動被治理效勞器：執行servernameadminurl停止weblogicserver停止被治理效勞器：執行servername啟動被治理效勞器：執行登錄和退出治理操縱臺治理效勞器啟動后能夠在閱讀器中登錄治理操縱臺輸入URL：，那么利用https訪問治理操縱臺在彈出的窗口“ConsoleLogin“中輸入用戶名和密碼登錄性能監控查看性能參數登錄操縱臺后點擊Servers-servername-Monitoring-Performance參數分析 1)IdleThreads&&QueueLength&&Throughout正常情形下idlethreads>0，queueLength為0，Throughout呈不規那么轉變曲線，MemoryUsage呈適度頻度的鋸齒轉變曲線。一樣來講，關于正常配置的生產環境（線程數50~200），若是idlethreads<10，或呈現不斷降低的趨勢，就應加以關注；空閑線程數與隊列長度通常有如下關系：A、若是空閑線程數>0，那么queuelength=0；B、反之，若是queuelength>0，那么空閑線程數=0； 2)MemoryUsageMemoryUsage=totalMemory()–freeMemory()內存利用曲線反映了JVMHeap內存利用的轉變情形，能夠結合其他三個值的轉變情形來判定server工作情形；比較理想的狀態是適當頻度的各類鋸齒轉變，由于JVMGC多采納“stoptheworld”機制，也確實是垃圾回收時其他處置將暫停，過度頻繁的GC將明顯降低server工作效率和性能表現。Oracle保護OracleDatabase，又名OracleRDBMS，或簡稱Oracle。是的一款。它是在數據庫領域一直處于領先地位的產品。能夠說Oracle數據庫系統是目前世界上流行的關系數據庫治理系統，系統可移植性好、利用方便、功能強，適用于各類大、中、小、微機環境。它是一種高效率、靠得住性好的適應高吞吐量的數據庫解決方案。數據庫性能優化Oracle性能治理既是一種藝術，也是一種科學。從有效角度講，它能夠分為兩種類型，主動式和被動式性能治理。主動式性能治理涉及到特定系統實施初期的設計和開發，包括硬件選擇、性能及容量計劃，海量存儲系統的選擇，I-O子系統配置及優化，和如何對不同組件進行定制，以知足Oracle數據庫和應用系統的復雜要求。被動式性能治理涉及到現有環境中不同組件的性能評估、故障排除和Oracle環境的優化。本文旨在探討如何進行被動式性能調優，以便為Oracle性能調優提供必要的指導，從而幸免僅僅通過反復嘗試的方式進行性能調優，提高Oracle性能治理的效率。因此ORACLE數據庫性能惡化表現大體上都是用戶響應時刻比較長，須要用戶長時刻的等待。取得中意的用戶響應時刻有兩個途徑：一是減少系統效勞時刻，即提高數據庫的吞吐量；二是減少用戶等待時刻，即減少用戶訪問同一數據庫資源的沖突率。關于以上的兩個問題，通常咱們采納以下幾個方面來進行改善：調整效勞器內存分派。例如，能夠依照數據庫運行狀況調整數據庫系統全局區（SGA區）的數據緩沖區、日記緩沖區和共享池的大小；還能夠調整程序全局區（PGA區）的大小。調整硬盤I/O問題，達到I/O負載均衡。調整運用程序結構設計。優化調整操作系統參數和利用資源治理器。SQL優化、診斷latch競爭、Rollback(undo)Segment優化、提升block的效率等等。查看Oracle數據庫性能查看Oracle數據庫性能情形，包括：查看數據庫的等待事件，查看死鎖及處置，查看cpu、I/O、內存性能，查看是不是有僵死進程，查看行鏈接/遷移，按期做統計分析，查看緩沖區命中率，查看共享池命中率，查看排序區，查看日記ORACLE產品日常運行保護年度效勞項目緩沖區，總共十個部份。查看數據庫的等待事件setpages80setlines120coleventfora40selectsid,event,p1,p2,p3,WAIT_TIME,SECONDS_IN_WAITfromv$session_waitwhereeventnotlike'SQL%'andeventnotlike'rdbms%';若是數據庫長時刻持續顯現大量像latchfree，enqueue，bufferbusywaits，dbfilesequentialread，dbfilescatteredread等等待事件時，需要對其進行分析，可能存在問題的語句。查看消耗CPU最高的進程SETLINE240SETVERIFYOFFCOLUMNSIDFORMAT999COLUMNPIDFORMAT999COLUMNS_#FORMAT999COLUMNUSERNAMEFORMATA9HEADING"ORAUSER"COLUMNPROGRAMFORMATA29COLUMNSQLFORMATA60COLUMNOSNAMEFORMATA9HEADING"OSUSER"SELECTPID,SID,SPID,USERNAME,OSNAME,#S_#,,PROGRAM,,,RTRIM(SUBSTR,1,80))SQLFROMV$PROCESSP,V$SESSIONS,V$SQLAREAAWHERE=AND=(+)ANDLIKE'%&1%';查看碎片程度高的表SQL>SELECTsegment_nametable_name,COUNT(*)extentsFROMdba_segmentsWHEREownerNOTIN('SYS','SYSTEM')GROUPBYsegment_nameHAVINGCOUNT(*)=(SELECTMAX(COUNT(*))FROMdba_segmentsGROUPBYsegment_name);查看表空間的I/O比例SQL>SELECTNAME,"FILE",PYR,,PYW,PBWFROMV$FILESTATF,DBA_DATA_FILESDF#=ORDERBY;查看文件系統的I/O比例SQL>SELECTSUBSTR#,1,2)"#",SUBSTR,1,30)"NAME",,,,FROMV$DATAFILEA,V$FILESTATBWHERE#=#;DiskRead最高的SQL語句的獲取SQL>SELECTSQL_TEXTFROM(SELECT*FROMV$SQLAREAORDERBYDISK_READS)WHEREROWNUM<=5desc;查找前十條性能差的sqlSELECT*FROM(SELECTPARSING_USER_IDEXECUTIONS,SORTS,COMMAND_TYPE,DISK_READS,SQL_TEXTFROMV$SQLAREAORDERBYDISK_READSDESC)WHEREROWNUM<10;等待時刻最多的5個系統等待事件的獲取SELECT*FROM(SELECT*FROMV$SYSTEM_EVENTWHEREEVENTNOTLIKE'SQL%'ORDERBYTOTAL_WAITSDESC)WHEREROWNUM<=5;查看運行好久的SQLCOLUMNUSERNAMEFORMATA12COLUMNOPNAMEFORMATA16COLUMNPROGRESSFORMATA8SELECTUSERNAME,SID,OPNAME,ROUND(SOFAR*100/TOTALWORK,0)||'%'ASPROGRESS,TIME_REMAINING,SQL_TEXTFROMV$SESSION_LONGOPS,V$SQLWHERETIME_REMAINING<>0ANDSQL_ADDRESS=ADDRESSANDSQL_HASH_VALUE=HASH_VALUE;查看死鎖及處置查詢目前鎖對象信息：colsidfor999999colusernamefora10colschemanamefora10colosuserfora16colmachinefora16colterminalfora20colownerfora10colobject_namefora30colobject_typefora10selectsid,serial#,username,SCHEMANAME,osuser,MACHINE,terminal,PROGRAM,owner,object_name,object_type,fromdba_objectso,v$locked_objectl,v$sessionswhere=and=;oracle級kill掉該session：altersystemkillsession'&sid,&serial#';操作系統級kill掉session：#>kill-9pid查看數據庫cpu、I/O、內存性能記錄數據庫的cpu利用、IO、內存等利用情形，利用vmstat,iostat,sar,top等命令進行信息搜集并查看這些信息，判定資源利用情形。CPU利用情形：[root@sale8~]#toptop-10:29:35up73days,19:54,1user,loadaverage:,,:353total,2running,351sleeping,0stopped,0zombieCpu(s):%us,%sy,%ni,%id,%wa,%hi,%siMem:ktotal,kused,3517044kfree,60796kbuffersSwap:8385920ktotal,665576kused,7720344kfree,kcachedPIDUSER30495oracle32501oracle32503oracle注意上面的加粗字體部份，此部份內容表示系統剩余的cpu，當其平均值下降至10%以下的時視為CPU利用率異樣，需記錄下該數值，并將狀態記為異樣內存利用情形：#free-mTotalusedfreesharedbufferscachedMem:2026-/+buffers/cache:3261700Swap:5992925900如上所示，total表示系統總內存，used表示系統利用的內存，free表示系統剩余內存，當剩余內存低于總內存的10%時視為異樣。系統負載情形：#uptime12:08:37up162days,23:33,15users,loadaverage:,,如上所示，loadaverage部份表示系統負載，后面的3個數值若是有高于的時候就說明系統在超負荷運轉了，并將此值記錄到巡檢表，視為異樣。查看是不是有僵死進程selectspidfromv$processwhereaddrnotin(selectpaddrfromv$session);有些僵尸進程有阻塞其他業務的正常運行，按期殺掉僵尸進程。查看行鏈接/遷移Sql>selecttable_name,num_rows,chain_cntFromdba_tablesWhereowner='CTAIS2'Andchain_cnt<>0;注：含有longraw列的表有行鏈接是正常的,找到遷移行保留到chained_rows表中,如沒有該表執行../rdbms/admin/Sql>analyzetabletablenamelistchainedrows;可通過表chained_rows中table_name,head_rowid看出哪些行是遷移行如:Sql>createtableaaasselecta.*fromsb_zsxxa,chained_rowsbwhere=='SB_ZSXX';sql>deletefromsb_zsxxwhererowidin(selecthead_rowidfromchained_rowswheretable_name='SB_ZSXX');sql>insertintosb_zsxxselect*fromchained_rowwheretable_name='SB_ZSXX';按期做統計分析關于采納OracleCost-Based-Optimizer的系統，需要按期對數據對象的統計信息進行搜集更新，使優化器能夠依照預備的信息作出正確的explainplan。在以下情形更需要進行統計信息的更新：應用發生轉變；大規模數據遷移、歷史數據遷出、其他數據的導入等；數據量發生轉變。查看表或索引的統計信息是不是需更新，如：Sql>Selecttable_name,num_rows,last_analyzedFromuser_tableswheretable_name='DJ_NSRXX'sql>selectcount(*)fromDJ_NSRXX如num_rows和count(*)若是行數相差很多,那么該表需要更新統計信息，建議一周做一次統計信息搜集，如：Sql>exec'CTAIS2',cascade=>TRUE,degree=>4);查看日記緩沖區SQL>selectname,valuefromv$sysstatwherenamein('redoentries','redobufferallocationretries');若是redobufferallocationretries/redoentries超過1%，那么需要增大log_buffer。性能調優及方式性能調優要緊有主動調優和被動調優，主動調優在前面咱們已經進行了論述，被動調優要緊有以下方式進行。確信合理的性能優化目標測試并記錄當前的性能指標確信當前存在的Oracle性能瓶頸(Oracle中何處存在等待，哪個SQL語句與此有關)確信當前的操作系統瓶頸優化相關的組件(應用、數據庫、I/O、連接OS及其它)跟蹤并實施轉變治理制度測試并記錄目前的性能指標重復第3到第7步直至達到既定的優化目標不要對并非性能瓶頸的部份進行優化，不然可能引發額外的問題。正如任何伶俐的人會告知你的：“若是還未壞，萬萬不要修”。更重要的是，一旦既定的優化目標已經達到，就務必停止所有的優化。獲取Oracle的性能指標(測試前及測試后)必需在峰值處置時測試并獲取系統在優化前和優化后的性能指標。數據搜集不該在數據庫instance方才起動后進行。同時，測試數據應在峰值期間每過15分鐘進行一次。初始化參數TIMED_STATISTICS應該被設為TRUE。通過運行以下腳本開始快照：$ORACLE_HOME/rdbms/admin/.通過運行以下腳本終止快照：$ORACLE_HOME/rdbms/admin/.完成操作后，會在當前目錄中生成名為“”的文件，包括系統的性能數據。該報告包括每15分鐘捕捉的所有與Oracle例程相關的參數。尋覓問題本源如上所述，通過查看v$system_event事件開始系統事件的問題診斷。下一步是查看v$session_event，找出引發或經歷等待事件的進程。最后一步是通過v$session_wait取得事件的細節。同時，應該進一步通過OS進行深切分析，了解核心的CPU、內存和IO狀態參數。最后，結合兩種不同的診斷的結論，找出系統瓶頸所在。應用優化從統計(和現實)的角度看，80%的Oracle系統性能問題能夠通過SQL代碼優化來解決。任何應用優化的進程，不外乎是索引優化、全表掃描、并行機制改良和選擇正確數據組合方式的進程。這正是要達到最正確應用性能所必需考慮的因素。沒有SQL的優化，就無法實現高性能的應用。良好的SQL語句能夠減少CPU資源的消耗，提高響應速度。同時，優化后的SQL語句還能夠提高應用的可擴展性，這是除增加大量內存外，任何其它硬件手腕也無法實現的。I-O優化I-O優化是系統優化中的一個關鍵步驟，還涉及到其它任務，將文件在不同驅動器/卷中進行散布，采納優化分區技術、確信I-O子系統瓶頸、確信操縱器瓶頸并依照應用的類型選擇最正確的RAID級。I-O優化應該在全面了解Oracle及OracleRDBMS結構以后進行。應該在進行I-O優化前后實施I-O數據監控，如平均效勞時刻，IOPS，平均磁盤隊列長度等。O-S監控數據庫忙時，應該對操作系統進行監控，因為操作系統的性能指標會揭露數據庫活動的性質及其對系統的阻礙。例如，為了了解CPU的利用率，能夠通過systemactivityreporter(sar–uintervalfrequency)、mpstat(SunSolaris),top(多數UNIX)、osview(SGIIrix)及vmstat等命令。Sar和vmstat也可被用于確信包括內存利用率、I-O參數、隊列等待、讀取/互換區活動等信息。在Solaris上，mpstatutility也可用于獲取前面提到的CPU利用率數據。Solaris上的Adrian性能治理工具也很有效。能夠利用其中的一到多個工具來確信系統的性能狀況，找出可能存在的瓶頸。Oracle數據庫性能的治理需要遵循系統的方式論，以確保所有核心問題得以解決。多數問題能夠事前得以治理。了解與O-S相關的問題是成功的關鍵。勿需置疑，系統硬件配置上的良好平穩也是相當重要的。必需承認，80%的系統性能問題能夠通過書寫更好的SQL語句來解決。來文試圖探討其余20%中可能覆蓋的內容。同時，必需遵守嚴格的規定，在調優目標達到后終止所有盡力。了解自己想到何處是重要的，更重要的是，要明白自己何時抵達了目的地。例程調優需要配置的要緊初始化參數以下是一些已知與例程優化關系最緊密的一些核心Oracle初始化參數。它們都會阻礙Oracle及SGA區的活動。任何對這些參數的改動，在實施到生產環境之前，都必需進行測試。一旦改變了生產環境的參數，就必需對相關的Oracle動態性能指標和操作系統的性能進行監測，尋覓可能由此產生的異樣現象。1)DB_BLOCK_SIZE該參數在數據庫成立前設定，決定了數據庫中每一個數據塊的大小。只有從頭成立數據庫，才有可能改變該參數。db_block_size的配置應遵循以下公式：DB_BLOCK_SIZE=FILESYSTEMBLOCKSIZE>=O-SPAGESIZE這能夠確保Oracle取得最正確I/O性能，同時可不能由于冗余或沒必要要的I/O，給I/O子系統帶來壓力。2)DB_BLOCK_BUFFERS該參數決定了SGA區數據庫緩沖區中的塊數量。由于這是Oracle讀取和寫入的區域，它的不正確配置會引發嚴峻的I/O性能問題。盡管緩沖區的大小與應用性質、數據庫大小、同步用戶數等無關，它的確是SGA區中最大的組件。常常能夠看到緩沖區占用75-80%SGA區內存的情形。另外，這一參數設置過大，也會引發整個系統的內存不足，引發操作系統過量的讀寫操作。該參數及SHARED_POOL_SIZE一般是兩個最重要的SGA優化目標。只有當數據庫緩沖率長時刻低于70%時，才需要增加其大小說。即便在這種情形下，也需要進一步審查應用的性能和整個系統的吞吐性。假設存在延遲性的應用設計問題，那么不管數據庫緩沖區的大小如何，緩沖和讀寫率都可不能有太大改變成。在實調優中，也曾發覺由于SQL語句的問題，顯現緩沖率很高，但仍存在全系統性能問題的情形。3)SHARED_POOL_SIZE該參數按字節數設定，概念了SGA中共享區的大小。該組件的大小嚴峻依托于應用的類型(即該應用是重用SQL，仍是生成動態SQL，等等)。同時它也取決于同步用戶的數量，和實例是不是被配置成支持多線程效勞器(MTS)。若是該應用采納了MTS配置，那么共享區應該明顯增加，因為光標狀態和用戶進程數據等程序全局區域(PGA)都被置入了共享區。有關多數應用的SHARED_POOL_SIZE大小設置，能夠從每10個同步用戶16MB共享區開始。這不是一成不變的，因為應用的性質最終會決定該組件的大小。只有當庫緩沖和字典緩沖利用率一直低于90%時，才需要關注這一參數。但如果是應用并未采納變量歸并和/共離圖標時，內存的數量并非會使緩沖利用率高于90%。共享區過大會致使處置時刻增加，乃至SQL語句的掛起。若是應用不能有效地重用SQL，那么不管配置多大的庫緩沖或字典緩沖都無濟于事，不能改善緩沖利用率。另一個值得考慮的因素是需要隨時利用的存儲PL/SQL代碼數量。應用的核心包能夠通過查看DBA_SOURCE、USER_SOURCE得以確認，其大小通過查詢DBA_OBJECT_SIZE了解。另外，為了確信存儲PL/SQL是不是被置于內存，能夠查詢動態性能視圖V$DB_OBJECT_SIZE。內時，包DBMS_SHARED_POOL中的程序大小可被用于確信應用中大包的規模。4)LOG_BUFFER依照字節設定，該參數概念了SGA緩沖區中redolog的大小。缺X值一般是數據庫塊大小的四倍，這關于多數環境并非是最正確的。關于中型的Oracle環境，其結構應該為512Kb左右。對該存儲結構而言，更大并非意味著更好。超過1MB就可能有問題。需要監控V$SESSION_WAIT中logbufferspace的等待事件，優化該內存結構。需要提示的是，在線redolog文件的大小設置不妥，會引發redo請求的等待。5)DB_WRITERS該參數能夠針對所有文件系統支持，且不可利用DirectI-O的Oracle實施設定。這并非需要與rawpartitions一路利用，因為異步I-O加倍。建議將該參數設定為(2*獨立磁盤驅動器數量/卷)。該參數只有在中的“averagewritequeuelength”持續高于1時，才需要設定。在Oracle和更高版本中，該參數已再也不被支持，而為其它兩個名為DB_WRITER_PROCESSES和DBWR_IO_SLAVES的參數取代。假設需要設置DB_WRITER_PROCESSES值高于8，那么DB_WRITER_PROCESSES可被設為1，且DBWR_IO_SLAVES可被設為“n”，其中n的值必需設置為(2*獨立磁盤驅動器數量/卷)競爭優化多數與Oracle有關的競爭問題能夠通過主動配置治理相關的初始化參數進行。不恰本地配置中的鎖參數可能引發競爭。為了不打破其中的平穩，所需的參數可進行配置并主動得以處置。包括表在內的數據庫對象可能存在兩個競爭點。第一個是所配置的“freelists”的數量(缺X值為1)。freelist結構保護著表中可用于插入的塊。關于存在大量同步插入的表，有必要配置該結構。為了以主動方式處置freelist競爭，必需在成立表時配置FREELISTS。可考慮的最正確值為(2*CPU數量)。V$WAITSTAT不可能指示存在freelist競爭，除非存在freelist組，而這種設置只存在于OracleParallelServer中。即便如此，也無法了解哪個表存在競爭中。主動式的freelist競爭調優能夠事前預防問題顯現。資源競爭的第二個來源與索引有關，即對象塊頭中配置的事務槽數量。事務槽是塊頭中的區域，是事務處置進程采納自身識別號進行注冊，以便任何被修改的更能夠通過特定事務槽數量在低層得以識別的地址。若是所有現存的事務槽已經被其它事務占用，效勞器器進程會從塊的PCTFREE中請求23個字節，成立一個新的槽。這種情形適用于存在大量同步事務的對象。關于事務槽的競爭，需要設置INITRANS參數。關于塊大小為8K的數據庫，多數情形下，4為最正確設置，占用的空間僅為92字節，卻能夠大大減少運行時故障和性能問題。數據庫備份恢復為了保證客戶數據庫系統的數據平安性，降低各類故障、災難給客戶帶來的數據丟失，依照客戶系統實際情形，協助客戶計劃實施符合客戶工作要求的完善的備份恢復方案，以確保客戶數據庫系統的平安靠得住運行。數據庫的恢復與備份要緊有以下幾點：恢復治理器(RMAN)，能使備份恢復操作自動化Oracle數據泵，用以數據庫的邏輯備份用戶治理許諾用戶通過操作系統命令手動備份數據庫。各類各樣的其他的數據庫備份和恢復軟件，增強了Oracle的備份有效程序Oracle備份時應注意事項：當數據庫處于運行狀態時的熱備份時，不備份活動事務；利用比如Oracle工具（OracleRAMN）或其他的第三方軟件（IBM/Tivoli的數據存儲治理器）緊縮Oracle備份數據；若是維持數據存儲空間比備份和恢復數據庫時刻更重要的話，能夠考慮利用二進制緊縮。查看Oracle數據庫備份結果查看Oracle數據庫備份結果，是日常運維中必不可少的一個環節。包括：查看數據庫備份日記信息，查看backup卷中文件產生的時刻，查看oracle用戶的email，總共三個部份。查看數據庫備份日記信息假設：備份的臨時目錄為/backup/hotbakup，咱們需要查看2021年7月22日的備份結果，那么用下面的命令來查看：#cat/backup/hotbackup/|grep–ierror備份腳本的日記文件為hotbackup-月份-日期-年份.log，在備份的臨時目錄下面。若是文件中存在“ERROR:”，那么說明備份沒有成功，存在問題需要查看。查看backup卷中文件產生的時刻#ls–lt/backup/hotbackupbackup卷是備份的臨時目錄，查看輸出結果中文件的日期，都應當是在當天凌晨由熱備份腳本產生的。若是時刻不對那么說明熱備份腳本沒執行成功。查看oracle用戶的email#tail–n300/var/mail/oracle熱備份腳本是通過Oracle用戶的cron去執行的。cron執行完后操作系統就會發一條Email通知Oracle用戶任務已經完成。查看Oracleemail中今天凌晨部份有無ORA-，Error，Failed等犯錯信息，若是有那么說明備份不正常。數據庫遷移數據遷移是日常運維進程中存在的一個必不可少的應急方案。日常保護進程中，由于硬件的緣故或其它一些外在因素需要對數據進行遷移，遷移到加倍高級的主機上、遷移到遠程的機房上、遷移到不同的平臺劣等等一些情形。關于數據遷移我公司有超級成熟的方案，從以下幾種方式咱們能夠充分了解其優缺點：exp/imp：這也算是最經常使用最簡單的方式了，一樣是基于應用的owner級做導出導入；優勢是能夠跨平臺利用；缺點是停機時刻長，停機時刻為從exp到網絡傳輸到新庫，再加上imp的時刻；存儲遷移：這種情形下，數據文件、操縱文件、日記文件、spfile都在存儲上（一樣情形下是裸設備），咱們能夠直接把存儲掛到新機械上，然后在新機械上啟動數據庫；優勢是該遷移方式超級簡單，要緊的工作是主機工程師的工作，dba只需配合即可，停機時刻為當庫、切存儲、起庫的時刻。缺點是要求新老庫都是同一平臺，是相同的數據庫版本。利用dataguard遷移；優勢是停機時刻短，停機時刻為switchover的時刻。缺點：主機必需雙份、存儲必需雙份。用rman做遷移，這種方式比較適合于跨文件系統的遷移，猶如平臺下的不同文件系統。數據庫運維數據庫的運維要緊結合各系統的實際情形，提供切實可行的運維建設機制，內容覆蓋ORACLE數據庫的日常保護、緊急故障處置，軟件升級等，客戶可依據效勞內容進行相應的定制。咱們將會提供全面的、針對性的效勞解決方案，以保證客戶系統穩固、高效、靠得住的運行，以達到對業務系統的有效支持。查看數據庫大體狀況對數據庫的大體狀況進行查看，其中包括：查看Oracle實例狀態，查看Oracle效勞進程，查看Oracle監聽進程，共三個部份。查看Oracle實例狀態SQL>selectinstance_name,host_name,startup_time,status,database_statusfromv$instance;其中“STATUS”表示Oracle當前的實例狀態，必需為“OPEN”；“DATABASE_STATUS”表示Oracle當前數據庫的狀態，必需為“ACTIVE”。SQL>selectname,log_mode,open_modefromv$database;其中“LOG_MODE”表示Oracle當前的歸檔方式。“ARCHIVELOG”表示數據庫運行在歸檔模式下，“NOARCHIVELOG”表示數據庫運行在非歸檔模式下。在咱們的系統中數據庫必需運行在歸檔方式下。查看Oracle效勞進程$ps-ef|grepora_|grep-vgrep&&ps-ef|grepora_|grep-vgrep|wc–l在查看Oracle的進程命令輸出后，輸出顯示至少應包括以下一些進程：Oracle寫數據文件的進程，輸出顯示為：“ora_dbw0_CKDB”Oracle寫日記文件的進程，輸出顯示為：“ora_lgwr_CKDB”Oracle監聽實例狀態的進程，輸出顯示為：“ora_smon_CKDB”Oracle監聽客戶端連接進程狀態的進程，輸出顯示為：“ora_pmon_CKDB”Oracle進行歸檔的進程，輸出顯示為：“ora_arc0_CKDB”Oracle進行查看點的進程，輸出顯示為：“ora_ckpt_CKDB”Oracle進行恢復的進程，輸出顯示為：“ora_reco_CKDB”查看Oracle監聽狀態/home/oracle>lsnrctlstatus“ServicesSummary”項表示Oracle的監聽進程正在監聽哪些數據庫實例，輸出顯示中至少應該有“CKDB”這一項。查看監聽進程是不是存在：[oracle@AS14~]$ps-ef|greplsn|grep-vgrep查看系統和oracle日記文件查看相關的日記文件，包括：查看操作系統的日記文件，查看Oracle日記文件，查看Oracle核心轉儲目錄，查看Root用戶和Oracle用戶的email，總共四個部份。查看操作系統日記文件#cat/var/log/messages|grepfailed查看是不是有與Oracle用戶相關的犯錯信息。查看oracle日記文件[oracle@AS14~]$cat/data/oracle/admin/CKDB/bdump/|grepora-[oracle@AS14~]$cat/data/oracle/admin/CKDB/bdump/|greperr[oracle@AS14~]$cat/data/oracle/admin/CKDB/bdump/|grepfailOracle在運行進程中，會在警告日記文件中記錄數據庫的一些運行情形：數據庫的啟動、關閉，啟動時的非缺X參數；數據庫的重做日記切換情形，記錄每次切換的時刻，及若是因為查看點(checkpoint)操作沒有執行完成造成不能切換，會記錄不能切換的緣故；對數據庫進行的某些操作，如創建或刪除表空間、增加數據文件；數據庫發生的錯誤，如表空間不夠、顯現壞塊、數據庫內部錯誤(ORA－600)等。按期查看日記文件，依照日記中發覺的問題及時進行處置：問題處理啟動參數不對查看初始化參數文件因為查看點操作或歸檔操作沒有完成造成重做日志不能切換如果經常發生這樣的情況，可以考慮增加重做日志文件組；想辦法提高查看點或歸檔操作的效率；有人未經授權刪除了表空間查看數據庫的安全問題，是否密碼太簡單；如有必要，撤消某些用戶的系統權限出現壞塊查看是否是硬件問題(如磁盤本生有壞塊)，如果不是，查看是那個數據庫對象出現了壞塊，對這個對象進行重建表空間不夠增加數據文件到相應的表空間出現ORA-600根據日志文件的內容查看相應的TRC文件，如果是Oracle的bug，要及時打上相應的補丁Listener日記：$ORACLE_HOME/network/log查看Oracle核心轉儲目錄$ls$ORACLE_BASE/admin/CKDB/cdump/*.trc|wc-l$ls$ORACLE_BASE/admin/CKDB/udump/*.trc|wc–l若是上面命令的結果天天都在增加，那么說明Oracle進程常常發生核心轉儲。這說明某些用戶進程或數據庫后臺進程由于無法處置的緣故此異樣退出。頻繁的核心轉儲專門是數據庫后臺進程的核心轉儲會致使數據庫異樣終止。查看Root用戶和Oracle用戶的email#tail–n200/var/mail/root#tail–n200/var/mail/oracle查看有無與Oracle用戶相關的犯錯信息。查看Oracle對象狀態查看相關Oracle對象的狀態，包括：查看Oracle操縱文件狀態，查看Oracle在線日記狀態，查看Oracle表空間的狀態，查看Oracle所有數據文件狀態，查看Oracle所有表、索引、存儲進程、觸發器、包等對象的狀態，查看Oracle所有回滾段的狀態，總共六個部份。查看Oracle操縱文件狀態SQL>selectstatus,namefromv$controlfile;輸出結果應該有3條以上（包括3條）的記錄，“STATUS”應該為空。狀態為空表示操縱文件狀態正常。查看Oracle在線日記狀態SQL>selectgroup#,status,type,memberfromv$logfile;輸出結果應該有3條以上（包括3條）記錄，“STATUS”應該為非“INVALID”，非“DELETED”。注：“STATUS”顯示為空表示正常。查看Oracle表空間的狀態SQL>selecttablespace_name,statusfromdba_tablespaces;輸出結果中STATUS應該都為ONLINE。查看Oracle所有數據文件狀態SQL>selectname,statusfromv$datafile;輸出結果中“STATUS”應該都為“ONLINE”。或：SQL>selectfile_name,statusfromdba_data_files;輸出結果中“STATUS”應該都為“AVAILABLE”。查看所有回滾段狀態SQL>selectsegment_name,statusfromdba_rollback_segs;輸出結果中所有回滾段的“STATUS”應該為“ONLINE”。查看Oracle相關資源的利用情形查看Oracle相關資源的利用情形，包括：查看Oracle初始化文件中相關的參數值，查看數據庫連接情形，查看系統磁盤空間，查看Oracle各個表空間利用情形，查看一些擴展異樣的對象，查看system表空間內的內容，查看對象的下一擴展與表空間的最大擴展值，總共七個部份。查看Oracle初始化文件中相關參數值SQL>selectresource_name,max_utilization,initial_allocation,limit_valuefromv$resource_limit;若LIMIT_VALU-MAX_UTILIZATION<=5，那么說明與RESOURCE_NAME相關的Oracle初始化參數需要調整。能夠通過修改Oracle初始化參數文件$ORACLE_BASE/admin/CKDB/pfile/來修改。查看數據庫連接情形查看當前會話連接數，是不是屬于正常范圍。selectsid,serial#,username,program,machine,statusfromv$session;其中：SID會話(session)的ID號；SERIAL#會話的序列號，和SID一路用來唯一標識一個會話；USERNAME成立該會話的用戶名；PROGRAM那個會話是用什么工具連接到數據庫的；STATUS當前那個會話的狀態，ACTIVE表示會話正在執行某些任務，INACTIVE表示當前會話沒有執行任何操作；若是成立了過量的連接，會消耗數據庫的資源，同時，對一些“掛死”的連接可能需要手工進行清理。若是DBA要手工斷開某個會話，那么執行：（一樣不建議利用這種方式去殺掉數據庫的連接，如此有時候session可不能斷開。容易引發死連接。建議通過sid查到操作系統的spid,利用ps–ef|grepspidno的方式確認spid不是ORACLE的后臺進程。利用操作系統的kill-9命令殺掉連接）altersystemkillsession'SID,SERIAL#';注意：上例中SID為1到10(USERNAME列為空)的會話，是Oracle的后臺進程，不要對這些會話進行任何操作。查看系統磁盤空間若是文件系統的剩余空間過小或增加較快，需對其進行確認并刪除不用的文件以釋放空間。[oracle@AS14~]$df–h查看表空間利用情形SQL>select,,,round(*100)"%Free"from(selecttablespace_name,sum(bytes/(1024*1024))totalfromdba_data_filesgroupbytablespace_name)a,(selecttablespace_name,round(sum(bytes/(1024*1024)))freefromdba_free_spacegroupbytablespace_name)fWHERE=(+)orderby"%Free";若是空閑率%Free小于10%以上（包括10%），那么注意要增加數據文件來擴展表空間而不若是用數據文件的自動擴展功能。請不要對表空間增加過量的數據文件，增加數據文件的原那么是每一個數據文件大小為2G或4G，自動擴展的最大限制在8G。查看一些擴展異樣的對象sql>selectSegment_Name,Segment_Type,TableSpace_Name,(Extents/Max_extents)*100PercentFromWhereMax_Extents!=0and(Extents/Max_extents)*100>=95orderByPercent;若是有記錄返回，那么這些對象的擴展已經快達到它概念時的最大擴展值。關于這些對象要修改它的存儲結構參數。查看對象的下一擴展與表空間的最大擴展值sql>select,,fromall_tablesa,(selecttablespace_name,max(bytes)asbig_chunkfromdba_free_spacegroupbytablespace_name)fwhere=and>unionselect,,fromall_indexesa,(selecttablespace_name,max(bytes)asbig_chunkfromdba_free_spacegroupbytablespace_name)fwhere=and>;若是有記錄返回，那么說明這些對象的下一個擴展大于該對象所屬表空間的最大擴展值，需調整相應表空間的存儲參數。查看數據庫平安性查看Oracle數據庫的平安性，包括：查看系統平安信息，按期修改密碼，總共兩個部份。查看系統平安日記信息系統平安日記文件的目錄在/var/log下，要緊查看登錄成功或失敗的用戶日記信息。查看登錄成功的日記：[root@rac2~]#grep-iaccepted/var/log/secure查看登錄失敗的日記：[root@rac2~]#grep-iinval/var/log/secure&&grep-ifailed/var/log/secure在顯現的日記信息中沒有錯誤(Invalid、refused)提示，若是沒有(Invalid、refused)視為系統正常，顯現錯誤提示，應作出系統告警通知。查看用戶修改密碼在數據庫系統上往往存在很多的用戶，如：第三方數據庫監控系統，初始安裝數據庫時的演示用戶，治理員用戶等等，這些用戶的密碼往往是寫定的，被很多人明白，會被別有效心的人利用來解決系統乃至進行修改數據。需要修改密碼的用戶包括：數據庫治理員用戶SYS，SYSTEM；其他用戶。登岸系統后，提示符下輸入cat/etc/passwd，在列出來的用戶中查看是不是存在已經再也不利用的或是陌生的帳號。假設存在，那么記錄為異樣。修改密碼方式：Sql>alteruserUSER_NAMEidentifiedbyPASSWORD;其他查看查看當前crontab任務是不是正常，查看OracleJob是不是有失敗等共六個部份。OracleJob是不是有失敗Sql>selectjob,what,last_date,next_date,failures,brokenfromdba_jobsWhereschema_user='CAIKE';如有問題建議重建job，如：execcommit;'REFRESH_ALL_SNAPSHOT;',SYSDATE+1/1440,'SYSDATE+4/1440');commit;監控數據量的增加情形SQL>select2,(1-/*100used_percent3from(selecttablespace_name,sum(bytes)total4fromdba_free_spacegroupbytablespace_name)A,5(selecttablespace_name,sum(bytes)total6fromdba_data_filesgroupbytablespace_name)B7where=;依照本周天天的查看情形找到空間擴展專門快的數據庫對象,并采取相應的方法：刪除歷史數據移動規定數據庫中至少保留6個月的歷史數據，因此以前的歷史數據能夠考慮備份然后進行清除以便釋放其所占的資源空間。擴表空間altertablespace<tablespace_name>adddatafile‘<file>’size<size>autoextendoff;注意：在數據庫結構發生轉變時，如增加了表空間，增加了數據文件或重做日記文件這些操作，都會造成Oracle數據庫操縱文件的轉變，DBA應及進行操縱文件的備份，備份方式是：執行SQL語句：alterdatabasebackupcontrolfileto'/home/backup/';或：alterdatabasebackupcontrolfiletotrace;如此，會在USER_DUMP_DEST(初始化參數文件中指定)目錄下生成創建操縱文件的SQL命令。查看無效的triggerSELECTowner,trigger_name,table_name,statusFROMdba_triggersWHEREstatus='DISABLED';如有失效觸發器那么啟用，如：Sql>alterTriggerTRIGGER_NAMEEnable;系統技術支持及預防性保護方案一個系統開發與實施的成功與否，專門大程度上取決于利用單位對該系統的利用情形，一個再好的系統若是沒有人利用，那么也不能說該系統是成功的，只能說它是失敗的。因此我公司尤其重視對利用單位的人員針對系統的利用培訓，并依照不同的利用權限及功能進行有針對性的培訓效勞。售后效勞我公司設有專門的技術支持中心,為客戶提供快捷周到的效勞。技術支持中心有完善的售后效勞體系,包括支持、電子郵件、遠程網絡支持、現場響應、緊急恢復等。可快速響應各用戶的效勞請求，隨時為客戶提供優質的技術效勞。支持當系統發生問題時，用戶能夠從客服專線取得及時有效的24小時支持。客戶效勞人員做好客戶效勞需求的記錄，并向用戶明確效勞需求的解決方式、進程和最終的解決方法。我公司將提供終身7×24小時熱線支持。提供遠程效勞器接入、郵件和效勞支持。現場效勞若是用戶的問題不能通過解決，客戶效勞部會立刻派體會豐碩的工程師到現場為用戶解決問題，客戶效勞人員對解決的進程進行記錄，并向用戶提供解決問題的報告．包括問題緣故、解決方式、解決問題的方式和進程，和建議用戶對系統進行正常利用的指導和培訓．問題解決后需要用戶進行確認。按期巡檢效勞依照招標文件的技術要求，我公司按期對系統進行運維巡檢效勞，并出具巡檢報告，發覺并預防可能產生的問題；巡檢完成后，于次月的5日前提交上月度的巡檢報告。巡檢內容包括：系統日記、網絡狀況、系統空間狀況、存儲設備狀態、系統性能、產品參數與配置、數據庫各類文件的狀態與配置、數據庫平安審計、數據對象配置的合理性、實例的運行效率、SQL代碼性能調優等。項目治理體系概述項目治理要緊包括治理組織、打算治理、質量操縱、文檔治理、風險治理及范圍操縱等部份內容。治理組織系統的實施開發涉及大量的業務處置流程與用戶核心的治理理念與組織架構,必需取得各部門的通力合作,尤其是業務部門骨干的參與。因此建議進行二級項目治理。即：A：項目指導委員會 負責項目的組織、和諧和推行工作。 將委派相應人員擔任方項目總和諧人。 建議客戶選派專人擔任用戶方項目總監，負責整個項目的實施。B：項目治理小組、項目領導項目領導全權負責項目治理，負責業務和技術方面的和諧。職責如下： 作出項目實施打算 安排資源，和諧項目組成員的工作 保證項目按規定的標準和質量進行 按期提交項目進展情形報告、及時提出需要解決的問題 治理項目風險 操縱項目預算 工作進度治理打算治理依照項目進度的要求，制定切實可行的工作打算，規定每一個成員的任務，查看任務完成的情形和質量，是保證項目順利實施的重要保證。工作打算治理應包括以下幾點： 按周做出工作打算，并經兩邊批準。 每周進行工作量統計，質量查看，并由客戶簽字。 每周做出工作小結，說明未完成緣故及改良建議。 工作分解到人。 項目領導應隨時和諧每人的工作，幸免重復或脫節。質量治理建議由兩邊項目領導對項目實施質量進行操縱。包括： 工作質量的審查與評定 工作質量的測試 工作進程的操縱和資料的完整性 負責歸集客戶簽署的時期功效確認書質量審查審查是以打算的內容為基礎，以目標和方式為依據，對所用的各類技術工作進行描述，同時提交執行文檔和軟件，所有提交審查的記錄將會作為項目審計線索被保留。測試治理一樣包括以下幾部份： 模塊測試：保證/驗證一個獨立模塊的功能。 系統測試：保證/驗證在此項目內功能區之間的功能。 集成測試：保證/驗證在項目整個應用區域內的整體功能。 測試結果確認。在進行上述各類測試前，兩邊項目領導必需先擬定測試打算，確信測試數據和可同意的測試結果。文檔治理在項目實施進程中，由于項目實施的復雜性，多方人員參加和時刻跨度長等因素，因此任何需求、建議、解決方案和結論都必需文檔化、標準化，以便查閱和引用。實施文檔應作為項目功效的一個組成部份。以下項目資料將在實施期間搜集：1. 各類設計，測試文檔。包括： 項目治理文檔 客戶化文檔和模塊開發文檔 客戶提交的需求文檔 客戶需求改變報告和批準書 測試方案和測試結果報告 客戶簽署的時期功效確認書 項目總結報告2. 成立需求變更表和日記3. 成立問題與風險報表和日記4. 成立周時期工作總結報告5. 成立會議備忘錄和日記風險治理1).用戶不能準確表達需求/用戶技術的限制在大型系統實施時，第一要對用戶現場的現狀及用戶需求做詳盡的描述。通常由于用戶人員對自己的業務明白得還在不斷的深化，因此往往在實施應用系統時用戶對需求的描述會隨實在施的不斷深切而有所改變，造成系統需求的不穩固。為幸免此風險，可按以下方式實施：1. 第一時期：在其它項目上的體會的再利用2. 所擁有的資深專家在項目實施進程中，將技術教授給項目小組。3. 客戶項目小組的通力合作和大力支持。2).實施范圍的不斷擴大及項目延期通常在實施進程中，用戶會對項目開始時所提出的目標和要求有所轉變，造成實施范圍的不斷擴大和項目實施的延期，最終使項目擱淺。為幸免這種情形的發生，咱們應該：1. 成立項目實施治理小組，明確項目的目標和各自的權限；處置項目實施的本錢，明確預算操縱。2. 配備體會豐碩的項目領導。3. 按期向項目的高層治理部門和用戶報告項目實施的進展及存在的問題。4. 操縱實施范圍的轉變──形成書面文檔、陳述更改緣故，待高層治理部門批準后方可實施更改。5. 成立當項目實施顯現問題時進行匯報和解決的標準工作流程。3).缺乏多廠商之間的彼此和諧和各廠商所負的責任不清1. 項目實施所涉及的廠商很多，包括硬件、數據庫、應用軟件、第三方軟件、網絡或集成商等，在項目實施進程中需要多方和諧、通力合作，只有如此才能保證項目保質保