PDA

View Full Version : استفاده همزمان چندین کاربر از دستابیس SQL تحت شبکه



programmernet
چهارشنبه 02 بهمن 1392, 19:00 عصر
سلام دوستان من برنامه ای نوشتم که در شبکه اجرا میشه . و دیتابیسم sql 2005 است . اما یه مشکلی دارم کاربرام نمی تونن همزمان ار دیتا بیس استفاده کنند و عملیات ثبت و .... را انجام بدن . خواهش می کنم کمک کنید . شنیدن که sql و اوراکل تا 255 تا کاربر را به صورت همزمان پشتیبانی می کنند . لطفا راهنماییم کنید کارم فوریه .

matin.soft
چهارشنبه 02 بهمن 1392, 21:15 عصر
چه خطایی می ده دوست عزیز.لطفاً سؤالتون رو بصورت کامل مطرح نمایید
موفق باشید

programmernet
چهارشنبه 02 بهمن 1392, 21:28 عصر
خطاش اینه که دیتا بیس قابل استفاده نیست وقتی دو تا کاربر همزمان با هم یک کاری را انجام بدن

programmernet
چهارشنبه 02 بهمن 1392, 21:34 عصر
من می خوام بدونم چطور می تونم چندین کاربر به صورت همزمان از دیتا بیس sql تحت شبکه من استفاده کنن بدون اینکه مشکلی واسشون پیش بیاد

alireza.zahani
چهارشنبه 02 بهمن 1392, 21:39 عصر
اگه شبکه باشه سیستمت باید sql روی یه سرور نصب باشه و کاربرای دیگه برا connection string بادید نام server رو بزنی
فرضا connectionet intori beshe
server1/localhost

programmernet
پنج شنبه 03 بهمن 1392, 18:42 عصر
اینا میدونم که چطوری دیتا بیسم را تحت شبکه کنم . سوالم اینه اینکه چندین کاربر بخوان همزمان دستوراتی را به دیتا بیس ارسال کنند دچار مشکل می شم . یعنی اگر دو تا کاربر با هم دستور insert یا delet را ارسال کنند .

لطفا راهنمایی کنید .

مرسی

امیر مهرشاد
جمعه 04 بهمن 1392, 12:44 عصر
کنترل قفل در SQL Server

یک سیستم بانک اطلاعاتی باید توانایی اجرای همزمان تراکنشها را داشته باشد. و همین concurrency یا همزمانی باعث میشود تا با مشکلاتی مواجه شویم که ما را نیازمند قفل می کند. مشکلات ایجاد شده در قالب مثال هایی در ادامه بررسی می کنیم.

مشکلات عدم استفاده از قفل
در نظر بگیرید که اجرای دو تراکنش همزمان شده است. تراکنش اول، داده x را از بانکاطلاعاتی می خواند. سپس تراکنش دوم نیز داده x را می خواند. تراکنش اول، x+5 را به جای x در بانک اطلاعاتی می نویسد. تراکنش دوم، x+1 را در بانک اطلاعاتی به جای x می نویسد. و هر دو به کارشان خاتمه می دهند.

حتما متوجه شده اید که مشکلی که در اینجا با آن روبرو می شویم، از دست دادن update انجام شده توسط تراکنش اول است. چون تراکنش دوم، دوباره بر روی داده update شده توسط تراکنش اول می نویسد. به این مشکل، lost update می گویند. راه بر طرف کردن آن، این است که وقتی تراکنش اول داده x را خواند، نباید تراکنش دیگری بتواند آنرا update کند، تا کار تراکنش اول به انتها برسد. یعنی باید داده x را قفل کرد تا تراکنش دیگری نتواند به آن دسترسی پیدا کند. البته، باید سطوح مختلفی برای قفل در نظر گرفت. چون بقیه تراکنش ها می توانند داده x را بخوانند، فقط نباید آنرا update کنند.

برای مثال دوم، فرض کنید که تراکنش اول داده x را می خواند و آنرا به x+5 تغییر می دهد. حال تراکنش دوم، داده x را می خواند و می خواهد بر اساس آن محاسباتی انجام دهد و مثلا داده y را با نتیجه بدست آمده بروز رسانی کند. تراکنش دوم، پس از بروزرسانی داده y به کار خود پایان می دهد. سپس تراکنش اول از تغییراتی که در بانک اطلاعاتی اعمال کرده است، پشیمان میشود. به عبارت دیگر با دستور rollback به تراکنش پایان می دهد. مشکلی که اینجا با آن مواجه هستیم، کارکرد تراکنش دوم بر مبنای داده های نادرست می باشد. این مشکل را نیز با قفل می توان حل کرد. به این مشکل dirty read می گویند.

حال فرض کنید که تراکنش اول، داده x را می خواند. سپس تراکنش دوم داده x را تغییر می دهد. حال اگر تراکنش اول دوباره داده x را بخواند، با مقدار جدیدی مواجه خواهد شد. به عبارت دیگر، دستور خواندن تکرار شدنی نیست. به این مشکل unrepeatable read می گویند.

و بالاخره به عنوان مثال آخر، در نظر بگیرید که تراکنش اول، رکوردهای یک جدول را می خواند. مثلا ۲۰ رکورد برگشت داده می شود. حال تراکنش دیگری می آید و یک رکورد جدیدی به جدول اضافه می کند. تراکنش اول، دوباره رکوردها را می خواند و ایندفعه با یک رکورد جدید روبرو می شود که قبلا نبود. رکوردی که مثل یک روح، یک دفعه در بین رکوردها ظاهر شده است!. همین اتفاق برای عمل حذف رکورد نیز صدق می کند. به این مشکل phantom read می گویند.

همانگونه که شاید حدس زده باشید، تمام مشکلات ناشی از اجرای هزمان چند تراکنش با یکدیگر می باشد. و اجرای همزمان تراکنش ها نیز در یک سیستم بانک اطلاعاتی امری اجتناب ناپذیر است. پس استفاده از یک سیستم کنترل قفل نیز اجتناب ناپذیر خواهد بود. روش های مختلفی برای کنترل اجرای همزمان تراکنش ها با یکدیگر وجود دارد، که در اینجا در مورد آنها بحث نخواهیم کرد. فقط به عنوان نمونه isolation level را که در SQL Server برای رفع همین مشکلات مورد استفاده قرار می گیرد، را در ادامه مورد بررسی قرار می دهیم.

ISOLATION LEVEL
sql server چهار سطح را برای رفع مشکلات فوق در نظر گرفته است. حتما متوجه شده اید که برخی از مشکلات عنوان شده فوق، همیشه مشکل به حساب نمی آید. مثلا در یک کاربرد ممکن است که مهم نباشد که ما مشکل phantom read داشته باشیم. isolation level برای یک تراکنش با دستور زیر مقداردهی می شود:

SET TRANSACTION ISOLATION LEVEL {
READ COMMITTED |
READ UNCOMMITTED|
REPEATABLE READ|
SERIALIZABLE}

هر کدام از چهار مقداری که می توان به آن نسبت داد را در ادامه بررسی می کنیم. نکته ای که باید قبل از ادامه بحث، به آن اشاره شود این است که مشکل اول یعنی lost update یکی از مشکلات اساسی بوده و در تمام کاربردها باید این مشکل رفع شود. بنابراین sql server به صورت پیش فرض برای تمام مقادیر انتخاب شده برای isolation level در نظر می گیرد. از بروز سه مشکل دیگر عنوان شده فوق، می توان به دلخواه با انتخاب یکی از مقادیر زیر برای isolation level جلوگیری کرد.

READ UNCOMMITTED
این مقدار، مساوی با این است که می خواهیم هیچ مکانیزم قفلی اعمال نشود. نتیجه آن نیز در صورت همزمانی تراکنش ها، احتمال وقوع مشکلات عنوان شده فوق می باشد.

READ COMMITTED
این مقدار پیش فرض برای isolation level می باشد. این مقدار تضمین می کند که داده ای که خوانده می شود یک داده commit شده باشد. یعنی مشکل dirty read بوجود نخواهد آمد. ولی دو مشکل آخری در این حالت می تواند بروز کند. نحوه رفع این مشکل نیز بدین صورت است که هر گاه تراکنشی داده ای را تغییر دهد و هنوز commit نکرده باشد، آن داده با قفل exclusive برچسب گذاری می شود. سپس اگر تراکنشی بخواهد داده را بخواند، سیستم اجازه خواندن داده را نمی دهد تا قفل آن داده آزاد شود. البته شرح کامل نحوه نسبت دهی قفل ها در [۱] آورده شده است و بحثی طولانی است که اینجا جای آن نیست!

REPEATABLE READ
این مقدار تضمین می کند که مشکل repeatable read نیز اتفاق نخواهد افتاد. این مشکل نیز به این صورت حل می شود که داده هایی که توسط یک تراکنش خوانده شده اند، قفل می شوند و اجازه تغییر آنها توسط تراکنش های دیگر تا انتهای اجرای این تراکنش داده نمی شود.

SERIALIZABLE
این مقدار تضمین می کند که هیچ یک از مشکلات عنوان شده فوق اتفاق نخواهد افتاد. مشکلی که تا مرحله قبل باقی مانده بود، مشکل phantom read می باشد. برای رفع این مشکل، sql server قفلی به data set خوانده شده توسط یک تراکنش تا انتهای آن اعمال می کند که تراکنش دیگری نتواند در طول اجرای آن تراکنش، رکوردی را ایجاد یا حذف کند.

منبع :http://www.fanoos-forum.com/

systam
پنج شنبه 08 اسفند 1392, 23:24 عصر
سلام
شاید کمکت کنه (http://barnamenevis.org/showthread.php?434765-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%A8%D8%B1%D8%A7%D9%8A-%D8%AF%D9%88-%D8%B1%D8%A7%D9%8A%D8%A7%D9%86%D9%87)