Các cách thức backup & recovery trong Oracle [Archive]

View Full Version : Các cách thức backup & recovery trong Oracle

Sigmasvn

04-10-2006, 14:58

@kendo,fire2fire,vncoding,netazy :
Từ chủ đề OCP Thất nghiệp mà chúng ta đã đến chủ đề "Backup & Recovery trong Oracle" :)
Để bắt đầu chủ đề nay, mình đặt lại vấn đề của fire2fire để cùng thảo luận nhé :

Mình đang xây dựng các phương án backup, restore nên cần các bạn tham vấn thêm. Không nói chuyện cách làm cũ nữa. Bên mình có 2 cluster, 1 chạy RAC, 1 không, cả 2 đều hoạt động 24h*7, cả 2 đều có backup bằng RMAN, export và bằng 1 phần mềm chuyên backup ra tape. Vấn đề là khi xảy ra sự cố, 1 máy phải được dùng để thay thế máy kia trong thời gian máy gặp sự cố được recover, sau khi máy chính được recover rồi thì quay trở lại máy chính, đưa số liệu phát sinh mới apply thêm vào. Nếu mình có máy dự phòng có cùng cấu hình cho cả 2 hoặc 2 máy cấu hình giống nhau thì mình sẽ tổ chức standby DB nhưng hiện tại mình chỉ có thể dùng import để làm việc này. Vì vậy mình mới cần biết RMAN có thể chép DB ngang từ bản backup sang máy khác để mình dựng DB lên không ? Theo các bạn thì sao?

fire2fire

04-10-2006, 15:36

Đọc lại yêu cầu thấy hơi lung tung nhỉ.

Chỉnh lại 1 chút nhé:

Với 1 mô hình như mình nêu thì phương án backup, tổ chức hệ thống, recovery, đảm bảo toàn vẹn dữ liệu như thế nào là hợp lý ?

kendo

04-10-2006, 20:09

Dear F2F! Thành thực mà nói, với mô hình OLTP như bạn, vấn đề sự cố xảy ra là không tránh khỏi, đúng là phải nên có một hệ thống chạy song song, vừa đặt ra các tình huống lỗi, vừa tìm ra phương án khắc phục lỗi nhanh nhất, và nó cũng là phương án dự phòng hoàn hảo nếu trong trường hợp thời gian khắc phục kéo dài! Có điều ngân sách tài chính có thể là lý do, nên chúng ta phải tính toán đến toàn bộ mọi thứ liên quan sao cho phù hợp với yêu cầu công việc nhất!
Theo mình, chúng ta cân nhắc phương án tổ chức hệ thống trước. Vì backup ra tape, nên dữ liệu thất thoát hoàn toàn có thể restore hoặc recover lại được, kể cả ở thời điểm khá xa. Mọi người cho ý kiến nhé!
Cảm ơn vì cho mình sự lắng nghe!

Sigmasvn

04-10-2006, 20:50

Trước khi cùng nhau xây dựng mô hình cho F2F,mình muốn hỏi rõ 1 số điểm

Bên mình có 2 cluster, 1 chạy RAC, 1 không, cả 2 đều hoạt động 24h*7
vậy ht RAC chỉ là 1 server thôi, và 1 ht khác là 1 server chạy stand-alone? Và dữ liệu trên 2 server này hoàn toàn khác nhau ?

cả 2 đều có backup bằng RMAN , bạn backup Rman là dùng control file hay catalog trong một dbs khác(catalog dbs)

export hiện giờ bạn vừa export ra dump file và vừa backup bằng Rman ?

Vấn đề là khi xảy ra sự cố, 1 máy phải được dùng để thay thế máy kia trong thời gian máy gặp sự cố được recover nếu như vậy thì máy để thay thế sẽ mất dữ liệu hiện tại của nó !!!?

@F2F, bạn có thể mô tả lại vấn đề cho rõ hơn được ko :) Thanks

kendo

04-10-2006, 22:44

F2F tối nay chắc bận mất rồi, tiếc thật!

Sigmasvn

05-10-2006, 06:44

$> tail -f alert_F2F.log

Ora-*** can not get error code
------------- instance bummmm ......................

SQL> startup
can not locate init file
can not locate control file
can not locate data file
can not ............................. open database
can not contact @F2F

fire2fire

05-10-2006, 08:21

Tối mình về nhà rồi, nhà mình ở Chắc Cà Đao, không có net :)

Mình xin nói rõ hệ thống bên mình nhé (xin sếp tha thứ tội lỗi cho em :( )

- 2 cluster có nghĩa là 2 hệ cluster, mỗi hệ gồm 2 server, 1 share disk array ở giữa. Vậy tổng cộng là 4 server.

Cluster A chạy RAC: trên mỗi node có 2 Oracle DB server, tổng cộng là 4 DB server, raw devide disk
DB1 phục vụ cho 4 hệ chương trình (application), đây là mảng quan trọng nhất, thời gian ngưng của DB1 phải giảm tối đa.
DB2 phục vụ cho 3 hệ chương trình, đây được xem như mảng quan trọng thứ 2, thời gian ngưng của DB2 có thể kếo dài hơn DB1 nhưng tốt nhất là không quá 1 ngày.

- Cluster B không chạy RAC, được tổ chức theo cơ chế active - standby, file system disk. Trên mỗi node cũng có 2 DB server, tổng cộng là 4 DB nhưng tại một thời điểm chỉ có 1 node active nên chỉ có 2 DB hoạt động. DB3 phục vụ 1 hệ chương trình nhưng đa số là dữ liệu cũ để lại cho tra cứu, dữ liệu mới phát sinh không cao. DB4 phục vụ 2 hệ chương trình. Các chương trình này đang xây dựng và chạy thử nghiệm. Như vậy DB3 và DB4 có thể ngưng vài ngày nhưng dữ liệu thì không được để mất.

RMAN chạy dựa trên controlfile, không dùng catalog.

Khi xảy ra sự cố, chủ yếu là giải quyết cho DB1 thì có thể bỏ DB3 thay thế bằng DB1 hoặc import thêm vào và chuyển cả 4 hệ chương trình sang kết nối đến DB3, tương tự cho DB2 và DB4.

Sigmasvn

05-10-2006, 08:41

.. analyzing ...... will reply asap :)

Sigmasvn

05-10-2006, 09:44

Sáng nay mình hơi bận, phải convert một hệ thống RAC cũ về lại SINGLE datbase, và bị mấy cuộc họp nó hành :(
Cố gắng hôm nay sẽ đưa ra mô hình để mọi người thảo luận nhé.
@kendo : có ý kiến gì về hệ thống và yêu cầu của f2f không ?

kendo

05-10-2006, 13:10

Hiện tại thì mình không (chưa) có ý kiến j về hệ thống của F2F. Mình đang thử hình dung phương án nào được cho là có hiệu quả trong trường hợp DB1 xảy ra lỗi.
DB1 là DB dành cho application hoạt động với chính dữ liệu của khách hàng, do đó, việc backup các data file, control file, redo log file và archive log file sẽ generate theo thời gian. Sorry vì mình chưa có kinh nghiệm thực tế, nên mình chỉ phỏng đoán là chủ yếu.
DB3 và DB4 theo mình hiểu thì là DB phục vụ cho query và report hàng tháng.

Sigmasvn

05-10-2006, 14:26

Cluster A chạy RAC: trên mỗi node có 2 Oracle DB server, tổng cộng là 4 DB server
Mình hơi thắc mắc chỗ này chút,xét ở hệ cluster A, mỗi node(là A-node1 hoặc A-node2) có 2 db,thì sẽ có tổng cộng 4 db, thì ít nhất là trong hệ cluster A sẽ phải có ít nhất 8 instance,do mỗi db sẽ phải có 2 instance,1 ở A-node1 và 1 ở A-node2, theo đúng ý nghĩa của RAC. Mình hiểu hệ thống của bạn như vậy có đúng không?

Bây giờ trở về vấn đề backup & restore .

1.Backup: cách backup bằng Rman thì ok.
Bạn backup Rman cho từng db từ một instance của db đó phải không? Nếu bạn làm như vậy thì ok, vì chỉ cần backup từ 1 instance thôi vì dùng share disk.
Nhưng nhớ tên của các tập tin backup file nên tường minh, dễ bị lầm lẫn giửa các dbs, hậu quả sẽ tai hại.

TUY NHIEN,có 1 vấn đề nghiêm trọng: Vì bạn backup Rman bằng CONTROLFILE, là lưu thông tin backup trong controlfile, thì khi DBS chứa control file đó bị hư, thì bạn không thể nào restore được các backup file từ Rman.

GIAI PHAP : Vì thế, bạn nên xem xét việc dùng một database khác, setup catalog , để từ đó bạn có thể backup cho nhiều dbs khác nhau.Và bạn chỉ cần export catalog ra dump file để backup.

Khi DBS chính bị hư, thì bạn chỉ cần lấy backup file + thông tin đã lưu trử trong catalog để restore lại.Nếu dbs chứa catalog bị hư thì vẫn còn dump file do bạn export ra.
->>>> Bạn nên nghiên cứu cách sử dụng catalog trong Rman

(sẽ ý kiến tiếp phần Restore , bây giờ đi ăn trưa tý :) )

Sigmasvn

05-10-2006, 15:29

Bây giờ tiếp phần Restore :

Về nguyên tắc bạn sẽ recover được dữ liệu từ DB1 về DB3 (là move dữ liệu từ RAC vê SINGLE), nếu như bạn nắm được các khái niệm ,thao tác sau :
1. khai báo thread trong file init parameter , để chỉnh lại thread trong Db3 tương ứng với thread(instance) trong RAC mà bạn dùng Rman để backup
Bạn nên lưu lại tập tin init parameter(text) bên RAC.
Nếu như thế là bạn đã start được instance bên Db3
2. Cách restore file backup dùng catalog từ RMan
3. Cách chuyển dữ liệu từ RAC về SINGLE. May wá, mình vừa làm sáng nay,nên có thể ghi chú lại cho bạn liền.Mình làm trên Linux

a. Shut down instances
b. cd $ORACLE_HOME/rdbms/lib
chạy câu "make -f ins_rdbms.mk rac_off ioracle"
c. Sửa lại parameter file, bỏ các tham số liên quan RAC như:
cluster_database,instance_name,instance_number,thr ead,undo_tablespace

d. Start instance & open database

e. Sau đó có thể DISABLE các thread ko còn sử dùng, và các REDO LOG, UNDO TBS ko sử dụng.

Tóm lại, là bạn nên xem các ý mà mình nói, như mình nói từ ban đầu : PHẢI NẮM NGUYÊN LÝ HOẠT ĐỘNG.

Chỗ nào bạn cần mình giải thích thêm thì cho biết nhé.Welcome :)

fire2fire

06-10-2006, 08:32

Mình hơi thắc mắc chỗ này chút,xét ở hệ cluster A, mỗi node(là A-node1 hoặc A-node2) có 2 db,thì sẽ có tổng cộng 4 db, thì ít nhất là trong hệ cluster A sẽ phải có ít nhất 8 instance,do mỗi db sẽ phải có 2 instance,1 ở A-node1 và 1 ở A-node2, theo đúng ý nghĩa của RAC. Mình hiểu hệ thống của bạn như vậy có đúng không?

Cluster A và B đều là 4 instance, 2 DB. RMAN chỉ chạy trên 1 node là đủ.
Mình sẽ tìm hiểu thêm về RMAN với cách dùng catalog

Cho mình hỏi rõ lại bạn cách backup nhé:

1. Nếu mình dùng DB3 làm catalog cho DB1 thì:
- Khi backup có phải là đứng tại node 1 của cluster A chạy RMAN không, vì đường dẫn file backup là trên node 1 của cluster A luôn, sau đó chép ra tape. Vậy nếu cluster A hư thì từ tape chuyển sang cluster B rồi restore được không. Mình hỏi như vậy vì mình thấy RMAN chỉ có lệnh restore mà không chỉ đường dẫn của source và dest.
- Cluster A dùng raw device disk, khi backup thì mình thấy RMAN tạo ra file system, vậy khi restore sang nơi khác thì sẽ như thế nào ? Mình chưa hiểu lắm về raw device.

2. Theo mình biết thì 1 catalog có thể dùng để lưu thông tin backup của nhiều DB, vậy mình dùng DB3 làm catalog cho DB1 và backup DB3 bằng RMAN trên control file được không ? Khi dùng DB3 làm catalog cho DB1 thì cách backup dùng RMAN dựa trên controlfile của DB1 vẫn giữ như cũ được không ? Mình không muốn thay thế cách backup hiện nay mà là thêm 1 phương án backup nữa.

3. Standby DB khi mình làm trên 8i thì đòi hỏi 2 DB cấu hình giống nhau. Còn trên 9i thì với cluster B có thể tổ chức DB3 làm standby cho DB1 không (cấu hình khác nhau, OS khác nhau)? Nếu được thì mình sẽ chuyển toàn bộ dữ liệu của DB3 sang DB1. Như vậy sẽ làm nặng DB1 nhưng có thể được.

Phần restore thì nếu mục 1 trên giải quyết được thì OK, các bước chuyển tiếp theo mình sẽ thử như bạn hướng dẫn.

Mong rằng sắp tới có thêm máy cho mình thử chứ nếu cả 2 đều đang hoạt động thế này mà làm thì hơi phiêu lưu.

Sigmasvn

07-10-2006, 08:45

@f2f : Hehe,cả ngày hôm qua,shutdown công việc, dẫn công chúa 14 tháng đi chơi Trung Thu, nên chưa trả lời sớm cho bạn. :)
1. Nếu như bạn dùng catalog rồi, thì bạn có thể đứng từ máy nào cũng được , miển sao là bạn có thể connect vào TARGET và CATALOG.
rman targat Sys/pwdsys@TARGET catalog Rman/pwdrman@CATALOG
2. Raw device: chỉ là một đường dẫn map với một datafile cụ thể.
Thật tiếc,là mình chưa làm backup Rman từ TARGET là raw devide để restore vào DBS là file system cả,nên không trả lời bạn được.Sorry.Mình nghĩ là DBS chắc cũng phải set up là raw device tương ứng.
Để mình search vấn đề này trên metalink.Mong là có cách giải quyết.
3. Bạn có thề dùng DB3 để lam catalog backup cho DB1,và giữ cách backup control file như hiện tai.Không sao cả.Vì thông tin về backup được lưu độc lập mà, và do khi bạn register database.
4. Để làm standby dbs thì mình ko nhớ rỏ điều kiện, nhưng mình nhớ là cần phải giống O/S.Vê tên dbs, cấu trúc thư mục thì có thể khác , vì mình được set thêm tham số trong parameter file. Bạn có thê xem ở đường link này
http://www.lc.leidenuniv.nl/awcourse/oracle/server.920/a96653/toc.htm

kendo

07-10-2006, 09:52

@F2F: Nếu bạn cần tài liệu về RMAN, mình sẵn sàng chia sẻ với bạn.
Nhân tiện, cũng xin hỏi luôn 2 bạn: Trong môi trường thực tế, thông thường thì DBA sẽ chọn cách backup nào thông dụng hơn giữa Whole backup và Full backup và giữa Backup sets với Incremental backup?
Xin cảm ơn!

Sigmasvn

07-10-2006, 15:06

@kendo : Trong thực tế thì DBA sẽ phải chọn cách backup/restore tùy thuộc vào cấu hính phần cứng,khả năng DBA và yêu cầu mức độ an toàn dữ liệu của doanh nghiệp.
Với hệ thống mình đang làm thì cách thức cơ chế như sau:
- trước khi chạy batch cuối ngày thì đều SHUTDOWN Production dbs để backup FULL.
Việc backup này dựa trên snapshot của hardware, và có tính incremetal nên dư liệu hiện giờ khoảng 230G thì chỉ khoàng 4-6.
phút là xong. Bản backup này chỉ dùng để sau này nếu User cần dữ liệu test thì restore lại full dbs vào môi trường UAT
- Sau khi chay batch xong thì sẽ clone để tao một Standby dbs và snap để tạo một Report Dbs.
Hehe, cách thức backup của mình đơn giản quá phải không :).Mình đã nói là phụ thuộc vào công nghệ phần cứng và yêu cầu dữ liệu(là ko mât dữ liệu,ko cần phải chạy 24*7).Nếu sau này bắt buộc 24*7 thì tính tiếp.
Tuy nhiên, nếu về phần cứng ko đủ dieu kien, thì Rman ( cả backupset, incremetal) vần that sự là cách backup tốt, vì trước day mình thường làm.

kendo

07-10-2006, 21:21

@sigmasvn: Cảm ơn bạn đã trả lời mình. Có một số khái niệm bạn nêu, nhưng thành thật xin lỗi vì mình không biết (snapshot hardware và UAT enviroment - có lẽ mình sẽ tự tìm hiểu sau, hơn là làm phiền bạn giải thích).

Không hiểu mình nghĩ thế này có đúng không: Trong trường hợp thực tế với DB chạy 24*7, RMAN mới là cách khả dĩ nhất, vì nếu dùng User Managed Backup, ta phải shutdown Instance để recovery control file, data file, redo log file, tablespace...

fire2fire

09-10-2006, 08:18

@Kendo:
Tài liệu RMAN của bạn là của Oracle hay của NXB khác viết, nếu là của hãng khác thì làm phiền bạn gửi cho mình với, email: fire2fire03@yahoo.com, mình cảm ơn trước nhé. Còn nếu đó là tài liệu của Oracle thì mình có bộ documentation của Oracle rồi.

Cảm ơn các bạn đã đóng góp ý kiến, mình sẽ xem kỹ lại RMAN để xem các giải pháp khả dĩ.

Sigmasvn

09-10-2006, 08:44

@kendo : snapshot là một công nghệ trên SANs, thực sự thì mình cũng không rành lắm,chỉ biết xài thôi, còn phần setup là do một nhóm khác làm :).
UAT : chỉ là môi trường dùng để test thôi bạn, User Accept Testing.

vncoding

09-10-2006, 11:37

@kendo:
Ở đây có hướng dẫn cụ thể tạo physical standby db:

http://www.utexas.edu/its/unix/reference/oracledocs/v92/B10501_01/server.920/a96653/create_ps.htm

Nếu ông tạo locally hãy chú ý tham số: lock_name_space.

Ở đây có hướng dẫn cách kiểm tra xem standby db hoạt động ổn không:

http://www.adp-gmbh.ch/ora/data_guard/verify_environment.html.

kendo

09-10-2006, 12:34

@F2F: Mình chỉ có tài liệu RAC của Oracle. Hiện tại cũng đang tìm thêm tài liệu của hãng khác. Mình tìm được sẽ send luôn cho bạn.
@sigmasvn: Cảm ơn bạn rất nhiều.
@vncoding: Chẳng biết nói gì nữa, cảm ơn nhiều thì khách sáo quá, chúc công chúa của ông hay ăn, chóng lớn nhé.

Sigmasvn

09-10-2006, 14:10

@vncoding :site mà bạn gửi hay, thông tin cần thiết.
@ALL : cái thread này lập ra là để thảo luận về backup/recovery,nay mình muốn tóm lại một số điểm sau mà DBA cần biết (thực ra cũng là nói tới nói lui thôi :)
- nắm được cấu trúc hệ thống dữ liệu cùa mình như bao gồm bao nhiều tablespace , datafile ,redo file, control file lưu như thế nào => để biết chỗ mà maintain cho đúng.
- Dbs cần phải chạy ở chế độ ARCHIVE .
- Tùy vào yêu cầu mà có thể backup ONLINE hay OFFLINE
- DBA cần học cách backup/restore bằng RMAN, và các trường hợp xử lý thông thường (có thể đọc trong tài liệu học thi của Oracle).Quan trọng : phải thực hành đề hiểu được nguyên tắc.
- Nếu dùng Rman thì nên dùng CATALOG
- Nếu không dùng Rman thì cũng nên học cách User Managed (cũng xem tài liệu Oracle luôn :))
- Nếu có điều kiện thì nên setup 1 hệ thống STANDBY database.

Ai có ý kiến gì thêm thì bổ sung nhé.
Mình đinh dừng việc thảo luận bk/rec ở đây để chuyển qua một thread bàn về RAC.Nhiều bạn có thể không có điều kiện để làm về RAC, nhưng nếu nắm về cơ bản,hiểu được ý nghĩa của nó thì cũng tốt. Các bạn thấy sao ?

fire2fire

10-10-2006, 09:20

Mình bó tay với mấy cái DB của mình rồi, thôi thì chuyển chủ đề vậy.

Chuyển qua RAC cũng hay, nhưng mình không rành, cái cluster của mình được cài sẵn, bây giờ nó mà nhức đầu sổ mũi chẳng biết đâu mà lần. Bạn có thể giới thiệu 1 cách tổng quan cho mọi người nắm được không?

Mình đề nghị thế này nhé, sau một vài chủ đề dạng overview, chúng ta sẽ đi vào các nhiệm vụ cụ thể. Ví dụ như: công việc hằng ngày của 1 DBA, khi gặp sự cố thì kiểm tra tuần tự thế nào, khi DB xử lý chậm thì bắt đàu từ đâu để tuning. Những cái này trong tài liệu thì có nhưng đi xuôi theo lý thuyết. Bây giờ mình thử đi ngược từ thực tế đi.

kendo

10-10-2006, 10:26

Nếu F2F đã đề nghị như thế, thì mình cũng xin có ý kiến thêm:
- Box Ora bản thân trong ddth cũng ít người tham gia discuss, nếu như thế thì thời gian cũng không phải là gấp gáp cho lắm đối với từng câu hỏi.
- Với mô hình Real Application Cluster (RAC) trừ những ai đã học, làm việc thực tế thì mới có một cái nhìn sâu sắc hơn, còn người khác thì lại không có được ưu thế như vậy. Do đó, mình đề nghị, nếu đã mở một thread riêng về RAC, chúng ta nên dành 1 thời gian, khoảng 1,5 cho đến 2 tuần nhằm tiếp cận kiến thức cho người mới và củng cố lại kiến thức cho người đã biết.
- Tổng quan về mô hình RAC sẽ do một người phụ trách đưa lên sau khi đã có đủ thời gian tìm hiểu và tìm hiểu lại. Điều này sẽ do chúng ta thảo luận và bình bầu. Hiện tại mới chỉ thấy có 4 người là sigmasvn, f2f, vncoding và mình, nếu ai đó muốn tham gia tiếp thì xin mời đăng ký thêm nhé.
- Một khi thread đã được đưa lên, thì phải bàn luận vấn đề sao cho cặn kẽ nhất có thể, không chỉ dựa vào một hoặc hai mô hình của các bạn để đưa ra kết luận mà phải đánh giá ở mọi góc độ khác nhau, các tình huống thông thường xảy ra...

Ý kiến trên của mình, mọi người thấy thế nào?

lotomo

13-10-2006, 14:55

Các bác cho tôi tham gia với nhé, chủ đề này rất hay. Tôi cũng có nhiều câu hỏi mong các bác giải đáp giúp ;)

nmha174

13-10-2006, 16:04

Bài toán thực tế:
Có 2 máy chạy cluster với 1 DB Oracle 10g, có một cặp máy chủ khác để dự phòng ở một chỗ khác. Mục đích muốn làm sao khi hỏng máy chủ, SAN sẽ dùng cặp máy dự phòng thay thế làm sao để thời gian khắc phục là nhanh nhất.

kendo

14-10-2006, 12:33

@nmha174: Mình vẫn chưa hiểu câu hỏi của bạn. Mình thử đưa ra một vài phân tích như thế này nhé:

1/ 1DB chạy OLTP hoặc có thể là Datawarehouse (nhưng có lẽ DW thì không cần thiết đến mức có một máy chạy dự phòng), OK? Và một Server chạy song song, có 1DB y hệt như thế.. Vậy thì câu hỏi đặt ra là:
- Chính sách backup và recovery của DB chính được hoạch định như thế nào? Restore và Recovery từ thẳng Tape (hoặc other Devices) được xử lý ra sao? Chính sách này phải được test cẩn thận, dự kiến các trường hợp gần như có thể xảy ra. Lấy ví dụ: Backup có 2 kiểu backup (Physical và Logical). Trong trường hợp nào thì ta dùng hệ thống dự phòng, bởi vì đối với một số phần recover Logical, ta hoàn toàn có thể recover ngay kể cả khi DB vẫn online. Tất nhiên trong một số trường hợp khác, DB bắt buộc phải để offline.
- Hệ thống dự phòng là một hệ thống được cấu hình sao cho y hệt như với hệ thống chính, mục đích của hệ thống dự phòng là thử nghiệm các phương án khắc phục lỗi tại thời điểm DB chính ít bị thao tác tới cấu trúc nhất. Và một trong những mục đích quan trọng không kém của hệ thống dự phòng là thay thế hệ thống chính khi và chỉ khi hệ thống chính bắt buộc phải để ở chế độ offline (Crash of Primary DB chắc là ít khi xảy ra, bởi vì chính sách cho Pirmary DB phải chặt chẽ đến mức tối đa nhất). Do đó, the Second DB chiếm một vai trò quan trọng trong công việc thay thế này.

2/ Để gây ra lỗi không hề đơn giản chút nào cả. Lỗi do khách quan hay chủ quan thông thường sẽ được test trên hệ thống dự phòng thứ cấp (giả sử có thêm một hệ thống dự phòng nữa) hoặc hệ thống dự phòng duy nhất. Vấn đề đặt ra là ngay cả việc gây lỗi và khắc phục lỗi trên hệ thống dự phòng này cũng nằm trong công việc hoạch định cụ thể, cả về chính sách backup lẫn recovery. Thông thường bản thân hệ thống dự phòng cũng phải được Whole backup bằng RMAN (hoặc bằng một soft khác của hãng thứ 3).

- Một phần nữa, mà tôi hình dung là cách nmha174 hỏi rằng : Cách thức kết nối ra sao giữa một middler tier với cả 2 hệ thống DB? Nếu như vậy thì việc kết nối giữa hệ thống chính và hệ thống dự phòng giống hệt nhau. Việc 2 hệ thống đặt ở đâu không quan trọng, quan trọng ở việc configure Listener ra sao mà thôi. Bởi vì về bản chất, khi Configure 1 Listener, ta hoàn toàn có thể làm thêm một Instance hoặc 1 DB khác, sử dụng Listener này.

P/S: @sigmasvn, F2F..: Mình vẫn đang xem xét RAC, hiện tại điều kiện không cho phép, nên không thể online thường xuyên đươc như trước. Vấn đề thảo luận về RAC, mình sẽ cố gắng tham dự discuss. Có một vấn đề nhỏ nữa mình vẫn đang băn khoăn: Configure RAC thì DB sẽ được hiểu như Share Server hay Dedicate Server? Cảm ơn mọi người đã trả lời.
Chúc vui!

nmha174

15-10-2006, 01:36

Nmha174 xin giải thích rõ hơn
- Cặp máy chủ chính đặt ở DataCenter (2 máy chủ chạy cluster) ở đây chứ database (DB01) chính cần phục vụ 24/7 cho các dịch vụ. Luôn có giao dịch phát sinh. DB01 để Archive, được physical backup online một ngày một lần, PUMP 1 ngày 1 lần vào buổi tối (backup ra vùng đĩa trên SAN rồi đưa ra TAPE).
- Cặp máy dự phòng giống hệt cặp máy ở DataCenter để dự phòng gọi là DB2. Nằm cách DataCenter 10 KM. Nối giữa DB01 và DB02 là đường cáp quang 1G.
Mục đích vì lý do nào đó, DB1 trong datacenter bị down hoặc SAN lỗi, cháy nổ...Muốn dựng DB02 lên để thay thế để phục vụ cách dịch vụ như DB01. Muốn có một giải pháp hợp lý nhất cho tình huống này.
Các bác tư vấn cho chú với.

kendo

15-10-2006, 09:54

Mình xin chờ nghe ý kiến của mọi người về việc thảo luận phương án của nmha174.
Nhân tiện cũng có một thắc mắc nhỏ:
- Như ta đã biết, trong Oracle 9i, để recover lại một DB thuộc một incranation là không thể, và bắt buộc phải OpenResetLogs. Vấn đề ở đây là mình đọc tài liệu Backup và Recovery của Oracle 8, thì lại thấy có hướng dẫn cụ thể việc Restore lại một Previous Incarnation khác. Script restore mình không nhớ cụ thể (sorry vì không ngồi máy ở nhà nên không lấy script ra được), trong RMAN thì chỉ việc search ra các Incarnation trước.
Lấy ví dụ: RMAN> List Incarnation of Database; Sau đó đóng RMAN tạm thời để chuyển sang host: RMAN> host; Tiếp đó dùng lệnh move của OS để locate datafile, control file hiện thời sang chỗ khác. Bước cuối cùng là chạy script để Restore lại Incarnation trước đó.
Mình băn khoăn một điều rằng: Tại sao trong Oracle 8 lại có thể thực hiện được điều này, trong khi Oracle 9i thì lại không được? Mình đã thử cẩn thận lại trên Oracle 9i, lỗi chắc chắn xảy ra. Với Oracle 8 thì mình chưa có điều kiện thử. Ai đó đã test rồi thì xin giải thích lại dùm mình vấn đề này nhé.

Cảm ơn mọi người rất nhiều!

Sigmasvn

15-10-2006, 11:01

woa, cả tuần nay mình bận phải ngâm cái thằng Siebel, bây giờ có thể thảo luận tiếp về vụ này rồi.Hehe, nhưng hôm nay chủ nhật, phải chở công chúa đi chơi cái đã, rồi về mới tính tiếp . cho spam tý. :)

nmha174

17-10-2006, 09:35

Chắc bác Sigmasvn đưa công chú sang nhà bà ngoại rồi ợ lại luôn bên đó roài. Khi "lào" về bác nghiên cứu tiếp vụ "lày" cho chú nhé.

kendo

17-10-2006, 23:13

Nhma174 có thể giới thiệu sơ qua về chiến lược backup của bên bạn không?

nmha174

20-10-2006, 00:14

@KENDO Mình đang đi học nên hơi bận, hẹn Kendo tuần sau đi học về sẽ trả lời câu hỏi của bạn.
Trân trọng,
nmha174

nmha174

27-10-2006, 13:35