Chào mọi người,

Mình IMP dữ liệu từ file DMP kích thước là 15GB (15,404,668 kB) tốn gần cả 1 ngày trời mới xong.

Code: Select all

imp system/oracle@orcl fromuser=sexport touser=yonan file=go_dummy.dmp log=yonan.log ignore=Y commit=Y

Bác nào có cách nào để cải thiện tình hình thì chỉ mình 1 cái...

Nhiều giải pháp lắm, mỗi cái 1 chút sẽ thấy khá hơn
- Khi export thêm vào Direct=Y
- Trước khi import, disable constraint, dẹp mấy cái trigger đi, dẹp luôn index càng tốt.
- Khi imp, dùng commit=n (default), tăng buffer (lý thuyết là số_row*size_của_row, thực tế cho khoảng 100000 ~ 100Mb, rồi từ từ chỉnh lại)
- Dùng bộ expdp/impdp mới.

Thêm tí
- Tạm thời chuyển về NoArchived mode.
- Nếu là 9i thì set thêm Large_pool_size
Và nếu là 10g trở lên thì nên dùng expdp/impdp thay cho exp/imp

Cảm ơn bác Sang gợi ý

nhsang wrote:- Khi export thêm vào Direct=Y

Cái này không thể do file dmp nhận từ khách hàng. Nhưng sẽ yêu cầu lần sau

nhsang wrote:- Trước khi import, disable constraint, dẹp mấy cái trigger đi, dẹp luôn index càng tốt.

Sẽ thử

nhsang wrote:- Khi imp, dùng commit=n (default), tăng buffer (lý thuyết là số_row*size_của_row, thực tế cho khoảng 100000 ~ 100Mb, rồi từ từ chỉnh lại)

Sẽ thử

nhsang wrote:- Dùng bộ expdp/impdp mới.

Cái này không thể do KH export bằng exp

Mình tắt chế độ archive như bác vnora chỉ

Code: Select all

SQL> shutdown immediate;
SQL> Startup mount;
SQL> Alter database flashback off;
SQL> Alter database noarchivelog;
SQL> Alter database open;

Sau đó thực hiện IMP như gợi ý của bác Sang thì có vẽ nó nhanh đáng kể

Code: Select all

imp system/oracle@orcl fromuser=sexport touser=yonan file=ORASMS_sakujo_mae_dummy.dmp log=syonan2.log ignore=Y commit=N Buffer=100000

Thử xem nó rút ngắn được bao nhiêu thời gian ....

Hi,

Mình chia sẻ một số ý:
1. Thêm yếu tố xử lý //
2. Chú ý (không nên) khi tắt archived-log đối với database của khách hàng
3. không nên post thông tin về datbase của khách hàng lên đây. (đều là thông tin nhạy cảm: imp system/oracle@orcl fromuser=sexport touser=yonan file=go_dummy.dmp log=yonan.log )

Rgds.

daotao_oracle wrote:Hi,

Mình chia sẻ một số ý:
1. Thêm yếu tố xử lý //
2. Chú ý (không nên) khi tắt archived-log đối với database của khách hàng
3. không nên post thông tin về datbase của khách hàng lên đây. (đều là thông tin nhạy cảm: imp system/oracle@orcl fromuser=sexport touser=yonan file=go_dummy.dmp log=yonan.log )

Rgds.

1. Thêm yếu tố xử lý // là như thế nào nhỉ? Bác vandt đang dùng imp chứ không phải impdp.
2. Tắt archivedlog khi import thôi, xong rồi thì lại bật nó lên (ở trên mình nói là tạm thời chuyển về noarchived log mà). Vì import lượng lớn dữ liệu như vậy thì DB cũng import vào thời điểm không có ai làm việc chứ, vì có muốn làm việc thì server cũng quá busy với thằng imp này rồi.
3. Có thể bạn đúng, nhưng cũng có thể bác vandt đã sửa thông tin khi post lên rồi (kiểu như trên báo nó vẫn nói "tên nạn nhân đã được thay đổi").

daotao_oracle wrote:Hi,
1. Thêm yếu tố xử lý //

Cảm ơn bạn.
Đúng như bác vnora đã post. Mình không hiểu xử lý // (có phải bạn muốn nói là xử lí song song phải không? Như vậy sẽ thực hiện như thế nào?)

daotao_oracle wrote:Hi,
2. Chú ý (không nên) khi tắt archived-log đối với database của khách hàng

Cái này thì chỉ OFF tạm thôi.

daotao_oracle wrote:Hi,

3. không nên post thông tin về datbase của khách hàng lên đây. (đều là thông tin nhạy cảm: imp system/oracle@orcl fromuser=sexport touser=yonan file=go_dummy.dmp log=yonan.log )

Cảm ơn bạn đã nhắc nhở. Cái này thì mình đã sửa thông tin rồi bạn ạ

Cuối cùng thì mình thấy thời gian rút ngắn hơn phân nữa trước đây gần 30 H nay chỉ còn 11 H
(30-11)/30*100 = 63%

Hi,

Oracle tính phí license theo số CPU hẳn có lý do chính đáng, khả năng // tạo nên sự khác biệt rõ trong hầu hết các thao tác xử lý trên dữ liệu lớn.

Về cơ bản, nếu máy chủ của bạn mạnh, nhiều CPU thì dù tác vụ đó không hỗ trợ tính năng xử lý // thì bạn cũng nên "tự" xử lý // bằng cách cho chạy nhiều tiến trình cùng một lúc.

Để cải tiến thời gian import (loading), theo kinh nghiệm, thì sql* loader cũng là một cách hiệu quả nếu bạn có thể nghĩ cách chuyển qua dùng công cụ này.

Ngoài ra, nếu bạn import các objects thuộc 1 tablespace nào đó, thay vì tắt ARCHIVED-LOG thì nên dùng tính năng NO LOGGING mức Table hoặc Tablespace.

Không biết bạn đã xem chủ đề này: http://www.dba-oracle.com/oracle_tips_load_speed.htm


Rgds.

daotao_oracle wrote:Hi,

Oracle tính phí license theo số CPU hẳn có lý do chính đáng, khả năng // tạo nên sự khác biệt rõ trong hầu hết các thao tác xử lý trên dữ liệu lớn.

Về cơ bản, nếu máy chủ của bạn mạnh, nhiều CPU thì dù tác vụ đó không hỗ trợ tính năng xử lý // thì bạn cũng nên "tự" xử lý // bằng cách cho chạy nhiều tiến trình cùng một lúc.

Để cải tiến thời gian import (loading), theo kinh nghiệm, thì sql* loader cũng là một cách hiệu quả nếu bạn có thể nghĩ cách chuyển qua dùng công cụ này.

Bác đúng là thầy giáo có khác, chẳng thực tế gì cả, lan man quá.
Người ta đã nói rõ vấn đề là đang có 1 file dump được export bằng exp, và làm thế nào để import vào DB cho nhanh mà.
Server của bác có 100 cái CPU thì imp nó có xử lý song song (//) được không?

daotao_oracle wrote:Ngoài ra, nếu bạn import các objects thuộc 1 tablespace nào đó, thay vì tắt ARCHIVED-LOG thì nên dùng tính năng NO LOGGING mức Table hoặc Tablespace.

Bác có biết NoLogging nó có tác dụng khi nào không? Có 2 điểm quan trọng cần phải nhớ về option này:
- Works only with direct load insert
- Still maintains minimal logging, i.e., space transactions, extent invalidation records for loaded extents, etc.

vì thế nên bác Sang bác ấy mới nói là Exp nên thêm Direct=Y

daotao_oracle wrote:Để cải tiến thời gian import (loading), theo kinh nghiệm, thì sql* loader cũng là một cách hiệu quả nếu bạn có thể nghĩ cách chuyển qua dùng công cụ này.

Bác nên đọc lại kỹ bài chủ topic nêu, đó là file Export là của khách hàng, bên bác chủ topic là người bị động. Đặt tình huống như bác thì ...

Ngoài ra, nếu bạn import các objects thuộc 1 tablespace nào đó, thay vì tắt ARCHIVED-LOG thì nên dùng tính năng NO LOGGING mức Table hoặc Tablespace.
Không biết bạn đã xem chủ đề này: http://www.dba-oracle.com/oracle_tips_load_speed.htm
Rgds.

Bác đã test chưa mà bác nói chắc chắn vậy nhỉ?

good morning,

box này sôi động thật đấy

mình là dân technical chứ không phải là đi dạy nhé, mình kinh nghiệm tuy chỉ vài ba năm nhưng về exp/imp cũng theo học lỏm được vài ý và cũng làm vài lần nên chia sẻ cho các bạn biết thôi.

Các bạn không thấy ý xử lý // là thế nào thì mình đoán là các bạn chưa từng làm công việc này trên CSDL hàng trăm GB rồi

1. Mình đã từng thấy các bác nhà mình thay vì ban đầu dùng imp thì tìm cách chuyển qua dùng sql*loader, khi đó mình thấy tốc độ cải tiến đáng kể

2. Cách xử lý //:
ví dụ: có 1 file cus_data.dmp có 5 bảng, chúng ta có thể tự xử lý // như sau:
a. cửa số 1, chạy: imp hr/hr file=cus_data.dmp tables=(b1,b2,b3)
b. cửa sổ 2, chạy: imp hr/hr file=cus_data.dmp tables=(b4,b5)

Theo kinh nghiệm của mình thì Index, Constraint, Trigger, và xử lý // là những cái tác động nhiều đến tốc độ imp, những yếu tố khác cải tiến không đáng kể.


thân.

daotao_oracle wrote:good morning,

box này sôi động thật đấy

mình là dân technical chứ không phải là đi dạy nhé, mình kinh nghiệm tuy chỉ vài ba năm nhưng về exp/imp cũng theo học lỏm được vài ý và cũng làm vài lần nên chia sẻ cho các bạn biết thôi.

Các bạn không thấy ý xử lý // là thế nào thì mình đoán là các bạn chưa từng làm công việc này trên CSDL hàng trăm GB rồi

1. Mình đã từng thấy các bác nhà mình thay vì ban đầu dùng imp thì tìm cách chuyển qua dùng sql*loader, khi đó mình thấy tốc độ cải tiến đáng kể

2. Cách xử lý //:
ví dụ: có 1 file cus_data.dmp có 5 bảng, chúng ta có thể tự xử lý // như sau:
a. cửa số 1, chạy: imp hr/hr file=cus_data.dmp tables=(b1,b2,b3)
b. cửa sổ 2, chạy: imp hr/hr file=cus_data.dmp tables=(b4,b5)

Theo kinh nghiệm của mình thì Index, Constraint, Trigger, và xử lý // là những cái tác động nhiều đến tốc độ imp, những yếu tố khác cải tiến không đáng kể.


thân.

Uh, đúng rồi, Tuấn Anh, chú có làm việc trên CSDL hàng trăm GB đâu mà phát biểu, chú chỉ có làm với CSDL có vài TB thôi mà

@daotao_oracle: mình cũng ít làm việc với CSDL, chủ yếu làm System Admin thôi, nên mình thấy là y/tố ảnh hưởng đến IMP không phải ở CPU mà ở Disk I/O mới là cái lớn nhất. Nên làm sao để giảm được Disk I/O đi thì sẽ cải thiện được tốc độ. Vì bây giờ ai cũng thấy, CPU thì tốc độ tăng trưởng chóng mặt, cái còi còi cũng vài GHz trong khi HDD thì từ hơn chục năm nay (từ lúc mình tiếp xúc với máy tính) đến giờ vẫn thấy nó dậm chân tại chỗ với tốc độ 5400 rpm và 7200 rpm, không hơn.

Và với 1 file dump cỡ vài trăm GB mà bác cho nhiều thằng cùng đọc (để cho nó xử lý // gì đó) thì DISK I/O sẽ thế nào, nó có thực sự nhanh hơn không hay lại chậm hơn, đảm bảo lúc đó Disk sẽ luôn Busy 100%. Thế nên mới nói bác chưa thực tế, vẫn mang tính lý thuyết quá.

Còn đã làm DBA Oracle thì có ai chưa tiếp xúc với cái DB vài trăm GB đâu, không to thế thì cần gì DBA.

Hoan nghênh những đóng góp của bác, cái VD bác đưa ra sẽ phù hợp với file dump cỡ vài chục MB & file lưu trên vùng đĩa RAID. Vì RAID cũng là 1 cách để cải thiện việc đọc đĩa.

Túm lại, vấn đề chính ảnh hưởng đến tốc độ Imp là Disk I/O, sau đó mới đến CPU và những thứ khác

@a Văn: Để ý làm gì những câu nói đó a, mệt đầu ra. Chiều nay a có rảnh không? có đi làm vài ngụm ở bia tươi chỗ tăng bạt hổ không a? Nóng -> khát quá

@bác daotaooracle: Khi bác đưa ra nhận định mang tính chất kỹ thuật, thì bác nên đưa ra những luận điểm hoặc những test cụ thể để chứng minh nhận định của bác, không phải nói khơi khơi thì ai cũng tin! Trong trường hợp này là phần Import mà bác đưa ra luận chứng put in nhiều process thì sẽ nhanh hơn 1 process!

P/S: Bác có tin khi bác put in hàng loạt như thế, buffer get trong Oracle sẽ busy liên tục & tăng dần đều rất nhan không?

trantuananh24hg wrote:@a Văn: Để ý làm gì những câu nói đó a, mệt đầu ra. Chiều nay a có rảnh không? có đi làm vài ngụm ở bia tươi chỗ tăng bạt hổ không a? Nóng -> khát quá

Uống dùm anh 1 chai luôn nhe, cũng mệt đầu quá