Di Chuyển File Khi Khôi Phục Dữ liệu

Khi bạn cần khôi phục (restore) database từ file backup từ một server khác, sự phân bố file trên server kia có thể khác với server này và khi restore bạn cần lưu ý đến điều đó. Ví dụ, trên server nguồn (server 1) data file nằm ở ổ E: và log file nằm ở ổ F:; trong khi server mà bạn đang restore lên (server 2) không có ổ E: và F: mà thay vào đó data file được chứa ở ổ P: và log file ở ổ Q:. Khi đó lệnh RESTORE thông thường sẽ gây ra thông báo lỗi:

RESTORE FILELISTONLY
FROM DISK='\\Server1\E$\Backup\TestDB.bak' 
--kết quả
--LogicalName	PhysicalName
--TestDB	E:\Data\TestDB.mdf
--TestDB_log	F:\Log\TestDB_log.LDF
 
RESTORE DATABASE TestDB
FROM DISK='\\Server1\E$\Backup\TestDB.bak'


Msg 5133, Level 16, State 1, Line 1
Directory lookup for the file “E:\Data\TestDB.mdf” failed with the operating system error 3(The system cannot find the path specified.).
Msg 3156, Level 16, State 3, Line 1
File ‘TestDB’ cannot be restored to ‘E:\Data\TestDB.mdf’. Use WITH MOVE to identify a valid location for the file.
Msg 5133, Level 16, State 1, Line 1
Directory lookup for the file “F:\Log\TestDB_log.LDF” failed with the operating system error 2(The system cannot find the file specified.).
Msg 3156, Level 16, State 3, Line 1
File ‘TestDB_log’ cannot be restored to ‘F:\Log\TestDB_log.LDF’. Use WITH MOVE to identify a valid location for the file.
Msg 3119, Level 16, State 1, Line 1
Problems were identified while planning for the RESTORE statement. Previous messages provide details.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.

Lỗi dài dòng nhưng tóm lại là nó phàn nàn là không thể restore data file vào ổ E và log file vào ổ F như yêu cầu, và gợi ý dùng “WITH MOVE” để chọn địa điểm khác. Cách khắc phục là bạn đưa lựa chọn “WITH MOVE” vào lệnh RESTORE và cung cấp địa điểm thích hợp:

RESTORE DATABASE TestDB
FROM DISK='\\Server1\E$\Backup\TestDB.bak' 
WITH MOVE 'TestDB' TO 'P:\Data\TestDB.mdf',
MOVE 'TestDB_log' TO 'Q:\Log\TestDB_log.ldf'
Posted on 13/8/2013 by Vũ Huy Tâm | Categories: Database Administration

Parameter Sniffing

Trước khi vào bài viết, tôi muốn kể lại một vài tình huống tôi đã trải qua.
Tình huống 1: Một ngày nọ, một thành viên trong nhóm Database của tôi gặp một hiện tượng kì lạ. Stored Procedure mà cậu ấy viết khi chạy trên môi trường test rất tốt, thời gian xấp xỉ 1 giây. Tuy nhiên khi đưa lên hệ thống thật, thì lại chạy ì ạch mất khoảng 30 giây.
Cậu ấy thay hết giá trị vào stored, chạy trên SSMS dưới dạng câu SQL bình thường thì lại chạy tốt. Vò đầu bứt tai một hồi cậu ấy đâm ra nghi ngờ khi sử dụng Stored Procedure và có kế hoạch thay hết Stored đã viết bằng dynamic sql để tăng hiệu năng. … đọc tiếp »

Posted on 25/6/2013 by Guess Post: Vũ Minh Tâm | Categories: SQL Server Programming, Stored Procedure

Dữ Liệu Kiểu DATE Và Kiểu TIME

Cùng với loại dữ liệu DATETIME để chứa dữ liệu kiểu ngày giờ, SQL Server 2008 bổ sung thêm hai kiểu dữ liệu là DATE cho ngày riêng và TIME cho giờ riêng.

CREATE TABLE #t (d DATE, ti TIME)
 
INSERT INTO #t VALUES(GETDATE(), GETDATE())
INSERT INTO #t VALUES('2013-06-21', '03:23pm')
INSERT INTO #t VALUES('2013-06-21', '14:13')
INSERT INTO #t VALUES('2013-06-21', '16:36:12.124')

Như ở ví dụ trên, bạn thấy khi thêm dữ liệu kiểu DATETIME vào trường kiểu DATE, chỉ dữ liệu phần DATE được lưu lại và phần TIME bị cắt bỏ. Và khi thêm dữ liệu kiểm DATETIME vào trường kiểu TIME, chỉ dữ liệu phần TIME được giữ lại còn phần DATE bị cắt bỏ. Trường kiểu TIME cũng nhận dữ liệu với khuôn dạng và độ chính xác khác nhau.
Việc tách DATE và TIME làm hai kiểu dữ liệu làm tăng tính linh hoạt cho ứng dụng. Ví dụ khi bạn cần lưu thông tin các lần xảy ra mất điện ở các vùng trong một tỉnh, có thể có lần bạn chỉ nhận được thông tin về ngày mà không có giờ cụ thể. Trong trường hợp này, ở các phiên bản trước, khi lưu vào trường DATETIME, phần thông tin về thời điểm sẽ tự động được đặt thành 00:00:00 (nửa đêm), tuy nhiên điều này có thể gây nhầm lẫn vì có thể có lần mất điện xảy ra chính xác vào lúc nửa đêm. Điều này trở nên quan trọng hơn khi bạn lưu kèm theo thời điểm điện được khôi phục trở lại, chẳng hạn để đánh giá tốc độ khôi phục sự cố. Với những lần mất điện mà không thu thập được thời điểm, khoảng thời gian mất điện luôn được tính bắt đầu từ lúc 00:00:00 và như vậy là sai.
Khi tách làm hai trường DATE và TIME, bạn có thể nhập ngày và giờ mất điện vào hai trường và khi không có dữ liệu về giờ, trường sẽ chứa NULL. Khi phân tích dữ liệu, bạn phân biệt được trường hợp nào có giờ và trường hợp nào không để tính toán cho chính xác.
Trường kiểu DATE khi được chuyển thành kiểu DATETIME sẽ tự động thêm ’00:00:00′ vào phần thời gian. Còn trường kiểu TIME khi được chuyển thành kiểu DATETIME sẽ được cộng thêm ’1900-01-01′ vào phần ngày tháng. Bạn cũng có thể ghép hai trường kiểu DATE và TIME để tạo thành dữ liệu kiểu DATETIME. Hãy xem các tình huống ở ví dụ dưới:

SELECT CAST(d AS DATETIME), CAST(ti AS DATETIME),
	CAST(d AS DATETIME) + CAST(ti AS DATETIME)
FROM #t
Posted on 7/6/2013 by Vũ Huy Tâm | Categories: Thiết kế database

Index Partitioning

Với một bảng đã được phân đoạn, mỗi index được tạo ra theo mặc định được phân đoạn theo giống như bảng. Ví dụ bảng được phân đoạn theo năm của ngày giao dịch thì index cũng được phân đoạn theo cách đó. Index khi đó được gọi là aligned với bảng. Tuy nhiên bạn cũng có thể không phân đoạn cho index và để nó nguyên một khối, hoặc phân đoạn theo cách khác. Khi đó index được gọi là non-aligned.
Bạn hãy hình dung bảng như một cái bánh tét, và index là sợi lạt buộc xung quanh. Khi phân đoạn, chiếc bánh được cắt thành từng lát. Nếu sợi lạt cũng được cắt theo và mỗi sợi con giờ buộc xung quanh từng lát bánh, sợi lạt được gọi là aligned với chiếc bánh. Nếu sợi lạt không được cắt và vẫn bao xung quanh cả chiếc bánh to, sợi lạt được gọi là non-aligned với chiếc bánh.
SQL Server luôn ưu tiên phân đoạn index để nó aligned với bảng và luôn cố gắng phân đoạn khi có thể, vì nó đem lại nhiều thuận lợi cho các tác vụ trên bảng. Tuy nhiên khi đi vào chi tiết từng loại index, cách cư xử này được thể hiện qua những sắc thái khác nhau, ta sẽ xem xét kỹ hơn ở dưới đây. … đọc tiếp »

Posted on 7/5/2013 by Vũ Huy Tâm | Categories: Index, Table partitioning, Thiết kế database

Các Thuộc Tính ACID

ACID là viết tắt của cụm từ Atomicity (nguyên tử), Consitency (nhất quán), Isolation (Cô lập), và Durability (Lâu bền). Đây là các thuộc tính mà mọi transaction đều được đảm bảo bởi SQL Server.
Atomicity: Thuộc tính này đảm bảo mỗi transaction là một khối duy nhất, được thực hiện trọn vẹn hoặc hoàn toàn không được thực hiện. Nếu có một lỗi nào đó xảy ra trong transaction, nó sẽ được quay trở lại (rollback) trạng thái ban đầu. Khi bạn gom nhiều lệnh vào một transaction (bao giữa BEGIN TRAN và COMMIT), sẽ chỉ có hai khả năng được phép xảy ra là, tất cả các lệnh này sẽ được thực hiện hoặc không có lệnh nào được thực hiện. Ở mức từng lệnh, SQL Server cũng đảm bảo tính atomicity, ví dụ một lệnh INSERT cho 10 bản ghi, nếu đang thêm được 5 bản ghi thì gặp lỗi, hệ thống sẽ hủy bỏ và không bản ghi nào được thêm. Nếu lệnh có kèm theo trigger, lỗi ở trigger cũng kéo theo lệnh bị hủy bỏ.
Khi bạn phát ra lệnh ROLLBACK, tất cả các lệnh đã thực hiện cũng bị quay lui và transaction trở lại trạng thái như trước khi thực hiện.
Consistency: SQL Server đảm bảo ở mọi thời điểm dữ liệu luôn luôn phải nhất quán, tức là tuân theo các ràng buộc đã được định nghĩa (ví dụ trường kiểu ngày phải chứa dữ liệu kiểu ngày, bản ghi bán hàng phải có mã sản phẩm hợp lệ…). Khi transaction được thực hiện, dữ liệu sau khi cập nhật cũng phải ở trạng thái nhất quán. Nếu transaction gây ra những vi phạm về ràng buộc dữ liệu, hệ thống sẽ không cho phép thực hiện tiếp và hủy bỏ toàn bộ transaction.
Isolation: Cũng như các hệ thống server khác, SQL Server có thể đáp ứng nhiều yêu cầu xảy ra đồng thời. Nhưng mỗi transaction được đảm bảo thực hiện trong một ngữ cảnh riêng biệt của nó và không bị ảnh hưởng bởi các transaction khác. Khi hai transaction cùng cập nhật một dữ liệu, SQL Server đảm bảo chúng được thực hiện tuần tự không dẫm lên chân của nhau.
Durability: Khi transaction thực hiện xong (đã commit), những cập nhật trở nên cố định và dữ liệu sẽ luôn luôn là như vậy. Khi hệ thống gặp sự cố bất ngờ, trong quá trình khôi phục lại nó sẽ đảm bảo khôi phục lại dữ liệu cho những transaction đã được commit.

Posted on 4/4/2013 by Vũ Huy Tâm | Categories: Database Administration

SQL Saturday

Tạm hoãn – Do thời gian biểu của mình không cho phép thực hiện dự án này trong thời điểm hiện tại, mình đành tạm thời dừng lại công việc này. Thành thật xin lỗi các bạn!
SQL Saturday là một chương trình đào tạo SQL bằng việc tổ chức một ngày hội thảo về SQL vào ngày thứ Bảy và thường là miễn phí. Mục đích của chương trình là cung cấp kiến thức về SQL Server cho cộng đồng, thông qua các bài giảng trực tiếp về tất cả các lĩnh vực xung quanh SQL Server. Tôi đã đi dự 1 lần hồi năm ngoái và trong tháng 12 sẽ đi một cái nữa (http://www.sqlsaturday.com/173/eventhome.aspx). Các bài giảng đều nhắm đến các vấn đề cụ thể và chia ra nhiều cấp cho mọi người từ bắt đầu đến nâng cao. Tôi rất thích chương trình này vì mục đích của nó và vì tính thực tiễn trong cách truyền bá kiến thức. Những người giảng đều là những người đang trực tiếp làm việc và truyền đạt lại kinh nghiệm của mình. Không đao to búa lớn, không phải nhân viên của Microsoft hô hào quảng bá tính năng nọ kia một các hời hợt và sáo rỗng.
Khi mới thành lập, chương trình này chủ yếu được tổ chức ở Mỹ, nhưng gần đây rất nhiều nơi trên thế giới đã bắt đầu tổ chức. Thậm chí kể cả những nơi tưởng như không thể sáng lòa như Việt nam (hay nói cách khác là tối tăm không kém gì Việt nam) như Nepal, Thổ nhĩ kỳ, Trinidad Tobago… cũng đã xuất hiện. Vì thế tôi rất muốn nhìn thấy sự kiện này được tổ chức ở Việt nam. Tất nhiên một mình mình thì không làm nổi. Quan trọng nhất là cần một nhóm bạn có kinh nghiệm làm việc tình nguyện tham gia giảng bài. Bạn nào có cùng ý tưởng này xin hãy trao đổi qua đây hoặc email cho tôi vuht2000@yahoo.com. Chung tay với nhau chúng ta có thể làm được một việc to tát hơn.

Posted on 29/11/2012 by Vũ Huy Tâm | Categories: Linh tinh

Thứ Tự Xử Lý Điều Kiện Ở Mệnh Đề WHERE

Theo bạn các điều kiện trong mệnh đề WHERE được xử lý theo thứ tự nào, từ phải sang trái hay từ trái sang phải? Thực tế là, chúng không phải luôn luôn được xử lý theo một thứ tự nhất định như các ngôn ngữ khác. Chúng được xử lý theo cách SQL Server đánh giá là đạt hiệu quả cao nhất với từng câu lệnh. Nếu bạn viết code các điều kiện của mệnh đề WHERE dựa trên giả định chúng được xử lý theo thứ tự nào đó, bạn sẽ gặp tình huống câu lệnh bị lỗi khi thứ tự xử lý bị đảo ngược (ví dụ khi lượng dữ liệu thay đổi và/hoặc có thêm index mới được tạo…).
Ta hãy thực hiện thí nghiệm sau: … đọc tiếp »

Posted on 31/10/2012 by Vũ Huy Tâm | Categories: SQL Server Programming, Tip & Trick

Các Mức Isolation Level

Isolation level là một thuộc tính của transaction, qui định mức độ cô lập của dữ liệu mà transaction có thể truy nhập vào khi dữ liệu đó đang được cập bởi một transaction khác. Khi một transaction cập nhật dữ liệu đang diễn ra, một phần dữ liệu sẽ bị thay đổi (ví dụ một số bản ghi của bảng được sửa đổi hoặc bị xóa bỏ, một số được thêm mới), vậy các transaction hoặc truy vấn khác xảy ra đồng thời và cùng tác động vào các bản ghi đó sẽ diễn ra thế nào? Chúng sẽ phải đợi đến khi transaction đầu hoàn thành hay có thể thực hiện song song, kết quả dữ liệu nhận được là trong khi hay sau khi cập nhật? Bạn có thể điều khiển những hành vi này thông qua việc đặt isolation level của từng transaction. SQL Server cung cấp các mức isolation level sau xếp theo thứ tự tăng dần của mức độ cô lập của dữ liệu: Read Uncommitted, Read Commited, Repeatable Read, và Serializable. Từ bản 2005 bắt đầu bổ sung thêm một loại mới là Snapshot. Phần còn lại của bài này sẽ đi vào chi tiết của từng loại. … đọc tiếp »

Posted on 23/10/2012 by Vũ Huy Tâm | Categories: SQL Server Programming

Filegroup Trong SQL Server

Filegroup là tên đặt cho một nhóm data file trong SQL Server. Filegroup không chứa dữ liệu, mà chỉ định nghĩa ở mức logic các data file nằm trong đó, và đến lượt các data file này mới thực chứa dữ liệu. Bạn có thể hình dung filegroup giống như một thư mục của Windows, và các data file thuộc về filegroup đó tương tự như các file trong thư mục. Khi bạn tạo một database, ở mức đơn giản nhất sẽ có hai file được tạo ra là một log file (.ldf) và một data file (.mdf). Tuy nhiên một điều có thể bạn ít để ý hơn là cũng có một filegroup được tạo ra cùng với nó: … đọc tiếp »

Posted on 8/8/2012 by Vũ Huy Tâm | Categories: Database Administration, Thiết kế database