linked server ها(۳)

قسمت اول ،قسمت دوم ، قسمت چهارم

مبحث کارآیی

سبک تبادل اطلاعات با remote sever شامل overhead بزرگی است که تنها شامل log in به remote server نمی شود، بلکه دریافت اطلاعات از remote server هم در آن می گنجد. بر طبق یک آنالیزی که انجام شده، بطور تخمینی اجرای یک Query تحت remote server تقریبا بیش از ۲۰ برابر اجرای ان بصورت Local منابع را اشغال کرده است.هنگامی که جدول نویسندگان را بر روی هر دو سرور با داده های زائد قرار دادم و showplan را اجرا کردم، حدودا ۳ برابر بیشتر زمان صرف شد.

اگر شما داده های بیش از نیازتان از remote server  درخواست کنید، سرعت اجرای query و حتی کارآیی کل شبکه را کاهش خواهید داد و ممکن است مدیر شبکه وارد شده و بر سرتان فریاد بکشد!

کاهش ترافیک

با دستور where ما این امکان را خواهیم داشت که بجای کل جدول ، داده هایی را که دقیقا مورد نظر است از remote server بازیابی کرده و به شکل محسوسی کارآیی را بالا ببریم.

select r.au_fname as remote_fname,r.au_lname as remote_lname,   l.*

from  authors l              

join  fuji_PUBS_DB.pubs.dbo.authors r

on    l.au_id = r.au_id

where (l.au_fname <> r.au_fname OR l.au_lname <> r.au_lname )

and   r.au_id in ('172-32-1176', '213-46-8915', '238-95-7766', '267-41-2394')

 توجه کنید که ردیفهایی که بصورت local موجودند را از سرور local  و تنها ردیفهایthe au_fname و au_lname  از remote server بازیابی شده اند. اگر دستور "select * from" را برای بازیابی داده ها استفاده می کردیم،SQL Server مجبور به بازیابی همه ستونها ،‌حتی آنهایی که نگاهی به آنها نمی اندازیم می شد. SQL Server 2000 به اندازه ای باهوش است که تنها ۲ردیف مورد نظر و یک ردیف au_id را بعنوان شناسه استفاده شده در دستور where را که مورد نیاز است،بازیابی کند. تنها ذره ای برنامه نویسی تر وتمیز توسط شما با MS SQL Server لازم است!

شما می توانید با استفاده از Query Analyser ، با نمایش execution plan و تمرکز روی آیکون remote query ، چک کنید که آیا query شما بهینه است یا خیر.

فراخوانی Stored Procedureها

 Stored procedureها بر روی remote server به راحتی اجرا می شوند، اما server در ابتدا نیاز دارد که برای RPC تنظیم شود.برای این کار تنها به کد زیر احتیاج است:

sp_serveroption fuji_PUBS_DB, [rpc out], true

این کد تنها یکبار می بایست اجرا شود.

برای صدا کردن stored procedure ها می توان طبق همان فرمول ۴ قسمتی فراخوانی جداول عمل کرد:

exec fuji_PUBS_DB.master.dbo.sp_who2


تغییر داده هایRemote

تغییر و بروز رسانی جداول در سرور پیوندی(linked server) هم مسئله خاصی ندارد.در اینجا مثال ساده ای بر مبنای select ی که جداول authors روی سرورهای دور از هم(remote) را با هم join کرده موجود است:

UPDATE fuji_PUBS_DB.pubs.dbo.authors

SET   au_fname = r.au_fname,     au_lname = r.au_lname

from  fuji_PUBS_DB.pubs.dbo.authors r join  authors l   on l.au_id = r.au_id

where (  l.au_fname <> r.au_fname OR  l.au_lname <> r.au_lname)

با این دستور update ، نیاز به ۲ رفت و برگشت جداگانه به سرور پیوندی(linked server) است. یک گردش که داده ها را از سرور پیوندی به سرور محلی می آورد برای جایگزینی در join. دومین گردش تغییرات واقعی روی ردیف های داده ای که  sql server نیاز به اعمال تغییرات بر روی آنها دارد را اجرا می کند.

مباحث بیشتر پیرامون کارآیی

در این مثال ردیفهایی را که به آنها مشکوک بودم کنار گذاشتم ، در صورتی که اگر آنها را وارد  می کردم، کارآیی پرس و جو می توانست بهتر شود، چرا که ردیفها در نتیجه نهایی linked server فیلتر می شد و داده های کمتری در سطح شبکه جریان می یافت و کار کمتری در join انجام می شد.

شبیه تمام تراکنش های update ، بروزرسانی(update) در linked server ها هم در یک تراکنش(transaction) صورت می گیرد.پردازش تراکنش ها هم به همین منوال نسبت به پردازش در سطح local زمان بیشتری صرف می کند که به همین جهت تراکنش های توزیع شده ای به این شکل را باید با صرف دقت بیشتر ، به شکل کارآ تری طراحی کرد.در ضمن شما می توانید چندین update در یک تراکنش توزیع شده داشته باشید

 اصل مقاله:http://www.databasejournal.com/features/mssql/article.php/10894_1438991_3

نویسنده:Neil Boyle

 

ادامه دارد...

نظرات 0 + ارسال نظر
برای نمایش آواتار خود در این وبلاگ در سایت Gravatar.com ثبت نام کنید. (راهنما)
ایمیل شما بعد از ثبت نمایش داده نخواهد شد