Cơ sở dữ liệu

Thiết kế, xây dựng các ứng dụng và CSDL cho doanh nghiệp

GIẢI PHÁP XÂY DỰNG HỆ THỐNG CƠ SỞ DỮ LIỆU

Cùng với sự phát triển mạnh mẽ của CNTT, hệ thống Cơ sở Dữ liệu (CSDL) ngày càng trở thành tài sản quan trọng đối với mọi doanh nghiệp. CSDL ngày nay được xem là thành phần cơ bản nhất trong mọi hệ thống ứng dụng, từ các ứng dụng lõi phục vụ sản xuất, kinh doanh cho đến các ứng dụng trao đổi thông tin, hỗ trợ người dùng, marketing, dịch vụ khách hàng…. Do vậy, yêu cầu trang bị hệ thống CSDL phù hợp, đáp ứng được các yêu cầu phát triển đang là một thách thức lớn đối với các doanh nghiệp hiện nay. Hệ thống CSDL phải luôn sẵn sàng, có khả năng hoạt động với hiệu năng cao và đảm bảo tính toàn vẹn ngay cả khi có sự cố xảy ra. Ngoài ra hệ thống CSDL còn phải được bảo đảm an toàn trước các nguy cơ tấn công từ bên ngoài và bên trong, có khả năng hiệu chỉnh, nâng cấp, mở rộng linh hoạt…

Bộ giải pháp bao gồm:

Giải Pháp sẵn sàng cao Oracle Real Application Cluster:

Giải pháp Oracle Real Application Clusters (RAC) là giải pháp xây dựng một hệ thống database gồm nhiều máy chủ xử lý trên cùng một vùng lưu trữ và cung cấp dịch vụ database như một database đơn, hoàn toàn trong suốt cho các ứng dụng. RAC tăng cường khả năng chịu lỗi cho hệ thống trong các trường hợp lỗi về phần cứng hay tạm ngừng một máy chủ. RAC cung cấp tính sẵn sàng cao, khả năng mở rộng và tối ưu chi phí.

Các đặc điểm của giải pháp Oracle Real Application:

• Nhiều instance, mỗi Instance chạy một máy chủ Nhiều instance chia sẻ một database vật lý
• Tất cả instance có cùng database và các control le chung
• Mỗi instance có những log le và undo segment riêng
• Tất cả các instance giao tiếp với nhau thông qua kết nối nội bộ (interconnect) và sử dụng kỹ thuật Cache-Fusion.

Lợi ích:

Oracle RAC là giải pháp mang lại nhiều lợi ích cho khách hàng khi sử dụng: tận dụng tài nguyên, tiết kiệm chi phí và quan trọng nhất là đảm bảo an toàn, sẵn sàng dữ liệu trước những sự cố, thảm họa ngoài ý muốn.

• Đảm bảo tính sẵn sàng cao về mặt hệ thống máy chủ: Oracle RAC cung cấp khả năng đảm bảo an toàn cao về mặt hệ thống máy chủ. Khi một instance gặp sự cố (hay một máy chủ trong hệ thống cluster bị lỗi), khả năng failover sẽ tự động chuyển các kết nối đến các instance khác. Do đó đảm bảo thời gian ngừng hoạt động của hệ thống là thấp nhất.
• Chia sẻ và cân bằng tải của hệ thống: Oracle RAC cung cấp khả năng quản lý tải của hệ thống, phân chia tải làm việc của các máy chủ một cách hợp lý trong hệ thống cluster, đảm bảo hiệu suất hoạt động tối ưu.
• Khả năng mở rộng linh hoạt và dễ dàng: Oracle RAC cho phép mở rộng một cách dễ dàng bằng cách bổ sung máy chủ vào hệ thống cluster có sẵn. Việc này có thể thực hiện online, không cần ngừng hoạt động của hệ thống. Tương tự, việc gỡ bỏ một máy chủ cũng có thể được thực hiện online mà không làm ảnh hưởng đến hệ thống đang hoạt động.
• Tận dụng nguồn tài nguyên, tiết kiệm chi phí đầu tư: Giải pháp Oracle RAC cho phép tận dụng tài nguyên của doanh nghiệp. Khi có nhu cầu tăng công suất làm việc của hệ thống RAC, khách hàng chỉ cần trang bị thêm thiết bị, máy chủ vào môi trường RAC hiện tại mà không cần phải trang bị lại hệ thống mới.
• Quản lý tập trung và dễ dàng: Oracle RAC cung cấp những công cụ như Oracle Enterprise Manager, Oracle Grid Control, Oracle Server Control Utility (SRVCTL), giúp cho việc quản lý các máy chủ tập trung và dễ dàng hơn.

Giải pháp sẵn sàng cao Oracle Data Guard:

Giải pháp Oracle Data Guard là giải pháp xây dựng hệ thống CSDL (Database) bao gồm một Database chính và một hay nhiều Database dự phòng. Database chính, còn gọi là Primary Database có chức năng liên tục gửi những cập nhật dưới dạng dữ liệu redo đến các Database dự phòng, tức Standby Database. Việc này sẽ đảm bảo dữ liệu luôn trong tình trạng đồng bộ giữa các Database với nhau. Trong trường hợp Primary Database bị hỏng do lỗi phần cứng, lỗi dữ liệu hoặc gặp sự cố thì Standby Database sẽ đảm nhiệm vai trò của Primary Database và khi đó các ứng dụng sẽ được chuyển kết nối đến Standby Database. Lúc này Standby Database hoạt động không khác gì Primary Database cho đến khi Primary Database được phục hồi.

Lợi Ích:

Giải pháp Oracle Data Guard đảm bảo tính an toàn dữ liệu, khả năng sẵn sàng, dễ dàng cấu hình và quản trị, đồng thời tiết kiệm chi phí.

• Dự phòng thảm hoạ, bảo vệ dữ liệu và sẵn sàng cao: Khả năng switchover và failover cho phép chuyển đổi nhanh chóng vai trò giữa database chính và database dự phòng, rút ngắn thời gian ngừng hệ thống.
• Bảo vệ dữ liệu toàn diện: Database dự phòng bảo vệ dữ liệu khỏi nguy cơ hỏng hóc dữ liệu và lỗi của người sử dụng. Các hư hỏng mức vật lý của database chính sẽ không được chuyển đến database dự phòng. Đối với các hư hỏng dạng logical hay lỗi người sử dụng gây tổn hại đến database chính thì có thể sửa chữa được. Cuối cùng, dữ liệu redo luôn được xem xét, kiểm tra trước khi được cập nhật vào database dự phòng.
• Sử dụng tài nguyên hiệu quả, tiết kiệm chi phí: Các dữ liệu bảng ở database dự phòng được cập nhật với redo log nhận từ database chính có thể sử dụng cho các mục đích khác như backup, báo cáo, tổng hợp và truy vấn. Do đó sẽ giảm tải cho database chính, tiết kiệm CPU và tăng tốc truy xuất dữ liệu.
• Linh động trong bảo vệ dữ liệu, cân bằng giữa tính sẵn sàng và yêu cầu về hiệu suất: Oracle Data Guard cung cấp các chế độ Maximum Protection, Maximum Availability và Maximum Performance để doanh nghiệp có thể cân đối giữa tính sẵn sàng dữ liệu và yêu cầu về hiệu suất.
• Quản trị tập trung và đơn giản: Data Guard broker (Quản trị Data Guard) cung cấp giao diện đồ hoạ Enterprise Manager và giao diện dòng lệnh DGMGRL để tự động quản lý và thực hiện các thao tác vận hành, giám sát trên nhiều database trong cùng hệ thống Data Guard.
• Tự động phát hiện gián đoạn và xử lý: Nếu kết nối giữa database chính và database dự phòng bị mất, dữ liệu redo phát sinh trên database chính sẽ không được chuyển sang database dự phòng. Một khi kết nối được khôi phục, các dữ liệu redo chưa được chuyển sang sẽ được tự động phát hiện bởi Data Guard và sẽ được chuyển sang database dự phòng. Database dự phòng sẽ tự động đồng bộ hoá với database chính mà không cần sự can thiệp của nhân viên quản trị database.
• Tích hợp với CSDL Oracle: Tính năng Oracle Data Guard được tích hợp sẵn trong phiên bản CSDL Oracle Enterprise Edition, doanh nghiệp không phải trả thêm chi phí cho tính năng này.

Giải pháp đồng bộ dữ liệu Oracle GoldenGate:

Oracle GoldenGate là giải pháp phần mềm hiệu năng cao cho phép đồng bộ và tích hợp dữ liệu theo thời gian thực, đảm bảo tính sẵn sàng cao đối với các ứng dụng quan trọng. Oracle GoldenGate cung cấp khả năng đồng bộ và phân phối dữ liệu của các phiên giao dịch giữa các hệ thống thực thi (production) và phân tích (analysis) một cách ổn định, nhanh chóng và chính xác.  Ngoài ra, Oracle GoldenGate có khả năng thu thập, lọc, vận chuyển, kiểm tra, chuyển đổi và phân phối dữ liệu trong môi trường cơ sở dữ liệu Oracle và các cơ sở dữ liệu khác một cách toàn vẹn với hiệu suất cao.

Lợi ích:

• Truy cập theo thời gian thực đến thông tin thực: Các hệ thống ứng dụng kinh doanh quan trọng luôn cần độ sẵn sàng cao nhất, bảo đảm khả năng truy cập nhanh chóng và dễ dàng đến các nguồn dữ liệu chính xác và nhanh chóng đáp ứng với sự thay đổi của yêu cầu kinh doanh của doanh nghiệp. Đặc biệt là khi số lượng các giao dịch cũng như số lượng các ứng dụng trực tuyến ngày càng tăng với tốc độ chóng mặt, các doanh nghiệp sẽ cần đến giải pháp tối ưu để thu thập và phân phối một cách hiệu quả khối lượng dữ liệu khổng lồ của mình. Giải pháp Oracle GoldenGate cung cấp các tính năng thu thập, chuyển đổi, vận chuyển và phân phối các giao dịch của database trên toàn bộ hệ thống. Goden- Gate di chuyển database với hiệu suất cao theo thời gian thực, giúp các ứng dụng quan trọng của doanh nghiệp như internet banking, mua bán trực tuyến, đặt vé qua mạng… được ổn định trong khi không làm ảnh hưởng đáng kể đến tải hệ thống.
• Đảm bảo tính sẵn sàng liên tục đối với các ứng dụng quan trọng: Khi di chuyển dữ liệu, tính toàn vẹn của dữ liệu và giao dịch được GoldenGate duy trì bằng cách sử dụng các cơ chế kiểm tra nghiêm ngặt. Do đó, khi có sự cố ví dụ như đứt kết nối mạng, hư hỏng dữ liệu… xảy ra, dữ liệu và giao dịch vẫn sẽ được an toàn, giúp cho các ứng dụng quan trọng có khả năng hoạt động liên tục với hiệu suất cao.
• Tích hợp dữ liệu theo thời gian thực trên hệ thống: Oracle GoldenGate thu thập và phân phối những dữ liệu thay đổi theo thời gian thực đến các hệ thống data warehouses, các kho dữ liệu đang hoạt động, các hệ thống báo cáo và các database xử lý giao dịch trực tuyến mà không ảnh hưởng đến hiệu năng của hệ thống.

Giải pháp quản lý Oracle Enterprise Manager:

OEM (Oracle Enterprise Management) Grid Control là ứng dụng với giao diện web của Oracle, có khả năng quản lý tập trung các hệ thống CNTT của các tổ chức, doanh nghiệp. OEM Grid Control hỗ trợ người quản trị giám sát hầu hết các thành phần ở các tầng kiến trúc của hệ thống CNTT, bao gồm cả những thành phần thuộc Oracle và không thuộc Oracle như máy chủ, thiết bị lưu trữ, cơ sở dữ liệu, Middleware, Application server, các ứng dụng nghiệp vụ, các thiết bị mạng, máy ảo, các phần mềm hoặc phần cứng của các hãng thứ 3. Oracle Enterprise Manager Grid Control cho phép quản lý các thành phần tài nguyên trong hệ thống CNTT như:

• Quản trị các máy chủ database với RAC management.
• Giám sát ASM – Automatic Storage Management, các thành phần Exadata.
• Quản trị Application Server, Web Server và quản lý chất lượng dịch vụ (SLA – Service Level Management), bao gồm việc xác định loại dịch vụ, giám sát hoạt động và báo cáo chất lượng dịch vụ.
• Theo dõi tổng thể tình trạng của hệ thống và dịch vụ, dựa trên home page và dashboard, có thể truy xuất đến mức chi tiết hơn (drill-down) để phân tích nguyên nhân gây ra lỗi.
• Bổ sung cảnh báo (Alert), chính sách bảo mật và ngưỡng (threshold) cho tất cả các thành phần, đặt quy tắc gửi thông báo lỗi (noti cation).
• Sử dụng template (tập hợp những chỉ tiêu theo dõi) để quản lý theo phương pháp giống nhau cho các loại database, host,… khác nhau.
• Triển khai Database và Application server lên hệ điều hành mới bằng cách sử dụng các thư viện phần mềm đã được kiểm tra trước.
• Quản lý vòng đời sản phẩm Oracle và cập nhật bản vá lỗi cho hệ điều hành, kết nối trực tiếp vào My Oracle- Support để chủ động lấy các bản thông báo, phân phối bản vá lỗi.
• Tự động hoá các tác vụ ở mức hệ điều hành và database bằng cách sử dụng hệ thống đặt lịch công việc.
• Quản lý cấu hình hệ thống, ghi nhận cấu hình hiện tại, so sánh đối chiếu với cấu hình đã lưu để tìm những thành phần đã thay đổi, hoặc xác định cấu hình chuẩn.
• Dễ dàng tạo ra các báo cáo out-of-box (không phải lập trình) để cung cấp cho người dùng, quản lý và lãnh đạo bằng những công cụ tạo báo cáo dạng đồ hoạ, có tính năng bảo mật khi phân phối báo cáo.
• Lợi ích:
• Quản lý tập trung: Giải pháp OEM Grid Control cho phép doanh nghiệp giám sát và quản trị tất cả các thành phần CNTT bao gồm Database, máy chủ, hệ thống lưu trữ, thiết bị mạng,… từ giao diện đồ họa tập trung. Việc quản lý các thành phần với giao diện đồ họa giúp cho người quản trị dễ dàng trong công tác theo dõi và vận hành hệ thống.
• Hệ thống đa quản trị: OEM Grid Control hỗ trợ quản lý đa nhiệm, cho phép phân tách vai trò giữa những người quản trị trên hệ thống nhưng vẫn đảm bảo thông tin được chia sẻ và bảo mật.
• Tự động hóa: OEM Grid Control với công cụ cho phép lập lịch tự động hóa các tác vụ sao lưu, chạy báo cáo định kỳ. Bên cạnh đó, công cụ cho phép người quản trị giám sát hoạt động hệ thống từ xa, khi có sự cố xảy ra trên hệ thống, người quản trị có thể thiết lập các tác vụ cho phép tự động xử lý kịp thời.
• Khả năng mở rộng: OEM Grid Control được phát triển với kiến trúc 3 lớp, do đó đảm bảo hiệu suất hoạt động của hệ thống. Khi có tình trạng quá tải trên OMS, doanh nghiệp có thể dễ dàng thêm OMS vào lớp giữa để chia sẻ và cân bằng tải.
• Kiến trúc mở: OEM Grid Control sử dụng các chuẩn mở, cho phép lập trình và tích hợp các công cụ quản lý thứ 3 vào giao diện quản lý đồ họa. Giúp cho việc quản lý các thành phần trên hệ thống trở nên đơn giản và linh hoạt hơn.
• Chức năng quản trị Database: OEM Grid Control bao gồm các tính năng quản trị Database, nhằm đơn giản hóa thao tác hằng ngày cho người quản trị và công tác quản trị từ xa.

Giải pháp nâng cao tính sẵn sàng cho cơ sở dữ liệu Oracle

Giới thiệu Oracle Data Guard

Oracle Data Guard đảm bảo tính sẵn sàng cao, bảo vệ dữ liệu, và khôi phục sau sự cố. Data Guard cung cấp tất cả các dịch vụ khởi tạo, duy trì, quản lý và giám sát một hay nhiều standby database để Oracle database tiếp tục tồn tại sau sự cố, hư hỏng dữ liệu. Data Guard duy trì các standby database như là các bản sao của primary database. Nếu primary database không sẵn sàng hoạt động, Data Guard có thể chuyển bất kỳ standby database thành primary database, giảm thiểu thời gian ngưng hoạt động. Data Guard có thể sử dụng với sao lưu, khôi phục, và kỹ thuật cluster để tạo ra mức độ cao về bảo vệ dữ liệu và sẵn sàng dữ liệu.

Với Data Guard, có thể cải thiện hiệu năng của primary database bằng cách sao lưu và chạy các báo cáo trên hệ thống standby.

Cấu hình Data Guard

Một cấu hình Data Guard bao gồm một primary database và một hay nhiều standby database. Các database trong một cấu hình Data Guard được kết nối bởi Oracle Net và có thể phân tán về mặt địa lý. Không có giới hạn về vị trí đặt database, chỉ đảm bảo các database phải liên lạc được với nhau. Ví dụ, có thể đặt một standby database trên cùng hệ thống với primary database, cùng với hai standby database trên một hệ thống khác tại một vị trí khác.

Có thể quản lý primary và các standby database bằng cách sử dụng giao diện dòng lệnh SQL hoặc giao diện Data Guard broker, bao gồm một giao diện dòng lệnh và một giao diện đồ họa người dùng được tích hợp trong Oracle Enterprise Manager.
Primary Database

Một cấu hình Data Guard bao gồm một primary database, có chức năng là vai trò chính. Đây là database mà hầu hết ứng dụng truy cập.

Primary database có thể là một single-instance Oracle database hay một Oracle Real Application Clusters (RAC) database.

Standby Databases

Một standby database là một bản copy của primary database. Sử dụng một bản copy backup của primary database, có thể tạo ra standby database và kết hợp standby database này vào trong một cấu hình Data Guard. Khi được tạo ra, Data Guard tự động duy trì mỗi standby database bằng cách truyền redo data từ primary database và apply redo data đến standby database.

Tương tự primary database, một standby database có thể là một single-instance Oracle database hay một Oracle RAC database.

Standby database có các loại sau:

Physical standby database

Cung cấp một bản copy vật lý đồng nhất của primary database, với cấu trúc database giống y primary database. Database schema, bao gồm cả index, là giống nhau. Một physical standby database duy trì đồng bộ với primary database thông qua Redo Apply: thực hiện recover redo data nhận từ primary database và apply redo đến physical standby database.

Với Oracle Database 11g release 1 (11.1), một physical standby database có thể nhận và apply redo trong khi open cho truy cập read-only. Vì thế một physical standby database có thể sử dụng đồng thời để bảo vệ dữ liệu và chạy báo cáo.
Logical standby database

Bao gồm thông tin logic giống như primary database, mặc dù cấu trúc và tổ chức vật lý của dữ liệu có thể khác. Logical standby database duy trì đồng bộ với primary database thông qua SQL Apply: chuyển đổi data trong redo nhận từ primary database thành các lệnh SQL và thực hiện các lệnh SQL này trên standby database.

Một logical standby database có thể sử dụng cho các mục đích nghiệp vụ khác, ngoài các yêu cầu khôi phục từ sự cố. Điều này cho phép người dùng truy cập đến logical standby database để truy vấn, chạy báo cáo bất kỳ lúc nào. Ngoài ra, dùng một logical standby database có thể upgrade Oracle Database software và các bản sửa lỗi mà gần như không phải ngừng hoạt động. Vì vậy, một logical standby database có thể sử dụng đồng thời để bảo vệ dữ liệu, chạy báo cáo, và upgrade database.

Snapshot Standby Database

Một snapshot standby database là một standby database có thể update đầy đủ.

Giống như một physical hay logical standby database, một snapshot standby database nhận và lưu trữ redo data từ một primary database. Không giống một physical hay logical standby database, một snapshot standby database không apply redo data nhận được. Redo data đã nhận bởi một snapshot standby database không apply cho tới khi snapshot standby chuyển đổi trở lại thành một physical standby database, sau khi loại bỏ các local update đã thực hiện với snapshot standby database.

Một snapshot standby database được sử dụng tốt nhất trong trường hợp yêu cầu một cái tạm thời, updatable snapshot của một physical standby database. Bởi vì redo data đã nhận bởi snapshot standby database không apply cho tới khi snapshot standby chuyển đổi trở lại thành một physical standby, nên thời gian cần thiết để recover một primary database bị sự cố thì tỷ lệ hoàn toàn với số lượng redo data cần thiết phải apply.

Các service của Data Guard

Redo Transport Services

Redo transport services điều khiển việc tự động truyền redo data từ primary database đến một hay nhiều đích lưu trữ.

Redo transport services thực hiện các công việc:

• Truyền redo data từ primary system đến standby systems theo cấu hình
• Quản lý tiến trình giải quyết sự ngắt quãng các archived redo log file vì sự cố về mạng.
• Tự động phát hiện các archived redo log file bị thiếu hay hư hỏng trên hệ thống standby, và tự động lấy lại các archived redo log file thay thế từ primary database hoặc từ standby database khác.

Apply Services

Redo data truyền từ primary database được ghi vào standby redo log trên standby database. Apply services tự động apply redo data trên standby database để duy trì sự đồng nhất với primary database. Apply services cũng cho phép truy cập dữ liệu read-only.

Sự khác nhau giữa physical và logical standby databases là cách mà apply services apply archived redo data:

• Với physical standby databases, Data Guard dùng công nghệ Redo Apply: apply redo data trên standby database sử dụng kỹ thuật standard recovery của một Oracle database.
• Với logical standby databases, Data Guard sử dụng công nghệ SQL Apply: chuyển đổi redo data đã nhận thành các lệnh SQL và thực hiện các lệnh SQL trên logical standby database.

Sự chuyển đổi vai trò

Một Oracle database hoạt động theo một trong hai vai trò: primary hoặc standby. Sử dụng Data Guard, có thể thay đổi vai trò của một database bằng hoạt động switchover hoặc failover.

Switchover là đảo ngược vai trò giữa primary database và một trong các standby database của nó. Switchover đảm bảo không mất dữ liệu. Hoạt động này thường được thực hiện cho việc bảo dưỡng theo kế hoạch của primary system. Trong qúa trình switchover, primary database chuyển vai trò thành standby, và standby database chuyển vai trò thành primary.

Failover khi primary database không sẵn sàng hoạt động. Failover chỉ thực hiện trong trường hợp primary database failure, và kết quả của failover là sự chuyển đổi một standby database thành vai trò primary. Quản trị database có thể cấu hình Data Guard để đảm bảo không mất dữ liệu.
Data Guard Broker

Data Guard broker là một framework quản lý phân tán, tự động hóa việc tạo ra, duy trì, và theo dõi cấu hình Data Guard. Có thể sử dụng Oracle Enterprise Manager GUI hay giao diện dòng lệnh Data Guard (DGMGRL) để:

• Tạo cấu hình Data Guard, bao gồm cả thiết lập redo transport services và apply services
• Quản lý toàn bộ cấu hình Data Guard từ bất kỳ hệ thống nào trong cấu hình
• Quản lý và theo dõi cấu hình Data Guard, bao gồm cả Oracle RAC primary hoặc standby databases
• Đơn giản hóa hoạt động switchovers và failovers chỉ bằng một click key trong Oracle Enterprise Manager hay một lệnh trong DGMGRL.
• Cho phép fast-start failover đối với hư hỏng một cách tự động khi primary database trở nên không sẵn sàng hoạt động. Khi fast-start failover là enabled, Data Guard broker xác định nếu một hư hỏng là tất yếu thì bắt đầu failover đối với target standby database đã chỉ rõ một cách tự động, không cần đến sự can thiệp của DBA.
Các đặc điểm của Data Guard

• Phần cứng ở server chính và server dự phòng có thể khác nhau.
• Hệ điều hành cài đặt ở các server phải như nhau
• Các phiên bản Release của hệ điều hành cài trên các server có thể khác nhau
• Các server phải cài đặt cùng bản Release của Oracle Database Enterprise Edition
• Database phải hoạt động ở Archive log mode
• Khôi phục, bảo vệ dữ liệu, và tính sẵn sàng cao.
• Sử dụng hiệu quả tài nguyên hệ thống
• Tinh hoạt trong bảo vệ dữ liệu, cân bằng tính sẵn sàng với các yêu cầu về hiệu năng
• Quản lý tập trung và đơn giản
• Tích hợp với Oracle Database
• Tự động chuyển đổi vai trò

Hướng dẫn cài đặt và cấu hình SQL Server để kết nối từ xa qua Internet

Hệ quản trị cơ sở dữ liệu Microsoft SQL Server của Microsoft được đánh giá là một trong những hệ quản trị cơ sở dữ liệu tốt và mạnh nhất hiện nay. Nếu bạn là một nhà phát triển ứng dụng cũng như phát triển website trên môi trường Windows thì không thể không biết đến SQL Server.
Khi phát triển các ứng dụng dạng Desktop thì chúng ta thường không quan tâm và thậm chí có thể không cần biết đến tính năng hỗ trợ kết nối từ xa của SQL Server. Nhưng khi bạn phát triển các ứng dụng Web, hoặc các ứng dụng desktop đòi hỏi dữ liệu tập trung tức thì để phục vụ cho việc ra báo cáo mà chương trình thì lại cách xa nhau về mặt địa lý, thì bạn sẽ cần đến tính năng kết nối từ xa của SQL Server. Tính năng này có trên tất cả các phiên bản SQL Server.
Trong bài viết này, tôi thực hiện hướng dẫn cài đặt và cấu hình trên phiên bản SQL Server 2005, các phiên bản khác việc thực hiện tương tự.
Sau khi hoàn thành bài hướng dẫn này:

• Bạn có thể cài đặt SQL Server
• Bạn có kết nối vào SQL Server cài trên máy tính của bạn từ bất kỳ máy tính nào có nối mạng Internet từ bất cứ đâu.

Các bước thực hiện

1. Cài đặt SQL Server
2. Cấu hình SQL Server để mở kết nối từ xa.
3. Tạo user kết nối
4. Cấu hình Firewall trên Server cho phép nhận kết nối đến qua cổng kết nối của SQL Server
5. Cấu hình Router cho phép kết nối đến thông qua cổng của kết nối SQL Server

·Bước 1: Cài đặt SQL Server
* Xem hướng dẫn cài đặt SQL Server 2005 tại link này: http://bis.net.vn/forums/t/47.aspx
·Bước 2: Config SQL Server cho phép kết nối từ xa
Mục đích là kích hoạt tính năng cho phép kết nối từ xa của SQL Server và thiết lập cổng nghe (Listenning Port) cho SQL Server.

Vào Start -> All Programs -> Microsoft SQL Server 2005 -> Configuration Tools -> SQL Server Configuration Manager
Ở menu bên trái, chọn vào mục SQL Server 2005 Services -> Bên phải tìm mục SQL Server (MSSQLSERVER) (chú ý đây là dịch vụ cơ bản của SQL Server, tên của nó tùy thuộc vào Instant của SQL mà bạn cài vào máy, của tôi là MSSQLSERVER, có thể Instant của bạn sẽ khác). Click phải vào và chọn Properties (xem hình)

Trong Tab Log On, click chọn vào Built-In Account, chọn vào Network Service như trong hình, Click OK

Quay lại màn hình SQL Server Configuration Manager -> ở menu bên trái tiếp tục click vào mục SQL Server 2005 Network Configuration để mở ra menu con Protocols for MSSQLSERRVER(tên trên máy bạn có thể khác), chọn vào mục này -> bên phải tìm mục có tên là TCP/IP, click phải vào nó và chọn Properties (xem hình)

Trong cửa sổ mở ra, ở Tab Protocols, mục Enabled chọn vào Yes

Tiếp tục click qua Tab IP Address -> Sẽ xuất hiện list các IP (IP1, IP2,…) đây là danh sách các IP hình thành khi máy bạn có kết nối vào các mạng LAN khác nhau

Hãy chọn một IP nào đó bất kỳ (ví dụ tôi chọn IP1)
·Ở mục IP Address bạn xóa đi và gõ lại địa chỉ IP của máy bạn trong mạng LAN (chú ý đây là địa chỉ IP của máy bạn trong mạng LAN – ví dụ của tôi là 192.168.1.2)
·Ở mục Active – chọn Yes, mục Enabled – chọn Yes
·Ở mục TCP Port, khai báo cổng share mặc định của SQL, bạn có thể để mặc định là 1433
·Click OK
Restart lại SQL Server. (bằng cách chọn vào mục SQL Server 2005 Services, bên phải click phải vào mục SQL Server (MSSQLSERVER) -> Chọn Restart)

·Bước 3: Tạo một user để thực hiện kết nối từ xa
Mở Start -> All Programs -> Microsoft SQL Server 2005 -> SQL Server Management Studio -> Connect vào Server
Ở menu bên trái, mở mục Security -> Login -> Nhấn chuột phải và chọn New Login

Gõ vào Tên User, Password như trong hình, bỏ dấu ở mục Enforce password Expiration -> Nhấn OK

·Bước 4: Cấu hình Firewall cho phép nhận kết nối đến qua cổng share của SQL Server
Mục đích của việc này là để mở cổng Firewall của Windows cho phép nhận kết nối từ bên ngoài qua cổng share của SQL, mặc định là cổng 1433
* Trên WindowsXP
·Vào Control Panel -> Windows Firewall
·Trong Tab Exceptions, click vào nút Add Port để thêm cổng 1433
·Hộp thoại Add Port hiện ra, trong mục Name gõ tên bất kỳ, Port Number gõ số 1433, click chọn vào mục TCP (xem hình dưới)
·Nhấn OK
·Log Off hoặc Restart lại máy

* Trên Windows Vista, Windows 7:
Vào Start -> Control Panel -> Windows Firewall -> Ở menu bên trái chọn Advanced settings
Menu bên trái, click vào mục Inbound Rules
Tiếp tục ở Menu bên phải, click vào mục New Rule
Trong cửa sổ mới hiện ra, đánh dấu vào mục Port như hình -> Nhấn Next

Tiếp theo nhấn chọn vào mục TCP và Specific local Ports, gõ vào 1433 (số cổng share của SQL Server đã config trong bước 2) -> Nhấn Next

Trên màn hình tiếp theo, đánh dấu chọn vào mục Allow the connection -> Nhấn Next

Trong màn hình tiếp theo, chọn kiểu mạng sẽ áp dụng mở cổng này, đánh dấu vào cả 3 mục Domain, Private, Public -> Nhấn Next

Trong màn hình tiếp theo, gõ tên kết nối và Description tùy ý -> Nhấn Finish

Log Off hoặc Restart lại máy
·Bước 5: Cấu hình Router cho phép kết nối qua Port 1433
Mục đích của việc này:
·Mở cổng của Router trên mạng của bạn để cho phép nhận kết nối từ bên ngoài mạng (từ Internet) qua cổng kết nối của SQL Server (Port 1433).
·Chuyển hướng (Forward) kết nối về đến đúng máy mà bạn làm Server khi Router nhận được yêu cầu qua cổng 1433
Tùy loại Router mà bạn đang sử dụng, việc cấu hình có thể khác nhau đôi chút. Ở đây tôi đang thực hiện config trên một loại Router của Dlink. Các loại Router khác bạn có thể tự tìm hiểu thêm. Cách thiết lập trên các loại Router cơ bản là giống nhau, chỉ khác nhau về cách bố trí trên menu thôi.
Đầu tiên mở IE ra và gõ địa chỉ của Gateway -> Enter và đăng nhập vào quản trị Router
Ví dụ: Gateway của tôi là 192.168.1.1 thì tôi gõ vào Address của IE là http://192.168.1.1 -> Enter
Hãy đọc hướng dẫn sử dụng kèm theo router của bạn để biết được địa chỉ gateway cũng như user và password đăng nhập vào quản trị.
Menu bên trái, chọn Advanced Setup -> NAT -> Virtual Servers

Click Add và thiết lập như trong hình -> Save

Hãy chú ý các mục mà tôi đánh dấu:
·Custom Server: Tên của thiết lập, do bạn tự đặt tùy ý
·Server IP Address: Đây là địa chỉ IP của máy mà bạn cài làm máy chủ. Ví dụ của tôi là 192.168.1.2
Chú ý: Đây chính là IP của máy mà yêu cầu sẽ được Router chuyển đến. Do đó bạn nên khai báo IP tĩnh cho máy bạn cài làm máy chủ để khỏi phải vào mục này thiết lập lại mỗi khi restart máy.
Xin nhớ rằng đây là IP của máy trong mạng LAN chứ không phải là IP đối với mạng Internet.
·Port Start, Port End là số hiệu của cổng nhận yêu cầu, đều khai báo là 1433
Ở đây sở dĩ có Port Start và Port End là vì Router cho phép bạn Forward trong cả một dải các cổng (từ cổng đến cổng). Đối với kết nối SQL Server chúng ta đang thực hiện thì chỉ cần Port 1433 thôi. Một số loại router có mục Single Port Forwarding – cho phép bạn chỉ cần config một cổng thôi là đủ.
·Mục Protocol: Chọn phương thức kết nối là TCP.

Chú ý: Thường thì phần thiết lập này nằm trong mục NAT (Network Address Translation), hoặc có thể là Port Forwarding,… tùy router.

Đến đây bạn đã hoàn thành việc cài đặt và cấu hình cho phép server nhận kết nối SQL Server từ xa qua cổng 1433.

Để test kết quả:
·Hãy ngồi ở một máy tính nào đó ngoài mạng LAN của bạn, có kết nối Internet.
·Dùng một chương trình quản lý SQL Server (có thể dùng SQL Server Management Studio), gõ vào các thông tin kết nối -> Nhấn Connect

Chú ý một số thông tin:
1.Server name: Đây là địa chỉ của Server nhận kết nối (chính là máy bạn đã cài SQL). Trong hình tôi gõ là 222.252.241.123,1433. Trong đó 222.252.241.123 chính là địa chỉ IP của máy tôi ở trên Internet, 1433 là cổng (Port) share SQL Server của tôi (tùy cổng share của bạn thiết lập, số này có thể khác, nếu bạn dùng 1433 thì có thể không cần gõ vì đây là cổng mặc định)
2.Authentication: Chọn kiểu chứng thực người dùng, có hai chế độ chứng thực là Windows Authentication và SQL Server Authentication. Tuy nhiên để kết nối từ xa thì phải dùng SQL Server Authentication
3.Login: Gõ user name mà bạn đã tạo

4.Password: Mật khẩu tương ứng

Nếu connect được thì có nghĩa là bạn đã cài đặt và thiết lập thành công.

Sử dụng index trong sql server một cách hiệu quả

Trong một câu lệnh SQL, một điều kiện tìm kiếm ở mệnh đề WHERE được gọi là sargable (viết tắt từ Search Argument-Able) nếu index có thể được sử dụng khi thực hiện câu lệnh (giả sử cột tương ứng có index). Ví dụ, với câu lệnh sau:

thì điều kiện “CustomerID = 1234″ là sargable, vì nó cho phép index trên cột CustomerID được sử dụng.
Vì index giúp tăng hiệu năng của câu lệnh lên rất nhiều, việc viết code để sao cho các điều kiện tìm kiếm trở thành sargable là một mục tiêu rất quan trọng. Một nguyên tắc rất cơ bản trong SQL Server mà bạn có thể áp dụng trong rất nhiều trường hợp, đó là cột cần tìm phải đứng một mình ở một phía của biểu thức tìm kiếm, nói cách khác là không có hàm số hay phép tính toán nào áp dụng trên cột đó. Hãy xem xét hai câu lệnh dưới đây:

Hai câu lệnh trên cho cùng một kết quả, nhưng ở câu lệnh 1 điều kiện tìm kiếm của nó là non-sargable và index trên cột CustomerID trở nên vô dụng. Kế hoạch thực thi của nó cho thấy điều này:

Câu lệnh 1 dẫn đến thao tác Clustered Index Scan, tức là quét cả cây clustered index, đồng nghĩa với quét bảng (vì clustered index chính là bảng). Do vậy mà chi phí của nó tăng vọt. Sở dĩ index đã không được sử dụng vì khi bạn áp dụng một phép tính toán trên cột, hệ thống phải thực hiện tính toán đó trên từng node trên cây index trước khi có thể lấy kết quả để so sánh với giá trị cần tìm. Vì thế nó phải duyệt tuần tự qua từng node thay vì tìm theo kiểu nhị phân (index seek, như với câu lệnh 2). Và đây là các con số thống kê về IO và thời gian thực hiện:
Câu lệnh 1 (non-sargable):

Câu lệnh 2 (sargable):

.

Trên đây là một trường hợp đơn giản mà có lẽ không mấy ai mắc phải, tuy nhiên có những tình huống khác không hiển nhiên như thế. Ví dụ, khi cần tìm tất cả các đơn hàng được thực hiện trong ngày 21/08/2009, một cách trực giác có thể bạn nghĩ ngay đến một trong các cách làm sau:

Cả hai cách viết trên đều làm mất tác dụng index trên trường OrderDate. Cách viết đúng phải là:

— lưu ý chuỗi ngày tháng mặc định của ANSI có dạng yyyymmdd

Một ví dụ khác, bạn cần tìm tất cả các khách hàng có tên bắt đầu bằng chữ C, như Can, Công, Cường… Các cách viết sau là không sargable:

Ở đây có một chi tiết thú vị, khi quan sát kế hoạch thực thi của câu lệnh ở ngay trên, bạn sẽ thấy điều kiện “Ten LIKE ‘C%’” được chuyển thành “Ten >=’C’ AND Ten< ‘D’” (vâng, chuỗi cũng so sánh lớn bé được như số), và điều kiện này hoàn toàn thích hợp với việc tìm kiếm bằng index.

Tuy nhiên, nếu bạn thay đổi yêu cầu một chút, tìm các khách hàng có tên chứa chữ ‘C’ ở bất kỳ vị trí nào, không chỉ ở đầu. Câu lệnh của bạn sẽ trở thành:

Khi đó index trên trường Ten lại bị mất tác dụng, vì hệ thống không có cách nào khác là dừng lại trên từng node, kiểm tra xem giá trị của trường Ten có chứa ký tự ‘C’ hay không. Trên thực tế đây là một thao tác rất tốn kém về tài nguyên, với các bài toàn như thế này cách làm hiệu quả hơn là dùng fulltext index và fulltext search.

Khắc phục sự cố Suspect Database trong SQL Server

I. Vấn đề đặt ra

• Trong quá trình làm việc, có một lần sau sự cố cúp điện đột ngột, tôi khởi động lại máy và phát hiện Database của mình đã chuyển sang trạng thái Suspect.
• Tôi không thể thực hiện bất kỳ câu truy vấn gì với Database này, và bản Backup gần nhất được thực hiện cách đây đã mấy ngày, trong khi tôi lại muốn làm việc với dữ liệu mới nhất. Vậy làm thế nào giải quyết sự cố Database bị Suspect.

II. Giải pháp

• Câu trả lời là chuyển Database sang trạng thái khẩn cấp (Emergency State) và bắt đầu các thao tác sửa chữa Database.
• Trạng thái khẩn cấp được giới thiệu từ phiên bản SQL Server 2005. Nó hữu dụng khi ta phải làm việc với một Database đang bị SQL Server đánh dấu là không đáng tin cậy (Suspect).
• Trong quy trình giải quyết các sự cố đã xảy đến với Database, trạng thái khẩn cấp cung cấp một vài tính năng linh động cho ta làm việc với một Database bị hư hay bị đánh dấu là không đáng tin cậy. Khi một Database được đặt vào trạng thái khẩn cấp, có 3 thay đổi chính trong cấu hình của Database này:
  • Database trở thành READ ONLY
  • Chỉ cho các user cấp cao nhất (như sa) truy cập
  • Không cho đăng nhập vào (vì nó đang ở trạng thái READ ONLY)

• Ở trạng thái khẩn cấp, ta có thể truy cập dữ liệu, và có thể Export dữ liệu sang một Database khác, hay ta cũng có thể chạy DBCC CHECKDB trên Database này để sửa các lỗi đang tồn tại.

III. Thực hành

• Để minh họa sự hữu ích của trạng thái khẩn cấp, ta cùng theo dõi bài thực hành sau đây, được thực hiện trên SQL Server 2008:
• Trước hết tôi tạo một Database và làm cho SQL Server đánh giá nó là không đáng tin cậy

–Tạo 1 Database tên là DBEmergency
CREATE DATABASE DBEmergency
GO
USE DBEmergency
GO
–Tạo 1 Table tên là tblTest với 2 cột Number, Name
CREATE TABLE tblTest (Number TINYINT, Name VARCHAR(15))
GO
–Insert 5 dòng vào Table tblTest
INSERT INTO tblTest (Number, Name)
SELECT 1, ‘One’ UNION ALL
SELECT 2, ‘Two’ UNION ALL
SELECT 3, ‘Three’ UNION ALL
SELECT 4, ‘Four’ UNION ALL
SELECT 5, ‘Five’ GO

• Sau đó tôi làm tiếp các bước sau:
  • Stop SQL Server Service
  • Mở file ldf của Database DBEmergency bằng notepad, sửa một vài dòng và lưu, đóng file lại.
    
• Start SQL Server Service.

• Bây giờ ta thấy Database đã ở trạng thái không đáng tin cậy (Suspect). Ta cũng có thể dùng T-SQL để xác nhận điều này

SELECT DATABASEPROPERTYEX (‘DBEmergency’, ‘STATUS’) AS ‘DBStatus’

• Và ở trạng thái này, ta không thể thực hiện bất kỳ câu truy vấn nào.

• Tiếp theo tôi chuyển Database sang trạng thái Emergency

ALTER DATABASE DBEmergency SET EMERGENCY
GO
Ta sẽ thấy như sau:

• Bây giờ ta sẽ dùng lệnh DBCC CHECKDB với tùy chọn REPAIR_ALLOW_DATA_LOSS để sửa lỗi cho Database này. Khi ta dùng REPAIR_ALLOW_DATA_LOSS, dữ liệu hay những Index bị hư sẽ bị loại bỏ khỏi Database để bảo đảm tính nhất quán. Nếu như những vấn đề phát sinh là do sự cố liên quan đến Transaction Log File, quá trình này sẽ tạo lại log file, ta đang ở trong trường hợp này

• Chạy đoạn script sau:

–Để sửa lỗi Database, ta cần chuyển sang chế độ Single User
ALTER DATABASE DBEmergency SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
–Bắt đầu sửa lỗi cho Database
DBCC CHECKDB (DBEmergency, REPAIR_ALLOW_DATA_LOSS)
GO
–Thiết lập Database trở lại trạng thái bình thường
ALTER DATABASE DBEmergency SET MULTI_USER WITH ROLLBACK IMMEDIATE
GO
ALTER DATABASE DBEmergency SET ONLINE
GO

• Như vậy là ta đã hoàn thành việc khắc phục một Database bị sự cố Suspect. Kết quả như sau:

Lưu ý:

• Mặc dù trạng thái khẩn cấp là một giải pháp tuyệt vời đưa Database của chúng ta trở lại trạng thái họat động bình thường, nhưng đây không phải cách tiếp cận cho Database lớn hơn. Điều quan trọng ta cần ghi nhớ là cần có một chiến lược hiệu quả cho việc Backup dữ liệu.
• Khi một Database đang ở trạng thái RESTORING, thì không thể chuyển sang trạng thái EMERGENCY, tương tự là các trạng thái OFFLINE, ONLINE.

Kiến thức bài viết được tham khảo từ mssqltips.com

Phân đoạn bảng trong SQL Server

Đây là tính năng mới được đưa vào SQL Server 2005 và tiếp tục được tăng cường ở phiên bản 2008. Đối với các ứng dụng truy cập từ bên ngoài, bảng (table) vẫn là một bảng duy nhất, chỉ có cấu trúc vật lý của nó là khác so với các bảng không phân đoạn.

Bảng được phân đoạn dựa vào giá trị một trường của nó (trường được chọn gọi là partition key). Ví dụ bạn có dữ liệu về các giao dịch bán hàng chứa trong bảng BanHang, bạn có thể phân đoạn theo năm của trường NgayGiaoDich (ngày giao dịch): các giao dịch xảy ra trong năm 2009 được nằm trong một đoạn riêng, tương tự với các giao dịch của năm 2010… Kỹ thuật này làm tăng khả năng mở rộng của SQL Server lên rất nhiều và giúp cho việc quản trị các cơ sở dữ liệu lớn trở nên dễ dàng hơn. Thử hình dung với một bảng dữ liệu chứa vài trăm triệu bản ghi thường xuyên được cập nhật, các tác vụ như backup/restore, hoặc create/rebuild index đều rất tốn kém thời gian. Việc truy vấn hoặc sửa đổi dữ liệu cũng rất vất vả. Table partitioning nhằm giải quyết các trở ngại đó, nó có các ưu điểm chính sau:
1. Tiện lợi về quản trị:
– Bạn có thể backup/restore một đoạn mà không ảnh hưởng đến các đoạn còn lại. Ví dụ, tại thời điểm năm 2010 các đoạn chứa dữ liệu của 2009 và các năm trước không còn tiếp nhận dữ liệu mới nữa, bạn không cần phải thường xuyên backup các đoạn này và chỉ cần backup đoạn 2010.
– Bạn cũng có thể REBUILD lại index trên từng đoạn (những đoạn cần phải REBUILD do có nhiều thao tác xóa, sửa) thay vì trên toàn bộ bảng.
– Nó cũng cho phép nhanh chóng loại bỏ dữ liệu nguyên một đoạn ra khỏi bảng thay vì phải dùng lệnh DELETE (thao tác này gọi là SWITCH-OUT). Tương tự nó cũng cho phép “nạp” dữ liệu từ một bảng khác vào thành một đoạn mới (SWITCH-IN). Tính năng này rất có giá trị đối với các ứng dụng ETL (Extract, Transform & Load) và Datawarehouse.
Ví dụ bạn cần import dữ liệu của năm 2008, bạn có thể import vào một bảng riêng và sau đó switch-in tức thì bảng này vào bảng chính. Trước khi có partitioning, bạn phải dùng lệnh INSERTđể chuyển dữ liệu từ bảng riêng vào bảng chính. Quá trình này mất nhiều thời gian hơn và trong suốt quá trình đó bảng bị khóa và không thể truy cập được.
2. Cải tiến về hiệu năng:
– Khi một câu lệnh chỉ cần lấy dữ liệu ở một đoạn nào đó thì hệ thống chỉ cần truy nhập vào đoạn đó và bỏ qua các đoạn còn lại (tính năng này gọi là partition elimination)
– Khi các đoạn dữ liệu được lưu trữ ở các ổ cứng khác nhau sẽ làm giảm tranh chấp vào/ra giữa các câu lệnh. Ví dụ hai câu lệnh SELECT và UPDATE hoạt động trên cùng một bảng nhưng ở hai đoạn khác nhau có thể thực hiện hoàn toàn song song với nhau.
Việc phân đoạn bảng dựa trên hai khái niệm mới sau đây:
– Partition function: Qui định giá trị biên cho các đoạn. Hệ thống dựa vào hàm này để xác định đoạn mà mỗi bản ghi thuộc vào.
– Partition scheme: Ánh xạ các đoạn khai báo trong partition function vào các filegroup (mỗi đoạn được lưu trữ tại một filegroup).
Dưới đây tôi sẽ đi qua từng bước thiết lập việc phân đoạn thông qua một ví dụ cụ thể.
Bạn có bảng BanHang gồm các cột BangHang_ID, NgayGiaoDich, MaSP, SoLuong, ThanhTien. Bạn muốn phân đoạn bảng theo từng năm của NgayGiaoDich: Để cho đơn giản, giả sử bạn muốn lưu các giao dịch của năm 2009 trở về trước vào một đoạn, trong năm 2010 vào một đoạn, và từ 2011 trở lên vào một đoạn (về sau bạn vẫn luôn luôn có thể sửa đổi để dành riêng một đoạn cho 2011 và bổ sung các đoạn mới cho 2012, 2013…). Như vậy với cấu hình ở trên, bảng sẽ có 3 đoạn: 2009 trở về trước, 2010, và 2011 trở về sau. Do đó bạn cũng cần 3 filegroup.
Bước 1: Tạo database và filegroup

CREATE DATABASE PartTest
GO
USE PartTest
GO
–tạo filegroup
ALTER DATABASE PartTest ADD FILEGROUP FG2009AndBefore
ALTER DATABASE PartTest ADD FILEGROUP FG2010
ALTER DATABASE PartTest ADD FILEGROUP FG2011AndAfter
–thêm data file vào mỗi filegroup
ALTER  DATABASE PartTest ADD FILE (NAME = N’FY2009AndBefore’, FILENAME =  N’D:\DATA\PartTest\FY2009AndBefore.ndf’) TO FILEGROUP FG2009AndBefore
ALTER DATABASE PartTest ADD FILE (NAME = N’FY2010′, FILENAME = N’D:\DATA\PartTest\FY2010.ndf’) TO FILEGROUP FG2010
ALTER  DATABASE PartTest ADD FILE (NAME = N’FY2011AndAfter’, FILENAME =  N’D:\DATA\PartTest\FY201AndAfter.ndf’) TO FILEGROUP FG2011AndAfter

Bước 2: Tạo partition function và partition scheme

USE PartTest
GO
CREATE PARTITION FUNCTION PFunc_NGD(DATETIME) AS RANGE RIGHT FOR VALUES (‘2010-01-01’, ‘2011-01-01’)
GO
CREATE PARTITION SCHEME PScheme_NGD AS PARTITION PFunc_NGD TO (FG2009AndBefore, FG2010, FG2011AndAfter)

Hàm partition function có tên PFunc_NGD định nghĩa giá trị biên cho các đoạn, là ngày đầu tiên của năm 2010 và ngày đầu tiên của 2011. Giống như khi bạn cắt một sợi dây, chỉ cần 2 nhát cắt để chia sợi dây làm 3 đoạn, ở đây cũng chỉ có 2 giá trị biên. Do vậy dải giá trị của các đoạn sẽ như sau:
Đoạn 1: Từ trước đến 2009-12-31 23:59
Đoạn 2: 2010-01-01 00:00:00 đến 2010-12-31 23:59
Đoạn 3: 2011-01-01 00:00:00 về sau
Sau đó partition scheme PScheme_NGD dùng hàm PFunc_NGD để “gắn” các đoạn vào từngfilegroup. Như vậy đoạn 1 sẽ đến FG2009AndBefore, đoạn 2 đến FG2010 và đoạn 3 đếnFG2011AndAfter.
Lưu ý, partition function không giống với các user-defined function. Trong Management Studio, bạn thấy partition function và partition scheme ở mục Database/Storage.
Một lưu ý nữa là một partition function có thể được dùng cho nhiều partition scheme, cả hai là các đối tượng chung trong database chứ không gắn liền với một bảng cụ thể. Khi định nghĩa bảng (xem bước 4) bạn cần chỉ định dùng partition scheme nào.
Bước 4: Tạo bảng dùng partition scheme

USE PartTest
GO
CREATE TABLE dbo.BanHang(
BangHang_ID INT IDENTITY,
NgayGiaoDich DATETIME,
MaSP INT,
SoLuong INT,
ThanhTien INT
) ON PScheme_NGD(NgayGiaoDich)
GO
CREATE CLUSTERED INDEX CI_BanHang_NGD ON dbo.BanHang(NgayGiaoDich) ON PScheme_NGD(NgayGiaoDich)

Mệnh đề “ON PScheme_NGD(NgayGiaoDich)” trong hai lệnh tạo bảng và tạo index ở trên chỉ định bảng BanHang và index CI_BanHang_NGD được tạo trên partition scheme PScheme_NGD, có nghĩa là để cho nó quản lý việc phân bổ dữ liệu. Vậy là bảng BanHang đã được phân đoạn. Bạn có thể kiểm tra xem dữ liệu được ghi vào đoạn nào:

ORACLE BLOCK, ROW MIGRATION, ROW CHAINING

Oracle block
Bất kỳ hệ điều hành nào cũng xác định riêng cho mình 1 block, gọi là OS block. OS block size là đơn vị nhỏ nhất cho việc read/write, và nó cũng là thuộc tính của file system. Khi tạo ra 1 Oracle Database, chúng ta sẽ xác định 1 Oracle block, size của Oracle block là 1 bội số của OS block size. Trước 9i, 1 khi đã xác định size của Oracle block, thì không thể thay đổi size này, và nó cũng tồn tại theo chu kỳ sống của Oracle Database. Để xác định 1 block size tương thích cho Database, ta phải xác định, nghiên cứu rất nhiều yếu tố trước khi đưa ra quyết định.

Hình 1.1

Header: Chứa các thông tin về data, ví dụ như block address, loại segment (table, index…), đồng thời nó cũng chứa thông tin về table, row thực sự (address) chứa data

Freespace: Không gian cấp phát cho việc insert/update trong tương lai, ảnh hưởng bởi giá trị của 2 tham số là PCTUSED và PCTFREE

Data: Row chứa dữ liệu
FreeList, PCTUSED, PCTFREE parameters:
Khi create/alter bất kỳ table/index nào, Oracle sẽ sử dụng 2 tham số đề điều khiển không gian
– PCTFREE: Số % dành riêng cho việc update các dữ liệu đã có trong tương lai
– PCTUSED: Số % của không gian nhỏ nhất đã được sử dụng cho việc insert data mới, giá trị này xác định khi nào thì các blocks sẽ được đưa trở lại vào trong FREELIST
– FREELIST: Cờu trúc xác định mà Oracle sử dụng để maitains 1 danh sách các block free hiện có.

Đầu tiên, Oracle sẽ tìm kiếm 1 free block trong FREELIST, sau đó, data sẽ được insert vào block đó, tính khả dụng của block trong FREELIST sẽ được xác định bởi giá trị của tham số PCTFREE, 1 block trống ban đầu sẽ được listed trong cấu trúc FREELIST, sau đó, nó vẫn sẽ còn ở đó cho đến khi không gian còn trống đạt đến ngưỡng của giá trị PCTFREE. Khi không gian trống đã đạt đến ngưỡng được xác định bởi giá trị của tham số PCTFREE, block sẽ được remove khỏi FREELIST, và nó sẽ được re-listed lại trong FREELIST khi và chỉ khi khối lượng data xuống dưới giá trị đã xác định của PCTUSED. Oracle sử dụng FREELIST để tăng hiệu năng hoạt động, với tất cả những câu lệnh Insert, thay vì tìm kiếm tất cả các block, Oracle sẽ chỉ tìm kiếm các free block trong FREELIST

PCTFREE
Hinh 1.2

Tham số PCTFREE xác định số % nhỏ nhất (không gian) của 1 data block được dành riêng cho việc update những row đã có trong block đó. Ví dụ: Nừu ta xác định 20% là giá trị của PCTFREE trong câu lệnh CREATE TABLE, thì có nghĩa, 20% của từng data block trong table segment sẽ được dành riêng cho việc update các row đã có bên trong từng block. Những row mới sẽ được thêm vào vùng row data, các thông tin tương ứng của chúng cũng được add vào row-overhead.

PCTUSED
Hinh 1.3

Tham số PCTUSED số % nhỏ nhất của 1 block có thể được sử dụng, cộng với phần overhead của các new row khi thêm vào block. Sau khi 1 data block đã đầy đến ngưỡng của PCTFREE, Oracle sẽ tìm kiếm các block hiện hữu chưa được sử dụng để insert row mới (xem phần FREELIST). Giả sử, ta xác định giá trị của tham số PCTUSED là 40% trong câu lệnh CREATE TABLE, thì trong trường hợp này, 1 data block được xác định là chưa khả dụng nếu như tổng không gian trong block này chưa giảm xuống 39% hoặc thấp hơn (giả sử rằng không gian trong block này trước đó đã đạt tới ngưỡng của PCTFREE).

PCTFREE và PCTUSED được sử dụng cùng nhau như thế nào?

2 tham số này được sử dụng cùng nhau để tối ưu hóa việc sử dụng không gian trong data block.
Trong 1 data block mới được cấp phát, thì không gian khả dụng cho việc insert chính là block size trừ đi phần block overhead và PCTFREE. Việc update có thể sử dụng bất kỳ không gian còn trống khả dụng nào trong block. Với mỗi một data và index segment, Oracle maitain một hoặc nhiều free list (xem ở trên), là danh sách các data block đã được cấp phát và có không gian lớn hơn tham số xác định của PCTFREE. Khi ta đưa ra 1 câu lệnh Insert, Oracle sẽ kiểm tra trong FREELIST để xác định block đầu tiên nào khả dụng cho việc insert này (tính khả dụng của data block trong FreeList đã nói ở trên).

Row Migration:
Trường hợp này, 1 row đã được lưu vào trong 1 data block, tuy nhiên, khi insert tiếp, free space đã đầy, và vì thế, Oracle sẽ migrate (dịch chuyển) data của toàn bộ row này sang 1 data block mới, với data block cũ, Oracle sẽ giữ lại 1 row piece – cũng chính là rowID để trỏ tới block mới.

Hinh 1.4

Đối với trường hợp Row Migration, việc Full Table Scan không bị ảnh hưởng (I/O increase), là bởi vì Forward address sẽ bị bỏ qua, tuy nhiên, Row Migration lại làm ảnh hưởng đến việc đọc Index. Bởi vì, Index sẽ nói rằng : “Đến file X, block Y, slot Z…để tìm row này”, và vì thế, khi nhận được thông điệp trên, ta lại mất thêm 1 I/O physical hoặc logical để tìm row này. (Physical I/O, Logical I/O đề cập ở phần khác).

Row Chaining:
Trong nhiều trường hợp, data cho 1 row quá lớn để lưu trong 1 single data block, do vậy, Oracle sẽ lưu data của row này vào trong 1 hoặc nhiều chained data block (các data block móc nối). Lờy ví dụ, nếu ta sử dụng 1 data block size 4KB cho Database, và cần insert 1 row với size 8KB, Oracle sẽ sử dụng 3 blocks để lưu lại data trong row. Row chaining xảy ra với các trường hợp
– Rowsize vượt quá data block size
– Table có LONG và LONGRAW columns
– Table có trên 255 column

Với trường hợp này, sẽ không có Forward Address trên 1 data block, mà ta sẽ có data trên ít nhất 2 block. Chained row có ảnh hưởng (tác động) rất khác nhau. Lờy ví dụ, chúng có có 1 row với 2 column trên 2 block. Query:

CODE: SELECT ALL

SQL> select column1 from tableA


Với column1 trên block1, sẽ không có “table fetch continued row”, tuy nhiên, nếu cũng với query:

CODE: SELECT ALL

SQL> select column2 from tableA


Thì ta sẽ nhận được kết quả với giá trị trả về trong “table fetch continued row” bởi vì block2 chính là chained row.

Xét ví dụ với cả 2 trường hợp Row Migration và Row Chaining:

CODE: SELECT ALL

SQL> show parameter db_block_size
SQL> show parameter db_block_sizeNAME                                 TYPE        VALUE
———————————— ———– ——-
db_block_size                        integer     4096
SQL>
SQL> CREATE TABLE row_mig_chain_demo (
2    x int PRIMARY KEY,
3    a CHAR(1000),
4    b CHAR(1000),
5    c CHAR(1000),
6    d CHAR(1000),
7    e CHAR(1000)