แสดงบทความที่มีป้ายกำกับ Database แสดงบทความทั้งหมด
แสดงบทความที่มีป้ายกำกับ Database แสดงบทความทั้งหมด

วันอังคารที่ 20 กรกฎาคม พ.ศ. 2553

command แจ่มๆบน SQL Server 2005

1) command ตรวจสอบว่า มี temporary table ค้างอยู่ในระบบหรือไม่
select name
from tempdb..sysobjects

2) select statement plans ที่ถูกใช้บ่อยที่สุดออกมา
SELECT TOP 100
qs.execution_count,
DatabaseName = DB_NAME(qp.dbid),
ObjectName = OBJECT_NAME(qp.objectid),
StatementDefinition =
SUBSTRING (
st.text,
(
qs.statement_start_offset / 2
) + 1,
(
(
CASE qs.statement_end_offset
WHEN -1 THEN DATALENGTH(st.text)
ELSE qs.statement_end_offset
END - qs.statement_start_offset
) / 2
) + 1
),
query_plan,
st.text, total_elapsed_time
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
CROSS APPLY sys.dm_exec_query_plan (qs.plan_handle) qp
WHERE
st.encrypted = 0
ORDER BY qs.execution_count DESC

วันเสาร์ที่ 10 เมษายน พ.ศ. 2553

รูปแบบของ Concurrency Control กับ Database

Database Concurrency Control คือ วิธีการควบคุม จัดการ กรณีที่ user 2 คนขึ้นไป
จะทำการแก้ไข เปลี่ยนแปลง หรือ ลบ ข้อมูลใน Database พร้อมๆกัน ซึ่งการที่ user 2 คนขึ้นไป
เข้ามาทำอะไรพร้อมๆกันนั้น อาจทำให้เกิดความผิดพลาดกับข้อมูลได้
แล้วจะจัดการกับเคสนี้อย่างไร ?
1. ไม่จัดการอะไรเลย
เคสนี้ ก็สะดวกดีกับคนเขียนโปรแกรม(-*-) ก็คือ ใคร update ทีหลังสุด ชนะไปเลย(เขียนทับของคนก่อนไปให้หมด) ซึ่งแน่นอน เกิด error ชัวร์ๆ ล้าน%
2. จัดการโดยใช้วิธีที่เรียกว่า Pessimistic concurrency control
ก็คือ ใครที่เข้ามาก่อน จะได้สิทธิ์ Lock Database ไปด้วยในตัว ทำให้ user ที่ 2 ที่เข้ามา จะไม่สามารถ grant เอา role สำหรับการแก้ไข เปลี่ยนแปลง ข้อมูล มาใช้ได้ ต้องรอให้ user คนแรกทำธุระให้เสร็จก่อนนั่นเอง
วิธีนี้ก็ดูเหมือนจะปลอดภัยดี แต่กับระบบเว็บ เราจะไป Lock ทิ้งไว้เลยแบบนี้คงไม่เวิร์ค ไหนจะ ปิด web browser โดยไม่ log out มั่งล่ะ จะค้างยาวไป จนกว่าจะ time out ไปนั่นแหละ(เซ็ต time out ไว้นาน ก็รอกันไปเถิด)
3. จัดการโดยใช้วิธีที่เรียกว่า Optimistic concurrency control(อันนี้ละแหล่มสุด)
ก็คือ จะไม่มีการ Lock Database ไว้ยาวๆแต่อย่างใด(จริงๆมันก็ Lock แป้ปนึงแหละ) ประเด็นคือ ไอ่ตอนเขียนข้อมูลทับลง Database นั่นแหละ จะมีการตรวจสอบว่า ข้อมูลที่ user เรียกขึ้นมาเห็นในหน้าจอ ก่อนที่จะแก้ไข กับ ข้อมูลที่อยู่ใน Database จริงๆ ณ ช่วงที่จะ update Database จริง ตรงกันฟิลด์ต่อฟิลด์หรือไม่
ถ้าตรงกัน ก็ยอมให้ Update ได้ แต่ถ้าไม่ แสดงว่า มีใครซักคนมาเขียนทับไปก่อนเรา เคสนี้ จะ throw Exception ออกมาได้ครับ โปรแกรมเมอร์ก็แค่ show error message ที่หน้าเว็บก็พอแล้ว

ผมเอง เน้นไปที่ Optimistic concurrency control เป็นหลัก(กำลังศึกษาอยู่) เพราะด้วยการ implement แนวทางนี้ จะสามารถนำไปใช้กับ web application ได้จริง
กำลังลองผิดลองถูกอยู่ครับ(ยังไม่สำเร็จ) ไว้ได้ผลยังไงจะมารายงานอีกรอบละกัน