數(shù)據(jù)庫應用程序遷移所帶來的問題

從一臺32核CPU,30G內存，800M硬盤的機器上。遷往到雙節(jié)點RAC機器上，該機器每個節(jié)點8核CPU 是雙核*4.硬盤和內存沒什么變。 聽起來是遷往一臺高性能機器上，很令人興奮不已，雙節(jié)點哦！ 實際上效果并非如此，其中一個節(jié)點被另外個數(shù)據(jù)庫所占用，也就是那臺節(jié)

從一臺32核CPU,30G內存，800M硬盤的機器上。遷往到雙節(jié)點RAC機器上，該機器每個節(jié)點8核CPU 是雙核*4.硬盤和內存沒什么變。

聽起來是遷往一臺高性能機器上，很令人興奮不已，雙節(jié)點哦！

實際上效果并非如此，其中一個節(jié)點被另外個數(shù)據(jù)庫所占用，也就是那臺節(jié)點基本上不能全力去工作，相當于單節(jié)點。反而承擔多節(jié)點管理工作！

UNDO和TEMP 采用兩個來切換，而且每個比原來的小上10G。原來都32GUNDO和32GTEMP。

其中暴露出一些存儲過程的SQL性能問題，比如占用太多的UNDO,TEMP和DB FILE SEQUENCE READ。

知道LEFT JOIN , MEGR INSERT 比 DELTET 和INSERT INTO 慢些，可數(shù)據(jù)很可靠!

老大原本想花三天遷移完的，實際上用了9天的時間。主要是發(fā)現(xiàn)存儲過程中語句業(yè)務邏輯缺失些數(shù)據(jù)，沒有完全從其他庫上獲得完整。

找這個問題所在，用老辦法全量從源庫 insert into xxxx@tooldb，或者從業(yè)務庫再次全托。

搞這事真累！ 很多事覺得做的很白費，瞎折騰。民營企業(yè)都這德性，中層或者高層下達工作指令時候都是交給你任務，馬上就問什么時候完成。

你回答一個時間，他不滿意，就說這個時間太長了，就說出他的希望的時間，基本上是在你的時間上縮短50%-80%。你跟他爭一點，他就說你態(tài)度不好！他說這個工作很緊只有幾個星期時間。

其實他們想得比較簡單，這工作就這么幾下，分分鐘的事情；或者以他的技術能力速度來考慮；或者他想不到干這事中會遇到技術和業(yè)務問題；或者他沒想到你除了干這事，還要干其他的事，被其他瑣事的事干擾！

民營企業(yè) 強調的是執(zhí)行力，溝通能力，主動能力，人的主觀能動性，樂觀向上積極奉獻。

反過來想，民企企業(yè)創(chuàng)業(yè)時一無所有，或者少有的條件，只有靠老板等老大們 發(fā)揮自己主觀能動性。不過這作風會一直延續(xù)下去，并且影響到招人和用人傾向！

想想自己 從中能獲得些經驗吧！也算是心理安慰，老板也沒少給錢，雖然做出來的東西還是被人棄之一邊，或者被其他同事重構掉！

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯(lián)系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com