Archive for August, 2010

Database Migration

August 30, 2010

Database Migration là một trong những công việc thường gặp của DBA (Hôm trước mình cũng bị hỏi câu này :)). Thông thường, khi đi triển khai, thường là mình mang một database có sẵn đến site của khách hàng, deploy vào rồi sau đó mới chỉnh sửa data theo yêu cầu.

Ở SQL Server thông thường có 2 cách.

  • Một là backup database ra file bak sau đó restore trên máy khác.
  • Hai là shutdown database sau đó copy file mdf và ldf rồi attach trên máy mới là ta có thể có 1 database tương tự như source.
  • Ngoài ra có thể có một số third-party hỗ trợ, nhưng ít dùng vì 2 cách trên vừa đơn giản vừa dễ dùng.

Tất nhiên vì là đồ M$ nên chuyện multi platform là no-table.

Ở Oracle thì có nhiều giải pháp hơn. Và cũng thường ít khi phải care đến vấn đề OS. Chúng ta có thể xem xét một số giải pháp như:

  • Export/Import: export ra file dump, sau đó dùng import lại. Đây là một trong những cách hay được sử dụng nhất vì tương đối đơn giản lại khá mạnh, không phụ thuộc vào OS. Bạn có thể export trên máy chạy Windows sau đó import trên máy chạy Linux/Unix mà không ảnh hưởng gì đến dữ liệu bên trong. Tuy nhiên nó chỉ chạy được với điều kiện database size cỡ GB, chứ lên đến TB thì không khả thi (@Saravanan Shanmugan – OCM & James Madison – PM and Application Architect for Migration)
  • Data Pump: Phiên bản nâng cấp của Export/Import, bắt đầu có từ phiên bản Oracle 10g. Data Pump chạy nhanh hơn và có một số cải tiến như dùng tablespace metadata để thực hiện các thao tác migrate thông qua network link, rồi khả năng restart job… Nói chung, do sinh sau đẻ muộn nên nó kế thừa đầy đủ các tính năng của Export và Import ở cấp độ mạnh hơn tương đối. Tuy nhiên, khi đối mặt với dữ liệu cỡ TB thì chú này cũng khóc. Thí nghiệm của Saravanan và James: 15GB thì datapump hết 11 mins, tuy nhiên 7 TB thì hết những 93 hours 😦 trên cùng một cấu hình phần cứng
  • CTAS (Create table as Select): Cách này cũng được nhưng không thích hợp với vai trò của DBA vì phải tìm hiểu cấu trúc database (diagram, schema…) quá nhiều. Quên mất, cái này cũng có thể dùng với MS, nhưng ít người làm theo cách này
  • Third –party: chung số phận với third party của MS
  • Transportable tablespace (TTS): Tên đầy đủ là Cross Platform Transportable Tablespace Technology XTTS. Đây là một trong những feature mình muốn nói đến nhất trong chủ đề này. Khi bạn có một yêu cầu migration một database cỡ vài TB trong một thời gian ngắn, thì đây chính là giải pháp tối ưu nhất. Cơ chế hoạt động của công nghệ này như sau:
    • Set source tablespace về Read only
    • Dùng RMAN để copy các tablespace đến target database. Nếu có sự khác nhau về endian format, sử dụng lệnh RMAN Convert để chuyển đổi.
    • Thực hiện các thao tác để đưa các tablespace này vào target database
    • Set cả source lẫn target về trạng thái bình thường (Read Write )

Công nghệ này đã có từ phiên bản Oracle 8i, nhung khi đó chỉ cho phép move giữa các Oracle database có cùng data block size và cùng platform. Sang version 9i, Oracle khắc phục được điểm cùng block size, tuy nhiên vẫn chỉ cho phép move trên cùng platform.  Và ở phiên bản 10g, Oracle phá bỏ được cái Barrie cuối cùng này bằng cách sử dụng công nghệ Cross Platform TTS.

Ưu điểm của công nghệ này là:

  • Move tablespace giữa các heterogeneous OS
  • XTTS chỉ là high-level copy of data
  • Giảm thiểu lỗi thiếu bảng hoặc thiếu dữ liệu. nó chỉ có trạng thái: hoặc là thành công, hoặc là thất bại, không có trường hợp thiếu
  • K cần rebuild lại indexes
  • Endian convert nếu có chỉ chậm hơn 3% so với thao tác copy của OS
  • Không cần recollect các statistic

Nói chung giải pháp TTS tương đối hay, tuy nhiên theo ý của mình, DBA nên cưng cứng 1 tý thì khả thi hơn. Cũng không nhất thiết lúc nào cũng phải dùng giải pháp này, nếu dữ liệu vừa vừa thì nên dùng Exp/Imp hoặc Expdp/Impdp.

Trên đây mình đề cập đến 2 trong số database hay được sử dụng là MS SQL Server và Oracle. Còn DB2 của IBM thì mình sẽ nghiên cứu và cập nhật sau. 🙂

30 Aug 2010

HN

References:
1. Oracle Cross Platform Transportable Tablespace
http://www.oracle.com/technology/deploy/availability/htdocs/xtts.htm
2. Oracle Recovery Manager – RMAN
http://www.oracle.com/technology/deploy/availability/htdocs/rman_overview.htm
3. Data Pump
http://www.oracle.com/technology/products/database/utilities/htdocs/data_pump_overview.html
4. RMAN CONVERT command
http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10770/rcmsynta18.htm#RCMRF200
5. Using Transportable Tablespace
http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10739/tspaces.htm – ADMIN01101

Advertisements

Flashback

August 19, 2010

We were both young when I first saw you.
I close my eyes, and the flashback starts,

(@Love story – Taylor Swift)

Vâng, cái mà mình muốn nói ở đây chính là kỹ thuật Flashback trong Oracle.

Flashback là gì?

Một cách định nghĩa mình thích “Effectively, it’s a “oh shit!” proctection mechanism for DBAs”,  là cách thức nhìn dữ liệu tại một thời điểm trong quá khứ mà không cần dùng đến các thao tác recovery. (đây chính là điểm quan trọng để chống lại kiểu Flashback lập lờ của M$ http://www.eggheadcafe.com/software/aspnet/35792955/sqlserver-equivalent-of-flashback.aspx http://msdn.microsoft.com/en-us/library/ms175158.aspx, ha ha, dùng Snapshot cơ đấy).

Khi nào thì dùng Flashback

  • Thực hiện các câu Query trả về dữ liệu ở quá khứ
  • Thực hiện các câu Query trả về metadata chỉ ra sự thay đổi chi tiết trong lịch sử
  • Recover dữ liệu vào 1 thời điểm trong quá khứ

Để làm các điều trên thì phải dùng tools gì

  • Oracle Flashback Query
  • Oracle Flashback Version Query
  • Oracle Flashback Transaction Query
  • DBMS_FLASHBACK package

Nói lằng nhằng như trên, tóm lại cái Flashback này dùng để làm gì: như cánh cửa thần của Doremon (ngoài lề tý, mình mà là thằng Nobita thì thôi chẳng phải làm gì cho mệt nhỉ?).

  • Oracle Flashback Table: phục hồi dữ liệu về 1 thời điểm trong quá khứ. Nhân dân có thể restore table trong khi database vẫn đang hoạt động, undo các thay đổi cho từng table
  • Oracle Flashback Drop: Nhân dân nhỡ tay drop 1 table, muốn sửa sai. Cái này >< với lệnh DROP table
  • Oracle Flashback Database: Nhanh chóng đưa database trở về một thời điểm trước đó, có thể undo nhưng thao tác sai trước đó. Lưu ý nhân dân k việc gì mà phải đi restore database backups như sản phẩm của anh Hoá Đơn Cổng.

Cách dùng: Rất đơn giản với từ khoá AS OF TIMESTAMP  TO_TIMESTAMP

Ex1: SELECT *

FROM employees AS OF TIMESTAMP

TO_TIMESTAMP(‘2004-04-04 09:30:00’, ‘YYYY-MM-DD HH:MI:SS’)

WHERE last_name = ‘Chung’;

Ex2:

INSERT INTO employees

(SELECT * FROM employees AS OF TIMESTAMP

TO_TIMESTAMP(‘2004-04-04 09:30:00’, ‘YYYY-MM-DD HH:MI:SS’)

WHERE last_name = ‘Chung’);

Trông cũng dễ nhỉ?

– Table A has been deleted? Who did it?

– Britney Spears: Oops ! I did it again (:))

19 Aug 2010

HN

When an Oracle system hang up

August 18, 2010

Mấy hôm trước ông bạn thân nhờ mình xem hộ cho hệ thống đang chạy trên nền Oracle 10g + Unix. Ông bạn nói lúc bình thường thì không sao, nhưng đợt này nhiều người truy cập (k có số lượng user cụ thể nhưng chắc trên 1K) hệ thống cứ treo cứng luôn và không làm được bất cứ việc gì cả. Mình có hỏi ông bạn cụ thể thì các user kia vào làm gì thì ông bạn nói chủ yếu là register và search trong một module của hệ thống. Điều kiện là không được sửa đổi application code đang running

Suy nghĩ đầu tiên bao giờ cũng là code xấu. Đây cũng chính là vấn đề cốt lõi và cũng là yếu tố quan trọng nhất trong Performance Tuning, tuy nhiên có cái ràng buộc ở trên nên mình sẽ no-table vấn đề này. Lúc ông bạn nói, mình nghĩ ngay một số vấn đề:

  • Cảm nhận đầu tiên của mình là về Oracle connection. Mình đoán là hệ thống của bạn mình đang sử dụng dedicated mode vì nó phổ biển và đơn giản ít phải configure. Dedicated server là cơ chế ánh xạ 1- giữa client  connection và server process. Khi có 1 client connection hệ thống sẽ tự động sịnh ra một server process để đáp ứng. Số lượng user lớn dẫn đến số lượng server process lớn. Mà mỗi server process đều chiếm 1 lượng tài nguyên nhất định cho nên đến một mức nào đó sẽ làm cho hệ thống overload -> treo
  • Cảm nhận tiếp theo là về resource của user. Nhiều hệ thống ở mình sử dụng cơ chế 1 power user, nghĩa là thực tế chỉ có 1 user của Oracle, còn các user A, B, C … kia chỉ là các bản ghi trong bảng user của ứng dụng. Oracle user này thường có quyền rất mạnh (thậm chí DBA) và được gán resource rất lớn. Kết hợp với yếu tố trên thì treo là điều dễ hiểu.

Tất nhiên sẽ còn 1 số vấn đề nữa nhưng theo mình 2 cái trên là đủ cho hệ thống treo. Giải pháp của mình đưa ra là

  • Xem xét chuyển database về cơ chế shared-server. Tất nhiên cũng phải thêm 1 chút cấu hình, tuy nhiên, nó đều có guide book đầy đủ, cứ làm theo là OK. Mình cũng nói thêm qua 1 chút về Shared Server. Shared server, there is a many-to-one relationship many clients to a shared server, rất thích hợp cho các hệ thống OLTP nhưng rất không phù hợp với data warehouse. Nó sẽ dùng dispatcher để quay vòng các server process. Số lượng server process là limit nên hệ thống có thể chậm chứ k treo, đó là điều chắc chắn.
  • Hạn chế resource của user. Có nhiều cách để hạn chế: thông qua profile, giảm số lượng process/thread cho user, gán quota … Và nếu có thể thì nên tạo riêng 1 Oracle user dành cho các user kiểu này. Và thực sự nếu có money thì khi có những yêu cầu đột biến kiểu này trong 1 thời gian ngắn thì có thể xem xét tăng thêm database phụ , dùng các cơ chế synchronize data, i.e. replicate, mview để giảm tải cho server chính

Ông bạn nói sẽ xem xét thử nghiệm. Mình thì tin chắc rằng hệ thống sẽ không bị treo như trước nữa.

18 Aug 2010

HN