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

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

اجرای کد T-SQL بر روی چند سرور در یک زمان!

>>محیط و زبان برنامه نویسی: MS T-SQL

آیا شما بیش از ۱۰ سرور sql جهت مدیریت دارید؟ بسیاری از DB admin ها که اینگونه اند؛ مثلا تا ۱۵۰ مورد جهت مدیریت دارند!

خیلی ها عادت دارند که ازISQL/OSQL در یک batch جهت اجرای دستورات خود بر روی تمامی موارد سرور ها استفاده کنند، که طرز کار جالبی ندارد.کد زیر جهت جمع آوری اطلاعات همه سرورهای sqlی با T-Sql و بدون استفاده از batch فایل است.

بطور اساسی این کد

1. جدولی را ایجاد می کند که منزلگاه تمامی نمونه های sql شما و کلمه عبور مربوط به کاربر 'sa' است.
2. پیوند ارتباطی ایجاد می کند.
3. کد شما را اجرا می کند.
4. پیوند ارتباطی را قطع می کند.
5. و نهایتا جدول موقتی ایجاد شده را پاک می کند.

برای اضافه کردن نمونه های بیشتر سرور sql تنها کافی است یک خط کد به قسمت "insert into" اضافه کنید.

جهت ایجاد تغییرات در کد برای هماهنگ سازی کد با محیط کار خود(sql2000 یا sql 2005 یا sql7) از راهنمای ابتدای کد استفاده کنید.

امیدوارم این قطعه کد باعث بشه که راحتتر زندگی کنید!

دانلود کد:
RemoteExec.sql

 نویسنده : Dr. Discovery

اصل مقاله:http://www.databasejournal.com/scripts/article.php/3646706

Linked Server ها(۲)

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

Logical Server Names

ممکن است شما نیاز به بیش از یک link بر روی یک سرور داشته باشید که یک نتیجه بارز آن کاهش شدید امنیت سرور است.ممکن است نیاز داشته باشید یکسری از کاربران به DB خاص و سری دیگر به  DB  دیگری دسترسی داشته باشند و هر گروه مجوز دسترسی به DB  گروه دیگر را نداشته باشند.

جهت دیدن عکس بزرگتر کلیک کنید.

کد زیر دو Logical Linked Server به یک ماشین (یکی برای دسترسی به Pubs بنام fuji_PBS_DB و در حالی که fuji_NORTHWIND_DB به NorthWind دسترسی می یابد. )میسازد

برای امتحان کد شما باید در سرور هدف(target) دو Login  بنامهای fuji_NORTHWIND و fuji_PUBS تنظیم کنید و مجوز دسترسی هر کدام برای DB  مربوط به خودشان را هم بدهید.

sp_addlinkedserver 

fuji_PBS_DB , 

droplogins @server='fuji_PUBS_DB',

@srvproduct='', 

@provider='SQLOLEDB',

@datasrc='FUJI'

go

sp_addlinkedsrvlogin 

@rmtsrvname = fuji_PUBS_DB, 

@useself = false,

@locallogin = NULL,

@rmtuser = fuji_PUBS , 

@rmtpassword = fuji_PUBS

go

sp_addlinkedserver       

fuji_PBS_DB, 

droplogins  @server='fuji_NORTHWIND_DB',

@srvproduct='',

@provider='SQLOLEDB',

@datasrc='FUJI'

go

sp_addlinkedsrvlogin 

@rmtsrvname = fuji_NORTHWIND_DB,

@useself = false,

@locallogin = NULL,

@rmtuser = fuji_NORTHWIND,

@rmtpassword = fuji_NORTHWIND

go

 حالا ما می توانیم مثال ساده خود را جهت نشان دادن تفاوت بین دو سرور اجرا کنیم:

select * from openquery (fuji_PUBS_DB, 'select @@serverName, user_name(), db_name(), @@spid')

 select * from openquery (fuji_NORTHWIND_DB, 'select @@serverName, user_name(), db_name(), @@spid')

یک نکته امنیتی 
اینکه چون ما 2 Login درست کرده و کاربران خود را از طریق آن دو به linked server متصل کرده ایم ، هر کاربری که به 
سرور محلی وصل شود قادر است به سرورremote هم وصل شود.  پس کافی است که کاربر بداند که امکان دسترسی به linked server  
را نیز دارد. آنچه مسلم است ابتدا باید کاربران گروهبندی شده و فقط آنها که نیاز به linked server دارند بتوانند به آن وصل شوند، که این 
هم راه حل مطلوب نیست و حتی الامکان سعی شود که برای هر کاربر login مختص به خود او روی linked server ایجاد گردد.
 
 
نکته امنیتی دیگر
بر طبق اصول در حالی که امنیت کافی برای سرورتان برقرار نکرده اید، آن را برای استفاده دیگران باز نگذارید. امکان کار کردن مستقیم کاربر 
با سرور را ندهید، بسته های مورد نیاز کاربر را در غالب procedureها ، Functionها و یا کدهای سمت سرویس گیرنده تهیه کنید و به وی 
مجوز کار با آنها را بدهید و کارش را کنترل کنید.کابران تنها به داده های خود را نیاز دارند، آنها کاری ندارند که داده ها چگونه می آیند.
استفاده از linked server
بعد از این تنظیمات ما چه کاری با آنها می توانیم انجام دهیم؟اجازه دهید به مثالهایی نگاه بیاندازیم:
مدل ابتدایی دسترسی به داده های  remote را پیشتر دیدیم:
 
Select * from openquery (server, 'your query here') --basic syntax
 
این دستور موجب می شود که SQL Server یک ارتباط با سرور هدف  ایجاد کند؛ به آن Login کند؛ query مورد نظر شما را اجرا کند؛
داده ها را به سروری که شما با آن کار می کنید برگرداند و در آخر ارتباط را قطع کند.
 
این query دقیقا همان عمل را انجام می دهد اما به شکل شسته و رفته و بسیار آسانتر جهت استفاده:
 
select * from fuji_PUBS_DB.pubs.dbo.authors
 
با این ترکیب ساده براحتی می توانیم joinهایی بر روی سرورهای مختلف داشته باشیم. مثلا در حالی که تغییراتی در نام نویسندگان در 
جدول authors از بانکPubs ، در remote server اعمال کرده ایم ، با query ساده زیر می توانیم از ردیفهای تغییر یافته مطلع شویم:
 
select r.au_fname as remote_fname,  r.au_lname as remote_lname,  l.*
from authors l  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
 
 
 
...ادامه دارد