15 bài thực hành tốt nhất về hiệu năng pureXML trong DB2 pps

Ngoài ra, nếu ứng dụng của bạn sử dụng một trình phân tích cú pháp DOM để tiêu thụ XML lấy ra từ DB2, các tài liệu nhỏ sẽ cho phép hiệu năng tốt hơn.. Lời khuyên 2: Sử dụng DMS và các tr

15 bài thực hành tốt nhất về hiệu năng

pureXML trong DB2

Matthias Nicola, Chuyên gia về hiệu năng CSDL, IBM Silicon Valley Laboratory

Tóm tắt: DB2 9 giới thiệu sự hỗ trợ pureXML, có nghĩa là dữ liệu XML được

lưu trữ và được truy vấn theo định dạng phân cấp vốn có của nó Để truy vấn dữ liệu XML, DB2 cung cấp hai ngôn ngữ, SQL/XML và XQuery Ngoài ra, DB2 9

có các khả năng lí tưởng về lập chỉ mục XML và hỗ trợ cho việc xác nhận tính hợp lệ của Lược đồ XML (XML Schema) Trong khi hầu hết các hướng dẫn thi hành hiện có cho DB2 cũng áp dụng cho dữ liệu XML, bài viết này cung cấp thêm các lời khuyên hiệu quả cho XML cụ thể Bài viết này đã được cập nhật cho DB2

9.5 [26 tháng 5 năm 2009: mã hiệu chỉnh trong các liệt kê 12 và 13. Biên tập.]

Giới thiệu

Hỗ trợ pureXML trong DB2 9 cung cấp các khả năng hiệu quả và linh hoạt để quản lý dữ liệu XML của bạn Hiệu năng là một sự ưu tiên cao cho nhiều ứng dụng XML; và các DBA, cũng như các nhà thiết kế ứng dụng, có thể chia sẻ khả năng của họ để đảm bảo hiệu năng tốt Đầu tiên, có tất cả các hướng dẫn thực thi DB2 truyền thống cho các cấu hình cân bằng về CPU/bộ nhớ/đĩa, các vùng bảng

và điều chỉnh vùng bộ đệm, khóa, ghi chép, các kế hoạch thực hiện truy vấn và v.v Tất cả các chủ đề này được trình bày trong các bài viết DB2 trước đó (xem Tài nguyên) và vẫn có liên quan khi bạn quản lý dữ liệu XML trong DB2

May mắn thay, một số trong các vấn đề này được các khả năng tự nhiên của DB2

xử lý như là quản lý lưu trữ tự động và quản lý bộ nhớ tự điều chỉnh Chúng cung cấp các mức hiệu năng cao cho nhiều ứng dụng và đòi hỏi rất ít sự can thiệp thủ

công Nhưng các ứng dụng XML với các yêu cầu thực thi tích cực có thể được lợi ích từ các khía cạnh phụ về hiệu năng Bài viết này tập trung vào các tình huống như vậy, đưa ra những lời khuyên và các hướng dẫn để đạt được hiệu năng tối đa của các ứng dụng XML có liên quan trong DB2 9

Dưới đây là 15 lời khuyên hiệu năng XML (không theo thứ tự cụ thể) mà chúng tôi thảo luận và minh họa trong bài viết này 15 lời khuyên này bao gồm nhiều lĩnh vực, nhưng kinh nghiệm cho thấy rằng các ứng dụng với các vấn đề hiệu năng thường chỉ cần áp dụng một hoặc hai trong số các lời khuyên này để đạt Lời

khuyên được hiệu năng mong muốn

 Lời khuyên 1: Sáng suốt lựa chọn độ chi tiết của tài liệu XML của bạn

 Lời khuyên 2: Sử dụng DMS và các trang lớn hơn để hiệu năng XML tốt

hơn

 Lời khuyên 3: Khai thác các tùy chọn lưu trữ cho XML: nội tuyến, nén

hoặc một vùng bảng riêng biệt

 Lời khuyên 4: Cách cấu hình DB2 cho phép chèn nhanh một số lượng lớn

dữ liệu XML

 Lời khuyên 5: Sử dụng các yếu tố giám sát đột xuất để kiểm tra hiệu năng

XML

 Lời khuyên 6: Hãy tăng cường xác nhận tính hợp lệ của lược đồ XML

 Lời khuyên 7: Trong các biểu thức XPath, sử dụng các đường dẫn cụ thể

đầy đủ càng nhiều càng tốt

 Lời khuyên 8: Định nghĩa các chỉ mục thiên về XML và tránh đánh chỉ

mục tất cả mọi thứ

 Lời khuyên 9: Đặt các vị từ lọc tài liệu trong XMLEXISTS thay cho

 Lời khuyên 12: Làm thế nào để sử dụng các khung nhìn xuất bản

SQL/XML để trưng ra dữ liệu quan hệ như XML

 Lời khuyên 13: Sử dụng các khung nhìn XMLTABLE để trưng ra dữ liệu

XML trong định dạng quan hệ như thế nào

 Lời khuyên 14: Đối với các truy vấn ngắn hoặc các ứng dụng OLTP, sử

dụng các câu lệnh SQL/XML với các dấu tham số

 Lời khuyên 15: Tránh chuyển đổi trang mã trong khi chèn và lấy ra XML

Trong cuộc thảo luận về các lời khuyên hiệu năng này, chúng tôi giả định rằng bạn

đã quen thuộc với các công việc thực hành hiệu năng và quản trị DB2 cơ bản cũng như với các khái niệm cơ bản về sự hỗ trợ pureXML của DB2 Ví dụ, bạn nên biết

về các cột XML, các chỉ mục XML và làm thế nào để truy vấn dữ liệu XML với SQL/XML và XQuery Tất cả những điều kiện cần trước này được trình bày trong bài viết được xuất bản trước đó trên developerWorks (xem Tài nguyên)

Các lời khuyên hiệu năng XML của DB2

Lời khuyên 1: Sáng suốt lựa chọn độ chi tiết của tài liệu XML của bạn

Khi bạn thiết kế ứng dụng XML và cấu trúc tài liệu XML của bạn, nói cụ thể, bạn

có thể có một sự lựa chọn để xác định dữ liệu nghiệp vụ nào được giữ cùng nhau trong một tài liệu XML Ví dụ, trong bảng bộ phận của chúng tôi dưới đây, chúng tôi sử dụng một tài liệu XML cho mỗi bộ phận (độ chi tiết trung bình) Đây là một

sự lựa chọn có lý nếu một bộ phận có độ chi tiết nổi trội hơn mà ứng dụng của chúng tôi truy cập và xử lý dữ liệu tại đó Theo cách khác, chúng tôi có thể có quyết định kết hợp nhiều chi nhánh bộ phận hoặc nhiều bộ phận vào một tài liệu XML duy nhất, ví dụ: tất cả những người thuộc về một đơn vị (độ chi tiết thô) Điều này, tuy nhiên, là sự tối ưu nhỏ nếu chúng ta thường xử lý chỉ một bộ phận vào một lúc

Bảng 1 Tạo bảng dept( unitID char(8), deptdoc xml)

viên đó thuộc về bộ phận nào Đây sẽ là một sự lựa chọn rất tốt nếu các nhân viên

tự mình sử dụng các đối tượng nghiệp vụ quan tâm, mà các đối tượng này thường được các nhân viên khác trong cùng một bộ phận truy cập và xử lý một cách độc lập Nhưng, nếu ứng dụng đó thường đòi hỏi cùng lúc tất cả các nhân viên trong một bộ phận, tốt hơn là để một tài liệu XML cho mỗi bộ phận

Cụ thể là, việc xử lý theo bó nhiều đối tượng nghiệp vụ độc lập trong một tài liệu duy nhất là không nên DB2 sử dụng các chỉ mục trên dữ liệu XML để lọc mức cho mỗi tài liệu Vì vậy, độ chi tiết tài liệu XML của bạn càng tốt hơn, thì lợi thế tiềm năng của bạn càng cao do việc truy cập theo chỉ mục Ngoài ra, nếu ứng dụng của bạn sử dụng một trình phân tích cú pháp DOM để tiêu thụ XML lấy ra từ DB2, các tài liệu nhỏ sẽ cho phép hiệu năng tốt hơn

Liên quan đến thiết kế tài liệu XML, một câu hỏi thường gặp là khi nào sử dụng các thuộc tính so với các phần tử và lựa chọn đó ảnh hưởng đến hiệu năng ra sao Đây là một câu hỏi về mô hình hóa dữ liệu hơn là một câu hỏi về hiệu năng Như vậy, câu hỏi này cũng cũ như là SGML, tiền thân của XML và người ta đã tranh cãi sôi nổi mà không đạt được sự đồng thuận nào Tuy nhiên, một thực tế quan trọng đi kèm là các phần tử XML linh hoạt hơn các thuộc tính bởi vì chúng có thể được lặp lại và lồng nhau Ví dụ, trong các tài liệu của bộ phận chúng tôi, chúng tôi sử dụng một phần tử "phone" để cho phép chúng tôi có nhiều lần xuất hiện của

"phone" nếu một nhân viên có nhiều số điện thoại Nó cũng được mở rộng trong trường hợp sau này chúng tôi cần phải ngắt các số điện thoại vào trong các phân đoạn, nghĩa là phần tử "phone" có thể có các phần tử con cho mã nước, mã vùng,

mã mở rộng, v.v Nếu "phone" đã là một thuộc tính của các phần tử của nhân viên (employee), thì sau đó nó có thể tồn tại chỉ một lần cho mỗi nhân viên và chúng tôi cũng không thể thêm vào nó các phần tử con, thuộc tính phone có thể cản trở

sự tiến hóa của lược đồ theo thời gian Mặc dù bạn có thể mô hình hóa tất cả các

dữ liệu của bạn mà dùng thuộc tính nào, chúng có thể là một lựa chọn rất trực

quan cho các mục tin đã được biết trước là không bao giờ lặp lại (theo phần tử), cũng không có bất kỳ các trường con nào Các thuộc tính làm cho XML ngắn hơn một chút vì chúng chỉ có một thẻ đơn, khác với các phần tử có một thẻ bắt đầu và một thẻ kết thúc Trong DB2, các thuộc tính có thể được sử dụng trong các truy vấn, các vị từ và các định nghĩa chỉ mục, dễ như phần tử Do các thuộc tính ít có khả năng mở rộng hơn so với các phần tử, nên DB2 có thể áp dụng việc tối ưu hóa lưu trữ và truy cập nào đó Điều này cần được xem là lợi điểm về hiệu năng, hơn việc chỉ khích lệ chuyển đổi các thuộc tính thành các phần tử, đặc biệt khi các khía cạnh mô hình hóa dữ liệu thực sự gọi các phần tử

Tóm lại, hãy chọn độ chi tiết của tài liệu XML của bạn đáp ứng độ chi tiết truy cập nổi trội đã dự liệu trước Khi có nghi ngờ, tốt hơn là đi theo hướng độ chi tiết cao hơn và các tài liệu XML nhỏ hơn

Lời khuyên 2: Sử dụng DMS và các trang lớn hơn để hiệu năng XML tốt hơn

DMS - Các vùng bảng quản lý cơ sở dữ liệu đảm bảo hiệu năng cao hơn so với SMS - các vùng bảng quản lý hệ điều hành Điều này đúng với dữ liệu quan hệ và thậm chí cũng đúng cho việc truy cập đọc và viết XML Trong DB2 9, theo mặc định các vùng bảng mới được tạo ra là DMS Người ta cũng đề xuất sử dụng các vùng bảng DMS có vùng lưu trữ tự động sao cho các vùng chứa DMS phát triển khi cần thiết mà không cần có sự can thiệp thủ công Nếu một tài liệu XML là quá lớn không vừa một trang duy nhất trong một vùng bảng, thì DB2 sẽ phân chia tài liệu thành nhiều vùng rồi sẽ lưu trữ trên nhiều trang Điều này là trong suốt đối với ứng dụng của bạn và cho phép DB2 XML xử lý các tài liệu XML đến sự ràng buộc trong giới hạn 2GB cho mỗi tài liệu

Nói chung, số các vùng (phân chia) cho mỗi tài liệu càng thấp thì hiệu năng càng tốt, đặc biệt đối với việc chèn và lấy ra tài liệu đầy đủ Nếu một tài liệu không khít

trên một trang, số lượng phân chia cho mỗi tài liệu phụ thuộc vào kích thước trang (4KB, 8KB, 16KB hoặc 32KB) Các kích thước trang của vùng bảng của bạn càng lớn thì số lượng phân chia tiềm tàng cho mỗi tài liệu càng thấp Ví dụ, giả sử một tài liệu đã cho bắt đầu chia thành bốn mươi trang 4KB Sau đó, lưu trữ cùng một tài liệu này chỉ trên hai mươi trang 8KB, hoặc mười trang16KB hoặc năm trang 32KB, tương ứng Nếu các tài liệu XML này nhỏ hơn đáng kể so với kích thước trang đã chọn, thì sẽ không có vùng nào bị lãng phí do có thể lưu trữ nhiều tài liệu nhỏ trên một trang duy nhất

Theo kinh nghiệm, chọn một kích thước trang cho dữ liệu XML không nhỏ hơn hai lần kích thước tài liệu dự kiến trung bình của bạn, với giả thuyết lớn nhất là 32KB Nếu bạn sử dụng một kích thước trang đơn cho dữ liệu quan hệ và dữ liệu XML hoặc cho dữ liệu và các chỉ mục, một kích thước trang 32KB có thể mang lại lợi ích cho dữ liệu XML, nhưng hơi bất lợi cho việc truy cập dữ liệu và chỉ mục quan hệ Trong trường hợp như vậy, các trang 16KB hoặc 8KB có thể là một lựa chọn tốt hơn để hoạt động tốt cho cả hai

Lời khuyên 3: Khai thác các tùy chọn lưu trữ cho XML: nội tuyến, nén hoặc một vùng bảng riêng biệt

Hãy xem xét các bảng mẫu sau đây để thảo luận về các tùy chọn lưu trữ cho dữ liệu XML Bảng này chứa dữ liệu quan hệ và dữ liệu XML:

Liệt kê 1 Bảng mẫu với dữ liệu XML và dữ liệu quan hệ

create table product(pid bigint, name varchar(20), brand varchar(35),

category integer, price decimal, description XML);

Với định nghĩa bảng này, theo mặc định dữ liệu XML và dữ liệu quan hệ của bảng được lưu trữ mặc định trong cùng một vùng bảng Điều này có nghĩa là chúng sử dụng cùng kích thước trang và được đệm trong cùng một vùng bộ đệm Trong vùng bảng, dữ liệu quan hệ được lưu giữ trong đối tượng DAT, trong khi dữ liệu XML nằm trong đối tượng XDA Điều này là do các tài liệu XML, như các LOB,

có thể là quá lớn không khít trong một hàng đơn trên một trang dữ liệu của bảng

Sự bố trí mặc định này đảm bảo hiệu năng tốt cho hầu hết các kịch bản ứng dụng

Nếu bạn đã thực hiện một sự phân tích hiệu năng và thấy rằng bạn cần phải có một kích thước trang lớn cho dữ liệu XML trừ một trang có kích thước nhỏ cho dữ liệu quan hệ hay các chỉ mục, bạn có thể sử dụng các vùng bảng riêng biệt để đạt được điều này Khi bạn định nghĩa một bảng, bạn có thể hướng dữ liệu "dài" vào trong một vùng bảng riêng biệt có kích thước trang khác nhau Dữ liệu dài bao gồm các

dữ liệu LOB và dữ liệu XML

Ví dụ sau định nghĩa hai vùng bộ đệm và hai vùng bảng, một thứ có các trang 4KB

và 32KB (Lưu ý rằng một vùng bảng luôn luôn đòi hỏi phải có một vùng bộ đệm

có kích thước trang vừa khít) Bảng sản phẩm ("product") được gán cho vùng bảng

"relData" có các trang 4KB Trong vùng bảng đó lưu trữ tất cả các cột của nó, trừ cột mô tả ("description") XML, lưu trữ trên các trang 32KB trong vùng bảng

"xmldata"

Liệt kê 2 Dữ liệu XML và dữ liệu quan hệ trong vùng bảng riêng biệt và các vùng bộ đệm

create bufferpool bp4k pagesize 4k;

create bufferpool bp32k pagesize 32k;

create tablespace relData

create table product(pid bigint, name varchar(20), brand varchar(35),

category integer, price decimal, description XML)

in relData

long in xmlData;

Các mặc định của vùng bảng trong DB2 9 khác nhau trong DB2 V8 Trừ khi xác định tường minh, các vùng bảng mới được tạo ra như DMS với các định danh (ID) hàng lớn Điều này có nghĩa một vùng bảng với các trang 4KB có thể phát triển lên đến 2TB thay vì 64GB ở V8 và với các trang 32KB lên đến 16TB thay vì 512GB Ngoài ra, loại bỏ giới hạn 255 hàng cho mỗi trang, cho phép lên đến 2.335 hàng trên các trang 32KB Do đó, giới hạn hàng cho mỗi trang tự nó không còn là

lý do để sử dụng các trang nhỏ cho dữ liệu quan hệ nữa

DB2 9.5 cũng cho phép bạn lưu trữ dữ liệu XML "nội tuyến" và nén

(compressed) Nếu một số hoặc tất cả các tài liệu XML của bạn là đủ nhỏ để khít

với hàng tương ứng của chúng trên trang bảng cơ sở trong đối tượng DAT, chúng

có thể được nội tuyến vào trong hàng quan hệ Điều này đảm bảo truy cập trực tiếp hơn đến dữ liệu XML và tránh sự truy cập chuyển hướng đến đối tượng XDA Nếu một số tài liệu trong cột XML vẫn còn quá lớn để được nội tuyến, chúng được lưu trữ "đường bao" trong đối tượng XDA như thường lệ Việc nội tuyến có thể làm giảm đáng kể kích thước của chỉ mục các vùng do các tài liệu đã nội tuyến không yêu cầu bất kỳ điểm vào nào trên chỉ mục vùng Chúng luôn luôn bao gồm một vùng đã nội tuyến, đơn Các tài liệu được nội tuyến cũng có thể được nén bằng cách sử dụng phép nén hàng của DB2, như chỉ ra trong Liệt kê 3:

Liệt kê 3 Lưu trữ XML nén và nội tuyến

create table product(pid bigint, name varchar(20), brand varchar(35),

category integer, price decimal,

description XML inline length 3000) compress yes;

Trong ví dụ này, cột XML được định nghĩa với tùy chọn "inline length 3000" (độ dài nội tuyến 3000) Điều này có nghĩa là bất kỳ tài liệu nào có thể được lưu trữ trong 3.000 byte hoặc ít hơn sẽ được nội tuyến Có liên quan với việc nội tuyến là kích thước của tài liệu sau khi phân tích cú pháp XML trong DB2, chứ không phải

là kích thước của tài liệu XML văn bản trong hệ thống tệp của bạn Độ dài nội tuyến phải nhỏ hơn kích thước trang trừ đi kích thước của các cột khác trong bảng

đó Dữ liệu XML đã nội tuyến luôn nằm trong vùng bảng giống như các cột quan

hệ của bảng đó và không thể được lưu trữ trên trang khác hoặc trong một vùng bảng riêng biệt

Kể từ khi bảng mẫu được định nghĩa với tùy chọn "compress yes" (có nén), dữ liệu quan hệ và các tài liệu XML nội tuyến bắt đầu được nén Để nén dữ liệu XML

đã nội tuyến xuống còn 70-85 phần trăm không phải là phổ biến Có thể sử dụng các câu lệnh sau đây để kiểm tra tỉ số nén của bảng sản phẩm "product":

Liệt kê 4 Chức năng quản trị (Admin) để kiểm tra tỉ số nén

select tabname,pages_saved_percent,bytes_saved_percent

from

table(sysproc.admin_get_tab_compress_info('MYSCHEMA','PRODUCT','ESTIMATE')) as t

Nén dữ liệu XML có thể làm tăng hiệu năng rất lớn nếu hệ thống của bạn muốn ràng buộc I/O hơn là CPU bị ràng buộc Lưu ý, tuy nhiên, việc nội tuyến làm tăng đáng kể kích thước hàng trên các trang dữ liệu của bạn Điều này lần lượt giảm số lượng hàng cho mỗi trang Các truy vấn mà chỉ truy cập vào các cột quan hệ của bảng bây giờ cần phải đọc một số lượng lớn các trang hơn số trang không nội tuyến Điều này có thể dẫn đến có nhiều I/O hơn và hiệu năng cho các truy vấn này thấp hơn Nếu các truy vấn của bạn thường luôn luôn có tác dụng đến cột XML đó, thì sau đó điều này không ảnh hưởng đến bạn

Tóm lại, sử dụng khả năng phán đoán chung khi xem xét các vùng bảng riêng biệt cho dữ liệu XML Càng ít vùng bộ đệm, vùng bảng và càng ít trang với kích thước khác biệt sẽ càng đơn giản khi thiết kế cơ sở dữ liệu vật lý để quản lý, duy trì và điều chỉnh Tránh đưa vào các kích thước nhiều trang trừ khi bạn biết rằng nó thực sự cung cấp một lợi ích hiệu năng đáng giá Sử dụng nội tuyến và nén để giảm tiêu thụ vùng lưu trữ và tăng hiệu năng I/O

Lời khuyên 4: Đặt cấu hình DB2 để chèn nhanh số lượng lớn các dữ liệu XML như thế nào

DB2 9 hỗ trợ hai lựa chọn để di chuyển dữ liệu XML từ một hệ thống tệp vào trong một bảng DB2: chèn và nhập khẩu Chèn và nhập khẩu có các đặc điểm tương tự như nhau từ hiệu năng và quan điểm vì tiện ích nhập khẩu thực sự thực hiện một loạt các hoạt động chèn

Kể từ DB2 9.5, bạn cũng có thể sử dụng tiện ích LOAD DB2 để di chuyển dữ liệu XML vào một bảng Các lợi thế chủ yếu của tiện ích LOAD với dữ liệu XML giống như với dữ liệu quan hệ, chẳng hạn như dữ liệu không lấy từ tệp log và việc song song hóa được tự động sử dụng để tăng hiệu năng DB2 xác định một mức độ mặc định của song song dựa trên số CPU và các vùng chứa vùng bảng Bạn cũng

có thể thiết lập song song của CPU và I/O với các tham số CPU_PARALLELISM

và DISK_PARALLELISM trong cú pháp của lệnh LOAD

Cho dù ứng dụng của bạn thực hiện các hoạt động chèn số lượng lớn, có thể thông qua các luồng hoạt động chèn đồng thời hoặc nếu bạn sử dụng nhập khẩu hoặc nạp, các hướng dẫn thực thi sau đây áp dụng:

 Là một điều kiện tiên quyết quan trọng, hãy chắc chắn sử dụng vùng bảng DMS với kích thước trang lớn (xem Lời khuyên 2)

 Thậm chí nếu bạn chưa định nghĩa bất kỳ các chỉ mục trên bảng đích, cơ chế lưu trữ pureXML của DB2 sẽ duy trì trong suốt cái gọi là các vùng và các chỉ mục đường dẫn cho việc truy cập XML hiệu quả Vì thế, cung cấp

đủ vùng bộ đệm để hỗ trợ đọc chỉ mục

 Nếu bạn cần nhiều chỉ mục XML do người dùng định nghĩa trên bảng của bạn, tốt hơn là xác định chúng trước khi chèn số lượng lớn hơn là sau khi chèn mới tạo ra chúng Trong hoạt động chèn, mỗi tài liệu XML sẽ được xử

lý chỉ một lần để tạo các đầu vào chỉ mục đối với tất cả các chỉ mục XML

Tuy nhiên, nếu bạn đưa ra nhiều câu lệnh "create index", tất cả tài liệu trong cột XML sẽ bị chuyển nhiều lần

 Nếu bạn cần phải di chuyển một số lượng rất lớn các tệp XML nhỏ từ một

hệ thống tệp vào trong một bảng DB2, có thể thực hiện hiệu quả là đặt chúng trong một hệ thống tệp dành riêng, mà không dùng chế độ truy cập nhanh tệp hệ thống Vì mỗi tệp là chỉ đọc một lần, truy cập nhanh là không cần thiết Trong AIX, người ta đã thấy có lợi khi gắn hệ thống tệp này với tùy chọn -o cio

Hãy xem xét các hướng dẫn sau đây để chèn và nhập khẩu:

 "ALTER TABLE <tablename> APPEND ON" cho phép gán thêm chế độ

cho bảng đó Dữ liệu mới được gán vào cuối của bảng thay vì tìm kiếm vùng trống trên các trang hiện có Điều này đảm bảo tăng cường hiệu năng của hoạt động chèn số lượng lớn

 Tăng kích thước bộ đệm log (LOGBUFSZ) và kích thước của tệp log

(LOGFILSIZ) cũng trợ giúp thực thi lệnh chèn Điều này đặc biệt quan trọng đối với phép chèn XML do khối lượng dữ liệu cho mỗi hàng có xu hướng lớn hơn rất nhiều so với các dữ liệu quan hệ Chúng tôi đề xuất sử dụng một thiết bị I/O nhanh cho tệp log

 Bạn có thể tránh việc ghi log nếu bạn sử dụng "ALTER TABLE

<tablename> ACTIVATE NOT LOGGED INITIALLY" (NLI) Tuy

nhiên, người ta đã cảnh báo rằng nếu có một câu lệnh sai, bảng sẽ được đánh dấu là không thể truy cập được và phải loại bỏ Điều này thường cấm NLI với các phép chèn gia tăng số lượng lớn trong các hệ thống sản xuất, nhưng có thể có ích khi tạo dữ liệu khởi đầu cho một bảng trống Coi chừng NLI ngăn cản các hoạt động chèn/nhập khẩu tương tranh vào trong một bảng đích và hoạt động song song có thể mang lại hiệu năng cao hơn NLI

 Nếu bạn sử dụng nhập khẩu, một giá trị nhỏ cho tham số

COMMITCOUNT có xu hướng hại đến hiệu năng Việc cam kết mỗi một

100 hàng hoặc nhiều hơn sẽ thực hiện tốt hơn so với cam kết từng hàng Bạn cũng có thể bỏ qua tham số COMMITCOUNT và để cho DB2 cam kết mỗi khi thích hợp

 Để tận dụng tốt hơn nhiều CPU và đĩa, bạn có thể chạy đồng thời nhiều lệnh nhập khẩu Hãy chắc chắn rằng, mỗi lệnh nhập khẩu chạy trong kết nối riêng của nó tới cơ sở dữ liệu và sử dụng mệnh đề "ALLOW WRITE

ACCESS" để tránh việc khóa các bảng Bạn không cần phải tách riêng tệp đầu vào (các tệp DEL) để chạy các lệnh nhập khẩu cùng nhau Mỗi lệnh nhập khẩu có thể đọc một đoạn khác nhau của cùng tệp đầu vào do lệnh

nhập khẩu cho phép bạn chỉ định "SKIPCOUNT m ROWCOUNT n" để đọc các hàng m+1 đến m+n từ tệp đầu vào

Đối với các hướng dẫn thực thi lệnh chèn, xem bài viết "Các lời khuyên để cải thiện việc thực thi lệnh INSERT trong DB2 UDB" [xem Tài nguyên]

Tóm lại, lệnh chèn truyền thống và việc điều chỉnh hiệu năng ghi log là tốt cho việc chèn và nhập khẩu XML Bạn có thể chạy các phiên nhập khẩu song song, nếu bạn thêm mệnh đề ALLOW WRITE ACCESS cho mỗi lệnh nhập khẩu Trong DB2 9.5, sử dụng nạp vào thay cho nhập khẩu

Lời khuyên 5: Sử dụng các yếu tố giám sát đột xuất để kiểm tra hiệu năng XML

Cho dù bạn đang kiểm tra lợi ích của các kích thước trang khác hoặc các lĩnh vực khác về hiệu năng XML, các cơ hội là bạn muốn sử dụng giám sát đột xuất DB2 như với dữ liệu quan hệ Bạn sẽ thấy rằng DB2 9 cung cấp các yếu tố giám sát đột xuất cho vùng bộ đệm mới cho dữ liệu XML mà nó khít với các bộ đếm hiện có cho dữ liệu quan hệ và các chỉ mục Do dữ liệu quan hệ và các chỉ mục được lưu trữ trong các đối tượng lưu trữ riêng biệt trong một vùng bảng, chúng đã tách riêng

các bộ đếm đọc và viết Lưu trữ pureXML trong DB2 9 giới thiệu một đối tượng lưu trữ mới cho dữ liệu XML, được gọi là XDA và nó cũng có bộ đếm vùng bộ đệm riêng của mình

Ví dụ dưới đây là một đoạn trích từ một kết quả đầu ra của giám sát đột xuất Bạn thấy các yếu tố từ màn hình chụp ứng với ba đối tượng lưu trữ khác nhau: dữ liệu, chỉ mục và XDA Điều này cho phép bạn giám sát và phân tích hoạt động đệm và I/O đối với dữ liệu XML một cách riêng biệt khỏi dữ liệu quan hệ Bất cứ hoạt động nào liên quan đến các chỉ mục XML đều có trong các bộ đếm chỉ số hiện tại Diễn giải về các bộ đếm XDA mới giống như các bộ đếm quan hệ tương ứng của

nó Ví dụ, một tỷ lệ thấp của hoạt động đọc vật lý XDA với hoạt động đọc logic XDA cho biết tỷ lệ cụ thể của vùng bộ đệm cao đối với dữ liệu XML, như là mong muốn Để biết thêm chi tiết về các yếu tố giám sát đột xuất của vùng bộ đệm, xem tài liệu DB2

Liệt kê 5 Kết quả đầu ra của màn hình đối với dữ liệu, chỉ mục và các đối tượng lưu trữ XDA

Buffer pool data logical reads = 221759

Buffer pool data physical reads = 48580

Buffer pool temporary data logical reads = 10730

Buffer pool temporary data physical reads = 0

Buffer pool data writes = 6

Asynchronous pool data page reads = 0

Asynchronous pool data page writes = 6

Buffer pool index logical reads = 8340915

Buffer pool index physical reads = 54517

Buffer pool temporary index logical reads = 0

Buffer pool temporary index physical reads = 0

Buffer pool index writes = 0

Asynchronous pool index page reads = 0

Asynchronous pool index page writes = 0

Buffer pool xda logical reads = 2533633

Buffer pool xda physical reads = 189056

Buffer pool temporary xda logical reads = 374243

Buffer pool temporary xda physical reads = 0

Buffer pool xda writes

= 0

Asynchronous pool xda page reads = 97728

Asynchronous pool xda page writes = 0

Asynchronous data read requests = 0

Asynchronous index read requests = 0

Asynchronous xda read requests = 83528

Tóm lại, các bộ đếm XDA mới trong đầu ra của màn hình chụp đột xuất phản ánh hoạt động XML Chúng có ích để hiểu vùng bộ đệm, I/O và cách sử dụng vùng tạm thời (temp) của dữ liệu XML của bạn

Lời khuyên 6: Hãy tăng cường xác nhận tính hợp lệ của lược đồ XML

Một lược đồ XML có thể định nghĩa cấu trúc, phần tử và các thuộc tính, các kiểu

dữ liệu của chúng, các dải giá trị, v.v được phép trong một tập hợp các tài liệu XML DB2 cho phép bạn (tùy chọn) xác nhận tính hợp lệ của các tài liệu XML với các lược đồ XML Nếu bạn chọn xác nhận hợp lệ các tài liệu, bạn thường xác nhận tính hợp lệ tại thời điểm chèn Điều này đáp ứng hai mục đích Trước tiên, việc xác nhận hợp lệ đảm bảo rằng dữ liệu được chèn vào cơ sở dữ liệu phải tuân theo định nghĩa lược đồ, nghĩa là bạn ngăn chặn "dữ liệu rác" nhập vào bảng của bạn Thứ hai, xác nhận hợp lệ lược đồ bổ sung thêm các chú thích về kiểu từ lược đồ này đến mỗi phần tử và thuộc tính XML và các kiểu này vẫn tiếp tục tồn tại trong vùng lưu trữ XML của DB2 Ví dụ, nếu một lược đồ XML định nghĩa rằng các ID

của nhân viên trong bảng dept của chúng tôi (đã chỉ ra trong Lời khuyên 1) là các

số nguyên và các tài liệu được xác nhận hợp lệ dựa vào lược đồ đó, sau đó DB2 nhớ trong mỗi tài liệu mà các ID của nhân viên có kiểu xs:integer Bất kỳ cố gắng nào thực hiện một sự so sánh chuỗi trên một ID nhân viên sau đó sẽ bị hỏng với một lỗi kiểu trong thời gian thực hiện truy vấn

Việc xác nhận tính hợp lệ của lược đồ XML là một hoạt động tùy chọn trong quá trình phân tích cú pháp XML Các nghiên cứu hiệu năng đã chỉ ra rằng việc phân tích cú pháp XML nói chung cần nhiều CPU hơn đáng kể nếu việc xác nhận tính hợp lệ của lược đồ được kích hoạt [link] Chi phí hoạt động này có thể thay đổi mạnh tùy thuộc vào cấu trúc và kích thước của tài liệu XML của bạn và đặc biệt là

về kích thước và độ phức tạp của Lược đồ XML được sử dụng Ví dụ, bạn có thể nhận thấy sự tiêu dùng CPU cao hơn 50% do việc xác nhận tính hợp lệ của lược

đồ với các lược đồ phức tạp vừa phải Trừ khi các hoạt động chèn vào XML của bạn là I/O bị ràng buộc rất nhiều, việc dùng tăng lên với CPU sẽ làm giảm thông lượng nhập vào

Xác định xem ứng dụng của bạn cần kiểm tra kiểu nghiêm ngặt hơn đối với việc tuân thủ các truy vấn và lược đồ XML Ví dụ, nếu bạn đang sử dụng một máy chủ ứng dụng thu nhận, xác nhận tính hợp lệ và xử lý các tài liệu XML trước khi chúng được lưu trữ trong cơ sở dữ liệu, sau đó các tài liệu đó có lẽ không cần phải được xác nhận lại tính hợp lệ trong DB2 Tại điểm đó bạn đã biết chúng hợp lệ rồi Hoặc, có lẽ cơ sở dữ liệu đó nhận được các tài liệu XML từ một ứng dụng tin cậy, thậm chí là một ứng dụng mà bạn kiểm soát và bạn biết rằng dữ liệu XML là luôn luôn hợp lệ Trong trường hợp đó, tránh xác nhận tính hợp lệ của lược đồ trước lợi ích về hiệu năng cao của phép nhập Tuy nhiên, nếu cơ sở dữ liệu DB2 của bạn nhận được dữ liệu XML từ các nguồn không đáng tin cậy và bạn cần phải đảm bảo tuân thủ lược đồ ở mức DB2, thì bạn cần phải dành thêm một số chu kỳ CPU cho việc đó

Tóm lại, để việc chèn đạt hiệu năng cao, tránh thực hiện xác nhận tính hợp lệ của lược đồ trong DB2 nếu nó không thực sự cần thiết

Lời khuyên 7: Trong các biểu thức XPath, sử dụng các đường dẫn cụ thể đầy đủ càng nhiều càng tốt

Giả sử bạn có một bảng với một cột XML

create table customer(info XML);

để quản lý các tài liệu "customerinfo" có cấu trúc sau:

Liệt kê 6 Tài liệu XML mẫu

/customerinfo/addr/city cũng như /customerinfo/*/city trả về city Để có hiệu năng tốt nhất, đường dẫn cụ thể đầy đủ sẽ được ưu tiên hơn so với cách sử dụng * hoặc // bởi vì nó cho phép DB2 chuyển hướng trực tiếp đến các phần tử mong muốn, bỏ qua các phần không liên quan của tài liệu

Nói cách khác, nếu bạn biết được trong tài liệu đó phần tử mong muốn sẽ được đặt

ở đâu, nó sẽ giúp cung cấp các thông tin đó dưới hình thức một đường cụ thể đầy

đủ Nếu bạn yêu cầu //phone thay cho /customerinfo/phone, bạn yêu cầu các phần

tử phone bất kỳ ở đâu trong tài liệu Điều này đòi hỏi DB2 chuyển hướng xuống vào nhánh cây con "addr" của tài liệu để tìm các phần tử phone ở bất kỳ mức tài liệu nào Đây là hoạt động vượt quá có thể tránh được

Lưu ý rằng * và // cũng có thể dẫn đến kết quả truy vấn không mong muốn hoặc bất ngờ Ví dụ, nếu một số tài liệu "customerinfo" cũng có chứa thông tin "trợ lý" ("assistant"), giống như một bảng dưới đây Đường dẫn //phone sẽ trả về các số điện thoại của khách hàng và số điện thoại trợ lý, không phân biệt chúng Từ các kết quả truy vấn bạn thậm chí sẽ không biết và xử lý nhầm lẫn số điện thoại trợ lý như là một số điện thoại của khách hàng

Liệt kê 7 Các phần tử tên và số điện thoại ở nhiều mức trong tài liệu