Tài liệu An toàn DB2 UDB, Phần 1: Hiểu cách các tài khoản người dùng và nhóm tương tác với DB2 UDB ppt

An toàn DB2 UDB, Phần 1: Hiểu cách các tài khoản
người dùng và nhóm tương tác với DB2 UDB
Giới thiệu
Những người mới dùng DB2 UDB thường hay hỏi về các tài khoản người dùng và nhóm cần
thiết cho một bản cài đặt và môi trường hoạt động của DB2 UDB. Trong bài này, bạn sẽ tìm hiểu
về các tương tác chính của DB2 UDB với những người dùng và các nhóm. Bài này mô tả tài
khoản người dùng mà bạn sẽ cần đến khi cài đặt DB2 UDB trên các hệ điều hành Linux, UNIX
và Windows, cũng như các tài khoản bổ sung mà bạn sẽ cần để chạy các quy trình và các dịch vụ
DB2 UDB khác nhau. Bài này cũng đánh giá mô hình an toàn DB2 UDB, bao gồm việc xác thực
người dùng, ủy quyền của người dùng và nhóm, và các siêu người dùng. Bài này áp dụng cho
Phiên bản 8.2 của DB2 UDB cho Linux, UNIX, và Windows; tuy nhiên, nhiều phần trong bài
này cũng có thể áp dụng cho các phiên bản DB2 UDB cũ hơn.
Về đầu trang
Mô hình an toàn DB2 UDB
Mô hình an toàn DB2 UDB gồm hai thành phần chính: xác thực và ủy quyền. Hình 1 đưa ra một
tổng quan về mô hình an toàn DB2 UDB.

Hình 1. Mô hình an toàn DB2 UDB

Xác thực
Việc xác thực là quá trình xác nhận hợp lệ một mã định danh (ID) và mật khẩu đã cấp cho người
dùng khi sử dụng một cơ chế an toàn. Việc xác thực người dùng và nhóm được quản lý trong
một phương tiện ngoài thay cho DB2 UDB, như hệ điều hành, một trình điều khiển miền, hoặc
một hệ thống an toàn Kerberos. Điều này khác với các hệ thống quản lý cơ sở dữ liệu khác (các
DBMS), như Oracle và SQL Server, là ở đây các tài khoản người dùng có thể được định nghĩa
và xác thực trong chính cơ sở dữ liệu đó, cũng như trong một phương tiện bên ngoài như hệ điều
hành.
Bất kỳ lúc nào cung cấp trực tiếp cho DB2 UDB một ID và mật khẩu người dùng như là một
phần của một cá thể đính kèm hoặc yêu cầu kết nối cơ sở dữ liệu, DB2 UDB cố gắng xác nhận
ID và mật khẩu người dùng đó bằng cách sử dụng phương tiện an toàn bên ngoài này. Nếu ID
hoặc mật khẩu người dùng không được cung cấp kèm với yêu cầu, DB2 UDB ngầm sử dụng ID

và mật khẩu người dùng đã được sử dụng để đăng nhập vào máy trạm, nơi tạo ra yêu cầu này.
Giá trị của tham số AUTHENTICATION của cá thể DB2 UDB xác định vị trí xác thực thực tế. Các
lược đồ xác thực khác nhau gồm những người dùng đã xác thực trên chính máy chủ DB2 UDB
đó (bằng cách sử dụng phương tiện chức năng an toàn của máy chủ), trên máy khách (cho phép
truy cập "đăng nhập một lần"), một phương tiện an toàn Kerberos, hoặc một trình cắm thêm GSS
(Generic Security Service – Dịch vụ an toàn chung) do người dùng định nghĩa. Các tùy chọn xác
thực bổ sung gồm khả năng mã hóa các tên và các mật khẩu người dùng, cũng như dữ liệu, khi
chúng truyền trên mạng giữa máy khách và máy chủ. Giá trị mà bạn chọn cho tham số
AUTHENTICATION tùy thuộc vào môi trường cụ thể của bạn cũng như các chính sách an toàn cục
bộ. Để có một mô tả đầy đủ về các lược đồ xác thực khác nhau, hãy tham khảo Tài liệu DB2
UDB. (Xem phần Tài nguyên.)
Ví dụ, Hình 1 cho thấy câu lệnh kết nối được một người dùng có tên là bob sử dụng để nối tới cơ
sở dữ liệu finance (tài chính) bằng mật khẩu bobpsw. Có sáu bước xảy ra trong quá trình xác
thực này:
1. Câu lệnh CONNECT được truyền đến máy chủ DB2 UDB.
2. Nếu vẫn chưa cấu hình trình cắm thêm an toàn, thì sẽ sử dụng trình cắm thêm mặc định.
Khi tham số AUTHENTICATION của cá thể có chứa cơ sở dữ liệu finance được thiết lập là
SERVER (thiết lập mặc định), phương tiện chức năng an toàn trên máy chủ DB2 UDB sẽ
xác thực ID và mật khẩu người dùng được cấp trong yêu cầu kết nối. Trình cắm thêm
mặc định sẽ gửi ID và mật khẩu người dùng tới hệ điều hành để xác nhận hợp lệ.
3. Hệ điều hành xác nhận xem liệu tổ hợp bob/bobpsw có hợp lệ hay không, và trả về thông
tin này cho trình cắm thêm an toàn.
4. Trình cắm thêm an toàn gọi cơ chế an toàn DB2 UDB để truy vấn các bảng danh mục
DB2 UDB cho người dùng bob để xem liệu người dùng có tên đó đã được cấp đặc quyền
CONNECT với cơ sở dữ liệu đó chưa. Theo mặc định, đặc quyền CONNECT được cấp
PUBLIC (CÔNG KHAI), có nghĩa là bất kỳ người dùng nào được xác thực thành công
đều có thể kết nối tới cơ sở dữ liệu này.
5. Cơ chế an toàn DB2 UDB xác nhận hợp lệ người dùng bob, hoặc trả về một lỗi.
6. Trình cắm thêm an toàn trả về cho người dùng một thông báo thành công hay thất bại.
Nếu người dùng không thể xác thực thành công, DB2 UDB từ chối yêu cầu kết nối và trả

về một thông báo lỗi cho ứng dụng khách, tương tự như sau:

Liệt kê 1. DB2 UDB trả về một thông báo cho ứng dụng này khi xác thực người dùng
không thành công
SQL30082N Attempt to establish connection
failed with security
reason "24" ("USERNAME AND/OR PASSWORD
INVALID"). SQLSTATE=08001

Một mục nhập tương tự như sau cũng xuất hiện trong bản ghi nhật ký chẩn đoán DB2 UDB
(db2diag.log) trên máy chủ DB2 UDB:

Liệt kê 2. Thông báo trong bản ghi nhật ký chẩn đoán của DB2 khi xác thực người dùng
không thành công
2005-07-09-16.18.33.546000-
240 I729347H256
LEVEL: Severe
PID : 3888 TID : 604
FUNCTION: DB2 Common, Security, Users and
Groups, secLogMessage, probe:20
DATA #1 : String, 44 bytes
check password failed with rc = -2146500502

Trên Windows, có thể tìm thấy bản ghi nhật ký chẩn đoán trong thư mục gốc Instance, theo mặc
định là C:\Program Files\IBM\SQLLIB\DB2 . Trên UNIX, theo mặc định, bản ghi này đặt ở
<DB2PATH>/DB2/db2dump, ở đây <DB2PATH> là đường dẫn của chủ sở hữu cá thể.
Nếu bạn luôn gặp phải các thông báo này, hãy bảo đảm rằng người dùng hay ứng dụng nối đến
cơ sở dữ liệu đã cung cấp một ID và mật khẩu người dùng hợp lệ. ID và mật khẩu người dùng
này phải tồn tại trong phương tiện mà việc xác thực người dùng được thiết lập để diễn ra ở đó
(được xác định bởi tham số AUTHENTICATION của cá thể DB2 UDB đích).

Uỷ quyền
Uỷ quyền là quá trình xác định thông tin truy cập và đặc quyền về các đối tượng và các hành
động của cơ sở dữ liệu cụ thể đối với một ID người dùng đã cấp. DB2 UDB lưu trữ và duy trì
thông tin ủy quyền người dùng và nhóm ở bên trong. Mỗi lần bạn gửi đi một lệnh, DB2 UDB
thực hiện kiểm tra ủy quyền để đảm bảo rằng bạn có tập đặc quyền đúng để thực hiện hành động
đó.
Các đặc quyền có thể được cấp cho những người dùng cụ thể hoặc cho các nhóm người dùng.
Thêm nữa, cả hai định nghĩa người dùng và định nghĩa nhóm tự chúng được định nghĩa bên
ngoài DB2 UDB. Những người dùng là một thành viên của một nhóm tự động thừa hưởng các
đặc quyền của nhóm. Các đặc quyền cụ thể được cấp cho một người dùng có tiền lệ hơn các đặc
quyền liên quan với bất kỳ (các) nhóm mà người dùng là một thành viên, và vẫn cứ tồn tại ngay
cả khi sau đó người dùng bị loại khỏi (các) nhóm đó. Có nghĩa là, các đặc quyền trực tiếp đã cấp
cho một người dùng phải trực tiếp bị hủy bỏ.
Hầu hết các đối tượng cơ sở dữ liệu có một tập các đặc quyền liên quan có thể được gán cho
những người dùng và các nhóm, bằng cách sử dụng các câu lệnh SQL GRANT (cấp) và
REVOKE (hủy bỏ). Ví dụ, câu lệnh SQL dưới đây cấp đặc quyền SELECT (chọn) trên bảng có
tên là ADM.ACCTABC cho một người dùng tên là bob:
GRANT SELECT ON TABLE ADM.ACCTABC TO USER BOB
Một khi ban hành câu lệnh này, người dùng bob có thể gửi đi các câu lệnh SELECT để tham
khảo bảng này. Cũng vậy, câu lệnh SQL sau hủy bỏ đặc quyền INSERT (chèn) trên một khung
nhìn (view) tên là ADM.LEGERS từ một nhóm có tên là clerks (các thư ký):
REVOKE INSERT ON VIEW ADM.LEGERS FROM GROUP CLERKS
Bạn chỉ có thể hủy bỏ một đặc quyền đã cấp trước đây. Để biết thông tin chi tiết về tất cả các đặc
quyền của đối tượng cơ sở dữ liệu khác nhau, có thể được cấp cho những người dùng và các
nhóm, hãy tham khảo tài liệu DB2 UDB (xem phần Tài nguyên).
Điều quan trọng cần lưu ý, đặc biệt với những người mới dùng DB2 UDB, câu lệnh GRANT
không kiểm tra sự tồn tại của một tài khoản người dùng hoặc tài khoản của nhóm trong phương
tiện bên ngoài. Điều này có nghĩa là có thể cấp các đặc quyền cho các tài khoản người dùng và
nhóm không tồn tại theo thông tin được lưu trữ trong cơ sở dữ liệu. Điều này gây ra cảm giác sai
lầm rằng các tài khoản người dùng và nhóm có thể được định nghĩa trong DB2 UDB. Ví dụ, nếu

bạn đưa ra câu lệnh sau trong khi kết nối tới cơ sở dữ liệu finance:
GRANT SELECT ON TABLE ADM.TAXCODE TO USER XYZ
ở đây xyz là bất kỳ chuỗi ký tự nào không ánh xạ tới một người dùng hiện có trong phương tiện
an toàn bên ngoài, sau đó DB2 UDB sẽ hiển thị xyz trong các công cụ giao diện người dùng đồ
họa (GUI) của nó hoặc trong một số các bảng danh mục, như được minh họa trong Hình 2. Điều
này không có nghĩa là một người dùng tên là xyz tồn tại hoặc đã được tạo ra.

Hình 2. Các đặc quyền bảng sau khi cấp các đặc quyền cho một người dùng không xác
định

Phần dưới cùng của Hình 1 cho thấy một ví dụ về một kịch bản uỷ quyền. Người dùng có tên là
bob, người trước đó đã kết nối thành công, bây giờ cố gắng thực hiện một câu lệnh SELECT trên
bảng ADM.TAXCODES. DB2 UDB sẽ tìm trong các bảng danh mục của nó để xem liệu người
dùng này đã được cấp phép với câu lệnh SELECT từ bảng này chưa. Do đặc quyền này trước
đây được cấp cho bob, nên DB2 UDB cho phép tiếp tục thực hiện câu lệnh SELECT.
Nếu người dùng không được uỷ quyền thực hiện một hoạt động đối với một đối tượng cụ thể,
DB2 UDB từ chối hoạt động này và trả về một thông báo lỗi đến ứng dụng khách. Ví dụ, nếu
người dùng bob đã cố INSERT (chèn) một hàng vào bảng ADM.TAXCODES, nhưng lại không
có đủ các đặc quyền để làm như vậy, thông báo lỗi sau sẽ được trả về:

Liệt kê 3. DB2 UDB trả về thông báo khi ủy quyền người dùng không thành công
DB21034E The command was processed as an SQL
statement because it
was not a valid Command Line Processor
command. During SQL
processing it returned:
SQL0551N "BOB" does not have the privilege to
perform
operation "INSERT" on object "ADM.TAXCODES".

SQLSTATE=42501

Nếu bạn luôn gặp phải các thông báo tương tự, hãy bảo đảm rằng ID người dùng được đưa ra để
nối tới cơ sở dữ liệu có các đặc quyền thích hợp để thực hiện hoạt động đích. Người dùng phải
được cấp trực tiếp đặc quyền đó, là một phần của một nhóm đã được cấp đặc quyền đó, hoặc là
một siêu người dùng.
Các siêu người dùng
Có thể chọn các nhóm người dùng nào đó khi có các ủy quyền cá thể và cơ sở dữ liệu đặc biệt.
DB2 UDB định nghĩa một hệ thống phân cấp về các ủy quyền siêu người dùng (SYSADM,
SYSCTRL, SYSMAINT, SYSMON), mỗi ủy quyền có khả năng thực hiện một tập con các hoạt
động quản trị ví dụ như tạo một cơ sở dữ liệu, bắt buộc những người dùng thoát khỏi hệ thống,
và lấy một bản sao lưu cơ sở dữ liệu. Để biết một cuộc thảo luận đầy đủ về các mức ủy quyền,
hãy tham khảo tài liệu DB2 UDB (xem phần Tài nguyên).
Bạn có thể cấu hình các ủy quyền cá thể bằng cách sử dụng các tham số mức-cá thể có liên quan
(SYSADM_GROUP, SYSCTRL_GROUP, SYSMAIN_GROUP, SYSMON_GROUP). Có thể thiết lập từng tham
số theo tên của nhóm những người dùng (được định nghĩa bên ngoài của DB2 UDB) có thể có ủy
quyền đó.
Ví dụ, nếu bạn định nghĩa một nhóm có tên là snrdba chứa tất cả các tài khoản người dùng DBA
cao cấp, bạn có thể tạo tất cả các siêu người dùng SYSADM của những người dùng này bằng
cách thiết lập giá trị của tham số cá thể SYSADM_GROUP là snrdba, khi sử dụng các lệnh sau đây:

Liệt kê 4. Cập nhật tham số cá thể SYSADM_GROUP
UPDATE DBM CFG USING SYSADM_GROUP
snrdba
db2stop
db2start

Sau đó tất cả những người dùng trong nhóm snrdba sẽ có tất cả các đặc quyền liên quan đến mức
ủy quyền SYSADM và do đó có thể thực hiện tất cả các nhiệm vụ quản trị đòi hỏi mức ủy quyền
đó.

Việc định nghĩa các ủy quyền theo cách này cho phép bạn phân biệt giữa các quản trị viên DB2
UDB và các quản trị viên hệ thống/mạng. Ví dụ, có thể một quản trị viên (DBA) được yêu cầu
có đầy đủ ủy quyền quản trị trên cá thể DB2 UDB, nhưng không phải trên máy tính hoặc mạng
cục bộ. Trong trường hợp này, có thể thêm tài khoản người dùng của DBA vào một nhóm không
có các quyền truy cập đầy đủ vào hệ thống/mạng, nhưng có thể có các quyền truy cập đầy đủ vào
cá thể DB2 UDB, bằng cách xác định tên nhóm đó trong tham số cá thể SYSADM_GROUP.
Trong lúc cài đặt DB2 UDB mặc định trên Windows, các giá trị của các tham số ủy quyền siêu
người dùng mức-cá thể này (SYSADM_GROUP, SYSCTRL_GROUP, SYSMAIN_GROUP, SYSMON_GROUP)
mặc định tới NULL (bằng không). Điều này có nghĩa là ủy quyền siêu người dùng được cấp cho
bất kỳ tài khoản hợp lệ nào thuộc về nhóm Administrators (các quản trị viên) cục bộ. Chúng tôi
đánh giá cao đề nghị thay đổi trực tiếp giá trị của các tham số này theo các tên nhóm hợp lệ để
ngăn chặn truy cập trái phép. Trên các bản cài đặt Linux và UNIX, việc này không phải là một
mối quan tâm lớn, vì một giá trị NULL mặc định cho nhóm chính của chủ sở hữu cá thể, mà theo
mặc định sau khi cài đặt chủ sở hữu cá thể chỉ gồm có ID người dùng của mình.
Cũng có thể gán cho những người dùng một tập các ủy quyền mức-cơ sở dữ liệu. Các ủy quyền
cơ sở dữ liệu được cấp bằng cách sử dụng các câu lệnh SQL GRANT và REVOKE tiêu chuẩn.
Có thể tìm thấy nhiều thông tin hơn về các mức ủy quyền cơ sở dữ liệu trong tài liệu DB2 UDB
(xem phần Tài nguyên.)
Các lệnh hệ thống DB2 UDB như db2, db2ilist, db2start, db2stop, db2iupdt và v.v , là các
lệnh có thể thực thi được của hệ điều hành. Vì vậy, cơ chế an toàn để chạy các lệnh này được
dựa vào các quyền hạn của các tệp của hệ điều hành. Các quyền hạn của các tệp được thiết lập
lúc cài đặt DB2 UDB.
Về đầu trang
Các quy tắc đặt tên tài khoản người dùng và nhóm của DB2 UDB
Trong DB2 UDB, các tài khoản người dùng và nhóm phải tuân thủ các quy tắc đặt tên được mô
tả trong Bảng 1 và 2. Các hạn chế này nằm ngoài bất kỳ các hạn chế nào có hiệu lực trong
phương tiện ở đó định nghĩa các tài khoản.
Bảng 1. Các giới hạn và các hạn chế bởi nền
tảng
Giới hạn Windows Linux/UNIX

Độ dài tên
nhóm
Lên đến 30 ký tự

Lên đến 30 ký
tự
Độ dài tên
người dùng
Lên đ
ến 30 ký tự
(1) (2)
Lên đến 8 ký
tự
Trường hợp
Không phân biệt
dạng chữ
Chỉ chữ
thường
(1) Windows NT®, Windows 2000®, Windows XP® và Windows Server® 2003 hiện đang có
giới hạn thực tế là 20 ký tự.
(2) Khi không sử dụng xác thực máy khách, các máy khách 32-bit không phải Windows đang nối
với Windows NT, Windows 2000, Windows XP và Windows Server 2003 có hỗ trợ các tên
người dùng dài hơn 8 ký tự khi tên và mật khẩu người dùng được quy định rõ ràng.
Bảng 2 cho thấy các hạn chế đặt tên với tất cả các nền tảng.
Bảng 2. Các hạn chế đặt tên cho tất cả các nền tảng
Quy tắc Giá trị
Các từ dành
riêng không
được phép

USERS, ADMINS, GUESTS, PUBLIC (3),
LOCAL, hoặc bất kỳ từ SQL dành riêng nào
Các tên không
thể bắt đầu
bằng
IBM, SQL, SYS, một số hoặc một dấu gạch
dưới
Các ký tự
không được
Các ký tự có trọng âm
phép
Các ký tự được
phép (4)
Từ A đến Z (Khi sử dụng trong hầu hết các
tên, các ký tự từ A đến Z được chuyển đổi từ
chữ thường thành chữ hoa).

0 đến 9

! % ( ) { } . - ^ ~ _ (dấu gạch dưới) 7 @, #, $,
\ (dấu gạch chéo ngược) và khoảng trống
(3) DB2 UDB sử dụng bên trong một nhóm-giả có tên là PUBLIC (công khai), có thể cấp và hủy
bỏ các đặc quyền. Trên thực tế PUBLIC không phải là một nhóm được định nghĩa trong phương
tiện an toàn ngoài. Đó là một cách để gán các đặc quyền cho bất kỳ người dùng nào đã xác thực
thành công.
(4) Cũng có thể sử dụng các ký tự đặc biệt khác, tùy thuộc vào hệ điều hành của bạn và ở đó bạn
đang làm việc với DB2 UDB. Tuy nhiên, để tránh sự không nhất quán và các vấn đề tiềm năng,
không sử dụng các ký tự đặc biệt khác này khi đặt tên các đối tượng trong cơ sở dữ liệu của bạn.
Việc cài đặt DB2 UDB với các ID người dùng mặc định (ví dụ, db2admin) và cung cấp một mật
khẩu yếu (hoặc không có gì cả) có thể đặt hệ thống của bạn vào nguy hiểm. Nhiều virus, sâu và

những con ngựa thành trojan (trojan horses) của máy tính được thiết kế để khai thác mật khẩu
yếu. Ví dụ, rất nhiều chương trình cố dùng các mật khẩu phổ biến như "password", "123456",
"111111", "db2admin" và v.v để đạt được quyền truy cập vào hệ thống. Do đó, điều quan trọng
không nên coi thường mật khẩu của bạn.
Các mật khẩu cũng rất quan trọng khi xác thực những người dùng. Ví dụ, trên các hệ điều hành
Linux và UNIX, các mật khẩu không xác định được xử lý là NULL (bằng không). Bất kỳ người
dùng nào không có một mật khẩu xác định được coi là có mật khẩu NULL. Từ quan điểm của hệ
điều hành, đây là một cuộc đấu và người dùng được xác nhận hợp lệ và có thể kết nối với cơ sở
dữ liệu.
Về đầu trang
Một bản cài đặt DB2 UDB tạo ra và yêu cầu các tài khoản người dùng và nhóm
Các môi trường cơ sở dữ liệu phân vùng
Trong một môi trường cơ sở dữ liệu phân vùng có sử dụng tính năng phân vùng dữ liệu (DPF)
của DB2 UDB, mỗi phân vùng cơ sở dữ liệu phải có cùng tập những người dùng và các nhóm
được định nghĩa. Nếu các định nghĩa không giống nhau, người dùng có thể không được ủy quyền
thực hiện các hành động cần thiết trên một số phân vùng. Tính nhất quán trên tất cả các phân
vùng rất quan trọng.
Một bản cài đặt DB2 UDB đòi hỏi một tài khoản người dùng có các quyền quản trị để thực hiện
việc cài đặt. Người dùng này yêu cầu các đặc quyền cụ thể tùy thuộc vào nền tảng mà DB2 UDB
đang được cài đặt trên đó. Theo mặc định, DB2 UDB tạo ra một số tài khoản người dùng và
nhóm trong lúc cài đặt. Các tài khoản này được sử dụng để "sở hữu" và khởi động các dịch vụ và
quá trình DB2 UDB khác nhau đang chạy trên máy chủ.
Trong phần này, chúng tôi mô tả các đặc quyền người dùng cần thiết để thực hiện một bản cài
đặt DB2 UDB trong môi trường Windows, Linux, và UNIX. Chúng tôi cũng nêu bật các tài
khoản người dùng và nhóm khác nhau được tạo trong một bản cài đặt DB2 UDB mặc định.
Các tài khoản người dùng và nhóm cần thiết trên các hệ điều hành Microsoft Windows
Nếu bạn đang cài đặt DB2 UDB trên các hệ điều hành Windows, bạn sẽ yêu cầu các tài khoản
người dùng sau đây:
 Tài khoản người dùng cài đặt.
 Tài khoản người dùng DAS (DB2 Administration Server – Máy chủ quản trị DB2).

 Tài khoản người dùng của chủ sở hữu cá thể DB2 UDB.
Tài khoản người dùng cài đặt
Trước khi chạy Trình hướng dẫn cài đặt DB2 (DB2 Setup wizard), bạn cần phải định nghĩa một
tài khoản người dùng cài đặt. Tài khoản này có thể là một tài khoản người dùng hay miền cục bộ.
Tài khoản phải thuộc nhóm Administrators trên máy tính thực hiện cài đặt này. Khi sử dụng các
tài khoản miền, tài khoản cài đặt phải thuộc nhóm Domain Administrators (Các quản trị viên
miền) trên miền ở đó các tài khoản người dùng thiết lập khác sẽ được tạo ra. Bạn cũng có thể sử
dụng tài khoản LocalSystem dựng sẵn để chạy cài đặt này cho tất cả các sản phẩm ngoại trừ DB2
UDB Enterprise Server Edition (Ấn bản doanh nghiệp của máy chủ DB2 UDB).
Bạn có thể định nghĩa các tài khoản người dùng khác trước lần cài đặt này, hoặc bạn có thể để
cho Trình hướng dẫn cài đặt DB2 tạo chúng cho bạn. Tất cả các tên tài khoản người dùng phải
tuân theo các quy tắc đặt tên hệ thống của bạn cũng như các quy tắc đặt tên của DB2 UDB.
Tài khoản người dùng DAS
Cần có một tài khoản cục bộ và miền để quản lý DAS (Máy chủ quản trị DB2). DAS là một dịch
vụ đặc biệt hỗ trợ các công cụ GUI và trợ giúp các nhiệm vụ quản trị. DAS có một tài khoản
người dùng đã gán dùng để để khởi động dịch vụ khi DB2 UDB được tải. Trong Trình hướng
dẫn cài đặt DB2, một trong các màn hình (được hiển thị trong Hình 3) sẽ nhắc bạn chọn một tài
khoản người dùng có thể được dùng để khởi động dịch vụ DAS.

Hình 3. Chỉ định tài khoản người dùng DAS trong Trình hướng dẫn cài đặt DB2

Bạn có thể tạo tài khoản người dùng này trước khi cài đặt DB2 UDB và chỉ rõ nó trong màn hình
này, hoặc bạn có thể dùng Trình hướng dẫn cài đặt DB2 tạo nó cho bạn. Theo mặc định, trình
hướng dẫn này tạo ra một tài khoản mới tên là db2admin (tuy vậy, bạn có thể đặt cho nó bất cứ
tên nào bạn thích). Tài khoản người dùng DAS cũng phải thuộc nhóm Administrators trên máy
tính ở đó bạn sẽ thực hiện cài đặt này. Nếu bạn muốn dùng Trình hướng dẫn cài đặt DB2 tạo một
tài khoản người dùng miền mới, tài khoản người dùng mà bạn sử dụng để thực hiện cài đặt này
phải có quyền tạo các tài khoản người dùng miền.
Các quyền người dùng sau đây sẽ được cấp tự động cho tài khoản này khi nó được các trình
hướng dẫn cài đặt tạo ra:

 Làm thay một phần của hệ điều hành
 Gỡ lỗi các chương trình
 Tạo đối tượng mã thông báo
 Tăng các hạn ngạch
 Khóa các trang trong bộ nhớ
 Đăng nhập là một dịch vụ
 Thay thế một mã thông báo mức quy trình
Nếu bạn đã tạo hoặc quy định một tài khoản khác, hãy chắc chắn tài khoản đó cũng có các quyền
người dùng nói trên. Để đảm bảo các quyền này được thiết lập đúng, mở Control Panel của
Windows (Start > Settings > Control Panel) và nhấn đúp chuột vào biểu tượng Administrative
Tools (Các công cụ quản trị). Nhấn đúp chuột vào biểu tượng Local Security Policy (Chính
sách an toàn cục bộ). Đối với từng chính sách được liệt kê ở trên, đảm bảo rằng người dùng được
bao gồm trong danh sách của những người dùng và các nhóm có ủy quyền. Việc cung cấp một
mật khẩu không đúng sẽ làm cho một dịch vụ không tải được trong lúc khởi động DB2 UDB và
có khả năng ngăn không cho bạn thực hiện một số hoạt động.
Trong lúc cài đặt, bạn cũng có thể chỉ dẫn Trình hướng dẫn cài đặt DB2 sử dụng cùng một tài
khoản này (tài khoản mà bạn đã chỉ định cho DAS) cho mình và khởi động tất cả các dịch vụ
khác của DB2 UDB cũng được. Để làm điều này, hãy chắc chắn đánh dấu chọn hộp kiểm "Use
the same user name and password for the remaining DB2 UDB services" (Sử dụng cùng một
tên người dùng và mật khẩu cho các dịch vụ còn lại của DB2 UDB) (xem Hình 3). Nếu bạn bỏ
dấu chọn của hộp này, trình hướng dẫn sẽ nhắc bạn chọn một tài khoản người dùng cho mình và
khởi động cá thể mặc định đã tạo. Tất cả các dịch vụ DB2 UDB khác sẽ sử dụng tài khoản
LocalSystem dựng sẵn của Windows để khởi động.
Bạn cũng nên đảm bảo rằng tài khoản người dùng DAS có ủy quyền SYSADM trên từng hệ
thống DB2 UDB trong môi trường của bạn, sao cho nó có thể khởi động hoặc dừng các cá thể
khác khi cần thiết. Theo mặc định, sau khi cài đặt DB2 UDB trong môi trường Windows, bất kỳ
người dùng nào, là một phần của Administrators, cũng có ủy quyền SYSADM. Tên dịch vụ DAS
được gọi là DB2DAS - DB2DAS00.
Tài khoản người dùng chủ sở hữu cá thể của DB2 UDB
Cần phải có một tài khoản cục bộ và miền cho riêng mình và khởi động một cá thể DB2 UDB.

Bạn có thể tạo tài khoản người dùng của chủ sở hữu cá thể DB2 UDB trước khi cài đặt DB2
UDB, hoặc bạn có thể dùng Trình hướng dẫn cài đặt DB2 tạo nó cho bạn. Nếu bạn muốn dùng
Trình hướng dẫn cài đặt DB2 tạo một tài khoản người dùng miền mới cho bạn, khi bạn thực hiện
lần cài đặt này bạn phải sử dụng một tài khoản người dùng có ủy quyền để tạo các tài khoản
người dùng miền. Tài khoản người dùng cũng phải thuộc nhóm Administrators trên máy tính mà
bạn sẽ thực hiện lần cài đặt này. Các quyền người dùng sau sẽ được cấp tự động cho tài khoản
này khi được Trình hướng dẫn cài đặt DB2 tạo:
 Làm thay một phần của hệ điều hành
 Gỡ lỗi các chương trình
 Tạo đối tượng mã thông báo
 Tăng các hạn ngạch
 Khóa các trang trong bộ nhớ
 Đăng nhập là một dịch vụ
 Thay thế một mã thông báo mức quy trình
Nếu bạn đã tạo hoặc quy định một tài khoản khác, hãy chắc chắn tài khoản đó cũng có các quyền
người dùng nói trên. Để đảm bảo các quyền này được thiết lập đúng, mở Control Panel của
Windows (Start > Settings > Control Panel) và nhấn đúp chuột vào biểu tượng Administrative
Tools. Nhấn đúp chuột vào biểu tượng Local Security Policy. Đối với từng chính sách được liệt
kê ở trên, đảm bảo rằng người dùng được bao gồm trong danh sách của những người dùng và các
nhóm có ủy quyền. Việc cung cấp một mật khẩu không đúng sẽ làm cho một dịch vụ không tải
được trong lúc khởi động DB2 UDB và có khả năng ngăn không cho bạn thực hiện một số hoạt
động.
Trong một bản cài đặt mặc định của Windows, một cá thể có tên là DB2 được tạo ra tự động.
Bạn có thể tạo ra các cá thể khác hoặc loại bỏ các cá thể hiện có bằng cách sử dụng các tiện ích
tương ứng là db2icrt và db2idrop. Có thể tìm thấy các tiện ích này trong thư mục
DB2PATH\sqllib\bin, ở đây DB2PATH DB2PATH là nơi bạn đã cài đặt DB2 UDB. Để chạy các
tiện ích này, bạn phải sử dụng một tài khoản người dùng có ủy quyền Administrator cục bộ. Nếu
bạn đưa ra một tài khoản và mật khẩu người dùng làm các tham số khi bạn tạo ra cá thể này, nó
sẽ sử dụng tài khoản người dùng đó cho riêng mình và khởi động dịch vụ. Nếu bạn không cung
cấp một tài khoản và mật khẩu người dùng, tài khoản LocalSystem sẽ được sử dụng để thay thế.

Ví dụ, lệnh sau đây tạo ra một cá thể mới gọi là devinst, và gán tài khoản LocalSystem cho riêng
nó và khởi động quy trình cá thể:

Liệt kê 5. Tạo một cá thể DB2 UDB mới trong Windows
db2icrt devinst

Thay đổi thông tin tài khoản
Ngoài ra, khi bắt đầu với Phiên bản 8.2 của DB2 UDB, bạn có thể sử dụng tài khoản
LocalSystem (LSA) dựng sẵn để khởi động một dịch vụ DB2 UDB. Việc sử dụng LSA có thể
thuận lợi trên các hệ thống ở đó bắt tuân thủ các chính sách mật khẩu nghiêm ngặt, vì LSA
không liên kết với một mật khẩu. Ví dụ, trong một số môi trường, những người dùng buộc phải
thay đổi các mật khẩu của họ hai tháng một lần, hoặc tài khoản của họ tạm thời bị khóa. Do đó,
một chính sách như vậy sẽ đòi hỏi phải thay đổi mật khẩu cho tài khoản người dùng được chỉ
định để khởi động các dịch vụ DB2 UDB. Nếu tài khoản người dùng được cấu hình để khởi động
các dịch vụ trở nên bị khóa, hoặc tài khoản người dùng đã thay đổi mật khẩu, nhưng chưa được
cập nhật trong các thuộc tính khởi động dịch vụ, thì các dịch vụ đó sẽ không thể khởi động được.
Trước khi chuyển đổi bất kỳ các dịch vụ DB2 UDB nào từ một tài khoản người dùng dành riêng
sang tài khoản LocalSystem, bạn nên cân nhắc là tài khoản LocalSystem không thể truy cập vào
các phần chia sẻ trên LAN được, vì không thể xác thực nó trên máy tính khác. Do đó, bạn phải
đảm bảo rằng hệ thống DB2 UDB của bạn không có bất kỳ tài nguyên tệp nào của nó trên máy
tính khác.
Các ứng dụng chạy trong ngữ cảnh của tài khoản LocalSystem (LSA) sử dụng các kết nối DB2
UDB ngầm cục bộ. Nếu bạn đang phát triển một ứng dụng sẽ chạy trong tài khoản này, nên hiểu
rõ rằng DB2 UDB có các hạn chế trên các đối tượng có các tên lược đồ bắt đầu bằng "SYS". Nếu
các ứng dụng của bạn có chứa các câu lệnh tạo các đối tượng DB2 UDB, cần phải viết chúng
như sau:
 Đối với SQL tĩnh, cần kết buộc chúng với một giá trị cho các tùy chọn QUALIFIER khác
với giá trị mặc định.
 Đối với SQL động, các đối tượng được tạo ra cần có đủ điều kiện rõ ràng với một tên
lược đồ được DB2 UDB hỗ trợ, hoặc phải thiết lập thanh ghi CURRENT SCHEMA (lược đồ

hiện tại) cho một lược đồ.
Hình 4 cho thấy một danh sách của một số các quá trình DB2 UDB đang chạy trên một hệ thống
DB2 UDB đang hoạt động. Như bạn có thể thấy, mỗi quy trình có liên quan với một chủ sở hữu
(tên người dùng). Để có một mô tả về tất cả các quy trình liên kết với DB2 UDB, hãy tham khảo
"Tất cả mọi thứ bạn muốn biết về các quy trình cơ sở dữ liệu phổ biến của DB2"
(developerWorks, 04. 2003).

Hình 4. Xem các quy trình DB2 UDB đang chạy

Để thay đổi tài khoản người dùng đang được dùng để khởi động một dịch vụ DB2 UDB, hãy mở
ô Services (Start > Settings > Control Panel > Administrative Tools > Services). Nhấn chuột
phải vào một dịch vụ DB2 UDB để xem các đặc tính của nó. Nhấn vào thẻ Log On ở trên cùng
của cửa sổ Service properties (Các thuộc tính dịch vụ) (Hình 5). Trong thẻ này, bạn có thể chỉ rõ
tài khoản người dùng mà bạn muốn dịch vụ sử dụng khi khởi động nó, hoặc bạn có thể chỉ định
LSA. Nhấn vào OK để lưu lại các lựa chọn của bạn và đóng cửa sổ các thuộc tính cho dịch vụ
đó.

Hình 5. Cửa sổ Các đặc tính đăng nhập dịch vụ DAS

Nói chung, bạn nên sử dụng một tài khoản người dùng riêng biệt và dễ định danh để khởi động
các dịch vụ DB2 UDB. Tuy nhiên, nếu các tài khoản người dùng được kiểm soát chặt chẽ hơn
trong môi trường của bạn, bạn có tùy chọn sử dụng các tài khoản người dùng hiện có hoặc sử
dụng tài khoản LocalSystem để khởi động các dịch vụ này. Sau khi thiết lập một tài khoản để
chạy một dịch vụ, không thể xóa được tài khoản đó hoặc trái lại các dịch vụ khác có liên quan
đến tài khoản đó sẽ không khởi động được. Điều này đúng ngay cả khi bạn tạo lại tài khoản bằng
cách sử dụng cùng một tên. Trong các trường hợp như vậy, bạn phải chuyển vào ô các dịch vụ
bằng thủ công như đã mô tả trước đây và cấu hình lại tài khoản người dùng được sử dụng để
khởi động dịch vụ.
Các nhóm DB2USERS và DB2ADMNS
Khi bắt đầu với phiên bản 8.2 của DB2 UDB, tính năng an toàn bổ sung được thêm vào DB2

UDB trong môi trường Windows. Một tùy chọn mới tồn tại như là một phần của bản cài đặt DB2
UDB để tạo hai nhóm bổ sung trong hệ điều hành, đó là, DB2USERS và DB2ADMNS. Một khi
đã tạo các nhóm này, chỉ các tài khoản người dùng là các thành viên của các nhóm này mới có
quyền truy cập các tệp DB2 UDB trên hệ thống (bao gồm các lệnh cũng như các tệp dữ liệu
người dùng được DB2 UDB tạo ra).
Có thể tùy chỉnh các tên nhóm này, nhưng bạn nên chấp nhận các tên mặc định nếu có thể. Nếu
có một xung đột với các tên nhóm hiện có, bạn sẽ được nhắc thay đổi các tên nhóm. Nếu bạn
không chọn tùy chọn này trong lúc cài đặt DB2 UDB ban đầu, bạn luôn có thể chạy nó sau này
bằng cách chạy chương trình db2secv82.exe. Có thể tìm thấy chương trình này trong thư mục
DB2PATH\SQLLIB\BIN\ , ở đây DB2PATH là nơi đã cài đặt DB2 UDB. Bạn nên chạy tùy
chọn này để bảo vệ máy chủ của bạn ở mức cao nhất.
Hình 6 cho thấy kết quả của việc đã chạy tính năng an toàn bổ sung này. Bây giờ tất cả các thư
mục DB2 UDB trên hệ thống tệp của máy chủ đòi hỏi những người dùng là thành viên của một
trong hai nhóm này có quyền truy cập các thư mục và các tệp DB2 UDB.

Hình 6. Các quyền hạn của thư mục khi chạy tính năng an toàn mới của Windows

Một khi bạn chạy tính năng an toàn bổ sung bằng cách sử dụng lệnh db2secv82.exe, bạn có hai
lựa chọn thoát khỏi nó:
 Chạy lại lệnh db2secv82.exe ngay lập tức MÀ KHÔNG thực hiện bất kỳ các thay đổi
bổ sung nào vào hệ thống. Nếu đã thực hiện bất kỳ các thay đổi nào với hệ thống, bạn
phải sử dụng tùy chọn tiếp theo.
 Thêm nhóm EVERYONE vào các nhóm DB2ADMNS và DB2USERS.
Khi chạy tính năng an toàn mở rộng, biến đăng ký DB2_EXTSECURITY của DB2 UDB được thiết
lập là YES. Việc này ra lệnh cho DB2 UDB kiểm tra tính năng an toàn bổ sung cần thiết từ phần
của nó. Nếu bạn thay đổi giá trị DB2_EXTSECURITY là NO sau khi tạo các nhóm DB2ADMNS và
DB2USERS các quyền hạn với các tệp và các thư mục sẽ vẫn được các nhóm này sở hữu; tuy
nhiên, DB2 UDB sẽ không thực hiện kiểm tra tính năng an toàn bổ sung.
Về đầu trang
Các tài khoản người dùng và nhóm cần thiết trên các hệ điều hành Linux và UNIX

Xem xét NIS/NIS+
Nếu sử dụng phần mềm NIS/NIS+ hoặc phần mềm an toàn tương tự trong môi trường của bạn,
bạn phải tạo các tài khoản người dùng và nhóm cần thiết của DB2 UDB bằng cách thủ công
trước khi bạn cài đặt DB2 UDB. Hãy tham khảo chủ đề NIS trong tài liệu DB2 UDB (xem phần
Tài nguyên) trước khi bạn bắt đầu.
Trong các hệ điều hành Linux và UNIX, một số tài khoản người dùng và nhóm thường cần dùng
để cài đặt và hoạt động DB2 UDB:
 Tài khoản người dùng cài đặt
 Tài khoản người dùng DAS (Máy chủ quản trị của DB2)
 Tài khoản người dùng chủ sở hữu cá thể DB2 UDB
 Tài khoản người dùng thường trình có rào chắn DB2 UDB
Theo mặc định, Trình hướng dẫn cài đặt DB2 tạo ra các tài khoản người dùng và nhóm này tự
động trong lúc cài đặt máy chủ DB2 UDB. Ngoài ra, bạn có thể chỉ định một tài khoản người
dùng hiện có trong lúc cài đặt.
Tài khoản người dùng cài đặt
Bạn phải cài đặt DB2 UDB bằng cách sử dụng tài khoản "root" (chủ). Đây là tài khoản người
dùng duy nhất có đủ các đặc quyền để thực hiện cài đặt.
Tài khoản người dùng của chủ sở hữu cá thể
Một cá thể DB2 UDB được tạo ra trong thư mục chủ của chủ sở hữu cá thể. Tài khoản người
dùng này kiểm soát tất cả các quy trình DB2 UDB và sở hữu tất cả các hệ thống tệp và các thiết
bị do các cơ sở dữ liệu chứa trong cá thể đó sử dụng. ID người dùng mặc định được sử dụng cho
chủ sở hữu cá thể DB2 UDB trong một bản cài đặt DB2 UDB là db2inst1, và nhóm mặc định là
db2iadm1. Nếu tên người dùng đã tồn tại, Trình hướng dẫn cài đặt DB2 gắn thêm một số từ 1
đến 99 vào tên người dùng mặc định, cho đến khi có thể tạo ra một ID người dùng chưa có. Ví
dụ, nếu những người dùng db2inst1 và db2inst2 đã có trong cài đặt DB2 UDB mới, trình hướng
dẫn tạo người dùng db2inst3. Nếu người dùng này đã tồn tại, trình hướng dẫn tiếp tục việc tìm
kiếm của mình (db2inst4, db2inst5 và v.v ) cho đến khi nó tìm được một người dùng có thể
dùng được. Thuật toán đặt tên này cũng được áp dụng cho việc tạo ra tài khoản người dùng có
rào chắn và tài khoản người dùng của trình ứng dụng quản trị DB2.
Một cách thực hành tốt là hạn chế tài khoản người dùng của chủ sở hữu cá thể là thành viên của

nhóm chủ sở hữu cá thể duy nhất, và không sử dụng nó trong bất kỳ nhóm khác nào. Điều này
giúp kiểm soát số lượng tài khoản người dùng và các nhóm, có thể thay đổi cá thể, hoặc bất kỳ
đối tượng nào trong cá thể đó.
Trong một bản cài đặt Linux hoặc UNIX mặc định, bạn có tùy chọn tạo một cá thể như là một
phần của quy trình cài đặt. Bạn cũng có thể tạo các cá thể khác hoặc loại bỏ các cá thể hiện có
sau này, bằng cách sử dụng các tiện ích tương ứng là db2icrt và db2idrop. Có thể tìm thấy các
tiện ích này trong thư mục DB2PATH/instance, ở đây DB2PATH biểu thị /usr/opt/db2_08_01
trên AIX, và /opt/IBM/db2/V8.1 trên tất cả các hệ thống dựa trên UNIX và Linux khác. Để chạy
các tiện ích này, bạn phải sử dụng tài khoản người dùng gốc. Khi tạo một cá thể mới trong Linux
và UNIX bằng tiện ích db2icrt, bạn phải chỉ định tài khoản người dùng có rào chắn liên quan
đến cá thể đó. Tên cá thể bạn chọn phải ánh xạ tới tên tài khoản người dùng là chủ sở hữu cá thể.
Ví dụ, nếu một tài khoản người dùng hiện có là prodinst là chủ sở hữu của cá thể mới, bạn sẽ chỉ
định prodinst làm tên cá thể trong lệnh db2icrt. Cá thể sẽ được tạo ra trong thư mục chủ của
người dùng sở hữu cá thể. Ví dụ, lệnh sau đây tạo ra một cá thể mới tên là devinst, do tài khoản
người dùng devinst sở hữu, và sử dụng tài khoản người dùng hiện có tên là devfenc cho tài khoản
người dùng có rào chắn:

Liệt kê 6. Tạo một cá thể DB2 UDB mới trong Linux và UNIX
db2icrt -u devfenc devinst

DB2 UDB không hỗ trợ tài khoản root hoạt động trực tiếp là một quản trị viên cơ sở dữ liệu. Bạn
nên sử dụng lệnh su - <instance owner> để chuyển sang tài khoản (chủ sở hữu cá thể) của
quản trị viên cơ sở dữ liệu.
Tài khoản người dùng DAS
Sử dụng tài khoản người dùng cho DAS (Trình ứng dụng chủ quản trị DB2) để chạy quy trình
DAS trên hệ thống. ID người dùng mặc định được tạo trong quá trình cài đặt mặc định là
dasusr1 và ID nhóm mặc định là dasadm1. Tài khoản DAS cũng được các công cụ GUI của DB2
UDB sử dụng để thực hiện các nhiệm vụ quản trị đối với các cá thể và các cơ sở dữ liệu của máy
chủ cục bộ. Chỉ cần một DAS cho mỗi máy. Nó có thể quản lý tất cả các cá thể được định nghĩa
trên máy chủ. Tài khoản người dùng DAS phải khác với tài khoản người dùng của chủ sở hữu cá

thể.
Một khi khởi động quá trình DAS bằng tài khoản này, cũng phải dừng nó bằng tài khoản này. Vì
vậy, trong Linux và UNIX, bạn phải sử dụng lệnh su - <DAS user> để chuyển sang tài khoản
người dùng DAS để khởi động và dừng quá trình DAS.
Tài khoản người dùng có rào chắn
Tài khoản người dùng có rào chắn được sử dụng để chạy các hàm do người dùng định nghĩa
(UDF) và các thủ tục đã lưu bên ngoài vùng địa chỉ (bộ nhớ) do máy DB2 UDB sử dụng. Đôi
khi, nếu một thủ tục hoặc hàm không ổn định hoặc đang được thử nghiệm, nó sẽ được định nghĩa
là FENCED (có rào chắn) sao cho có thể chạy nó trong vùng địa chỉ của quá trình của nó. Theo
cách này, nếu chức năng hoặc thủ tục bị sự cố hoặc chấm dứt bất thường, nó sẽ không ảnh hưởng
đến bất kỳ các quá trình cá thể nào khác. Tài khoản người dùng mặc định được tạo cho người
dùng có rào chắn là db2fenc1 và nhóm mặc định là db2fadm1. Vì các lý do an toàn, chúng tôi
khuyên bạn không sử dụng tài khoản chủ sở hữu cá thể cho tài khoản người dùng có rào chắn.
Nếu bạn không cần mức an toàn này ví dụ, nếu bạn đang chạy trong một môi trường thử
nghiệm, hoặc bạn không có kế hoạch sử dụng các UDF có rào chắn hoặc các thủ tục đã lưu
bạn có thể sử dụng tài khoản chủ sở hữu cá thể thay vì tạo ra một tài khoản người dùng . Khi tạo
ra các cá thể mới, các tài khoản người dùng có rào chắn phải được xác định như là một phần của
lệnh tạo cá thể (db2icrt -u <Fenced_ID>).
Thiết lập môi trường DB2 UDB cho những người dùng Linux và UNIX
Kiểm tra vị trí đường dẫn DB2 UDB
Sử dụng lệnh which db2 để đảm bảo rằng đường dẫn tìm kiếm của bạn đã được thiết lập đúng.
Điều này đặc biệt quan trọng khi bạn có nhiều cá thể đang chạy trên cùng một máy chủ. Lệnh
này sẽ trả về đường dẫn tuyệt đối có thể thực hiện được của bộ xử lý dòng lệnh (CLP). Kiểm tra
xem nó có được đặt trong thư mục sqllib của cá thể đúng không.
Các môi trường Linux và UNIX bắt tuân thủ an toàn chắc chắn ở mức người dùng; các tệp và các
quá trình liên kết với một tài khoản người dùng không thể truy cập trực tiếp bởi người dùng
khác. Theo mặc định, khi tạo một cá thể DB2 UDB mới, một kịch bản lệnh của môi trường DB2
UDB đặc biệt được gọi là db2profile cũng được thêm vào hồ sơ hệ thống của chủ sở hữu cá thể,
để cho kịch bản lệnh này được chỉ rõ nguồn gốc mỗi khi chủ sở hữu cá thể đăng nhập vào hệ
thống. Các kịch bản lệnh này thiết lập quyền truy cập vào môi trường cơ sở dữ liệu và cho phép

chủ sở hữu cá thể thực hiện các lệnh DB2 UDB. Để những người dùng khác trên hệ thống có
quyền truy cập đến cá thể đó và môi trường DB2 UDB, chúng cũng phải chạy các kịch bản lệnh
tương tự. Một cách để làm điều này là "chỉ rõ nguồn gốc" cho tệp .profile của chủ sở hữu cá thể
DB2 UDB (hoặc tệp .profile đó tham khảo tệp db2profile). Nếu bạn đang sử dụng trình bao
(shell) Bourne hoặc Korn, bạn có thể chỉnh sửa tệp .profile của một tài khoản người dùng đích
sao cho kịch bản lệnh db2profile chạy tự động khi người dùng đăng nhập vào hệ thống. Đối với
người dùng trình bao C, bạn có thể chỉnh sửa tệp .login sao cho nó chạy tệp kịch bản db2shrc. Để
chọn cá thể bạn muốn sử dụng, thêm một trong các câu sau đây vào tệp kịch bản lệnh .profile
hoặc .login, hoặc ban hành các câu lệnh từ một cửa sổ đầu cuối ở đó người dùng cần truy cập
DB2 UDB từ (lưu ý cần có period (.) và khoảng trống):
 với trình bao Bourne hoặc Korn:
. INSTHOME/sqllib/db2profile
 với trình bao C:
source INSTHOME/sqllib/db2cshrc
ở đây INSTHOME là thư mục chủ của cá thể bạn muốn sử dụng.
Đối với những người dùng có một phiên bản kịch bản lệnh tùy chỉnh trong thư mục chủ của họ:
 với trình bao Bourne hoặc Korn:
. USERHOME/db2profile
 với trình bao C:
source USERHOME/db2cshrc
ở đây USERHOME là thư mục chủ của người dùng.
Nếu bạn muốn làm việc với nhiều hơn một cá thể cùng lúc, hãy chạy kịch bản lệnh cho từng cá
thể mà bạn muốn sử dụng trong các cửa sổ thiết bị đầu cuối riêng biệt.
Về đầu trang
Tài khoản người dùng của trình lịch biểu
Tài khoản người dùng của trình lịch biểu là cần thiết khi chạy các phương tiện tạo lịch của DB2
UDB. Tài khoản này được trình lịch biểu DB2 UDB sử dụng để kết nối với cơ sở dữ liệu danh
mục của các công cụ khi nó lưu trú trên một máy chủ ở xa. Cơ sở dữ liệu danh mục của các công
cụ chứa tất cả các siêu dữ liệu về các nhiệm vụ được tạo lịch để chạy trên máy chủ DB2 UDB (ví
dụ, một nhiệm vụ sao lưu được tạo lịch để chạy mỗi Chủ nhật một lần lúc 1:00 am). Các phương

tiện tạo lịch biểu được thiết kế để cho cơ sở dữ liệu danh mục của các công cụ không cần phải
lưu trú trên cùng một cùng máy chủ DB2 UDB mà ở đó các nhiệm vụ được tạo lịch để chạy.
Trong trường hợp này, trình lịch biểu trên máy chủ DB2 UDB cần kết nối với cơ sở dữ liệu danh
mục của các công cụ để lấy ra bất kỳ thông tin cần thiết nào về các nhiệm vụ được chạy.
Tài khoản trình lịch biểu được các tham số cấu hình SCHED_USERID điều khiển. Tham số này chỉ
thích hợp nếu cơ sở dữ liệu danh mục các công cụ không nằm trên cùng một máy tính như máy
chủ quản trị DB2. Bạn có thể xem giá trị của tham số này bằng cách ban hành lệnh db2 get
admin cfg.
Để thay đổi giá trị của tham số này, bạn có thể dùng lệnh db2admin setschedid <user_ID>
<password> ở đây <user_ID> và <password> là ID và mật khẩu người dùng mà bạn cần trình
lịch biểu sử dụng để kết nối với cơ sở dữ liệu danh mục của các công cụ từ xa.
Liệt kê 7 cho thấy các kết quả sau khi thiết lập ID của trình lịch biểu với một giá trị là xtradba.

Liệt kê 7. Một danh sách của các tham số DAS và giá trị của chúng có thể cấu hình được
C:\>db2 get admin cfg

Admin Server Configuration

Authentication Type DAS
(AUTHENTICATION) = SERVER_ENCRYPT

DAS Administration Authority Group Name
(DASADM_GROUP) =

DAS Discovery Mode
(DISCOVER) = DISABLE
Name of the DB2 Server System
(DB2SYSTEM) = TEDWAS

Java Development Kit Installation Path DAS

(JDK_PATH) =
C:\Program
Files\IBM\SQLLIB\java\jdk\
Java Development Kit Installation Path DAS
(JDK_64_PATH) =

DAS Code Page
(DAS_CODEPAGE) = 0
DAS Territory
(DAS_TERRITORY) = 0

Location of Contact List
(CONTACT_HOST) =
Execute Expired Tasks
(EXEC_EXP_TASK) = NO
Scheduler Mode
(SCHED_ENABLE) = ON
SMTP Server
(SMTP_SERVER) =
Tools Catalog Database
(TOOLSCAT_DB) = TOOLSDB
Tools Catalog Database Instance
(TOOLSCAT_INST) = DB2
Tools Catalog Database Schema
(TOOLSCAT_SCHEMA) = TOOLSDB
Scheduler User ID = xtradba

Kết luận
Bài này đã xem xét các tương tác chính của DB2 UDB với các tài khoản người dùng và nhóm.
Nó đã tóm tắt cách DB2 UDB thực hiện xác thực người dùng và ủy quyền người dùng/nhóm,

cũng như cách định nghĩa siêu người dùng cho một cá thể DB2 UDB. Bạn đã tìm hiểu về các tài
khoản người dùng và nhóm mặc định được yêu cầu và/hoặc tạo một bản cài đặt DB2 UDB và
cách cấu hình chúng. Với hiểu biết tốt hơn về cách các tài khoản người dùng và nhóm tương tác
với DB2 UDB, bạn có thể lập kế hoạch và thực hiện cấu hình tài khoản người dùng và nhóm tối
ưu cho môi trường của bạn.