مطالب
اس کیوال سرور 2008 و عملگرهای C مانند

اگر با زبان C و مشتقات آن آشنایی داشته باشید، حتما با عملگرهای ترکیبی آن‌ها که جهت خلاصه نویسی بکار می‌روند، نیز کار کرده‌اید. برای مثال:

int i =5;
i += 15; // i = i + 15;

اس کیوال سرور 2008 نیز از اینگونه عملگرها پشتیبانی به عمل می‌آورد. برای نمونه:
DECLARE @x1 int = 27;
SET @x1 += 2 ;
SELECT @x1 AS Added_2;
در دستورات T-SQL فوق دو نکته قابل توجه است:
الف) امکان تعریف و مقدار دهی همزمان یک متغیر (مقدار دهی همزمان با تعریف، تا قبل از اس کیوال سرور 2008 پشتیبانی نمی‌شد)
ب) امکان استفاده از عملگرهای C مانند در عبارات T-SQL

لیست این عملگرهای جدید به شرح زیر است:
+= (Add EQUALS) (Transact-SQL)
-= (Subtract EQUALS) (Transact-SQL)
*= (Multiply EQUALS) (Transact-SQL)
/= (Divide EQUALS) (Transact-SQL)
%= (Modulo EQUALS) (Transact-SQL)
&= (Bitwise AND EQUALS) (Transact-SQL)
^= (Bitwise Exclusive OR EQUALS) (Transact-SQL)
|= (Bitwise OR EQUALS) (Transact-SQL)

مطالب
نگهداری ایندکس‌ها در اس‌کیوال سرور

پس از مدتی که از شروع به کار یک سیستم می‌گذرد، همانطور که تعریف ایندکس‌های مفید سرعت جستجوها را بالا می‌برد، ایجاد fragmentation در آن‌ها نیز تاثیر منفی در کارآیی خواهد داشت. به همین منظور نیاز است هر از چندگاهی بررسی شود میزان fragmentation ایندکس‌ها چقدر است. اگر این میزان بیش از 30 درصد بود توصیه شده است که از دستور DBCC INDEXDEFRAG استفاده شود یا بازسازی مجدد ( rebuild ) ایندکس‌ها صورت گیرد.

یکی دیگر از امکانات dmv های اس کیوال سرورهای 2005 به بعد، ارائه آمار میزان fragmentation ایندکس‌ها است که کوئری آن به صورت زیر می‌تواند باشد:

USE dbName;
SELECT OBJECT_NAME(DMV.object_id) AS TABLE_NAME,
SI.NAME AS INDEX_NAME,
avg_fragmentation_in_percent AS FRAGMENT_PERCENT,
DMV.record_count
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'SAMPLED') AS
DMV
LEFT OUTER JOIN SYS.INDEXES AS SI
ON DMV.OBJECT_ID = SI.OBJECT_ID
AND DMV.INDEX_ID = SI.INDEX_ID
WHERE avg_fragmentation_in_percent > 10
AND index_type_desc IN ('CLUSTERED INDEX', 'NONCLUSTERED INDEX')
AND DMV.record_count >= 2000
ORDER BY
TABLE_NAME DESC

باید در نظر داشت که اجرای این کوئری بر روی یک دیتابیس حجیم زمان‌بر بوده و احتمالا عملکرد سیستم را تحت تاثیر قرار می‌دهد. بنابراین استفاده از آن در خارج از ساعات کاری باید مد نظر باشد. بازسازی ایندکس‌ها نیز به همین صورت است.

برای بازسازی تمامی ایندکس‌های یک دیتابیس مفروض می‌توان از کوئری زیر استفاده کرد:

DECLARE @TableName VARCHAR(255)
DECLARE @sql NVARCHAR(500)
DECLARE @fillfactor INT
SET @fillfactor = 80
DECLARE TableCursor CURSOR
FOR
SELECT OBJECT_SCHEMA_NAME([object_id]) + '.' + NAME AS TableName
FROM sys.tables

OPEN TableCursor
FETCH NEXT FROM TableCursor INTO @TableName
WHILE @@FETCH_STATUS = 0
BEGIN
SET @sql = 'ALTER INDEX ALL ON ' + @TableName +
' REBUILD WITH (FILLFACTOR = ' + CONVERT(VARCHAR(3), @fillfactor) + ')'

EXEC (@sql)
FETCH NEXT FROM TableCursor INTO @TableName
END
CLOSE TableCursor
DEALLOCATE TableCursor

مطالب
تعیین اعتبار کردن یک عبارت SQL

سؤال: چگونه می‌توان یک کوئری را تعیین اعتبار کرد بدون اینکه نتیجه‌ی اجرای آن برای ما اهمیتی داشته باشد یا دیتابیس را به هم بریزد؟

روش انجام این‌کار در اس کیوال سرور به صورت زیر است:

SET NOEXEC ON
GO
عبارات اس کیوال ما در اینجا قرار خواهند گرفت
GO
SET NOEXEC OFF
GO
مطابق راهنمای اس کیوال سرور، SET NOEXEC سبب کامپایل کوئری‌های پس از آن شده ولی آن‌ها‌را اجرا نخواهد کرد. همچنین SET PARSEONLY ON فقط syntax یک کوئری را بررسی کرده و خطاهای حاصل را نمایش می‌دهد (بدون اجرا کوئری، بدون کامپایل آن).

مطالب
آیا از وضعیت رویه‌های ذخیره شده‌ی دیتابیس‌های اس کیوال سرور خود خبر دارید؟

به لطف امکانات سیستمی اس کیوال سرورهای 2005 به بعد و DMV های آن‌ها، آمارگیری از ریز اتفاقات رخ داده در یک اس کیوال سرور این روزها بسیار ساده شده است و نیازی به ابزارهای جانبی برای انجام این نوع عملیات نیست (یا کمتر هست). در ادامه مروری خواهیم داشت بر یک سری کوئری که اطلاعات جالبی را در مورد وضعیت رویه‌های ذخیره شده‌ی دیتابیس‌های شما ارائه می‌دهند. لازم به ذکر است که اکثر این آمارها با هر بار ری استارت سرور، صفر خواهند شد.

آیا می‌دانید در یک دیتابیس خاص کدامیک از رویه‌های ذخیره شده‌ی شما بیش از سایرین مورد استفاده بود و آماری از این دست؟

use dbName;
SELECT TOP(100) qt.text AS 'SP Name',
qs.execution_count AS 'Execution Count',
qs.execution_count / DATEDIFF(Second, qs.creation_time, GETDATE()) AS
'Calls/Second',
qs.total_worker_time / qs.execution_count AS 'AvgWorkerTime',
qs.total_worker_time AS 'TotalWorkerTime',
qs.total_elapsed_time / qs.execution_count AS 'AvgElapsedTime',
qs.max_logical_reads,
qs.max_logical_writes,
qs.total_physical_reads,
DATEDIFF(Minute, qs.creation_time, GETDATE()) AS 'Age in Cache'
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS qt
WHERE qt.dbid = DB_ID() -- Filter by current database
ORDER BY
qs.execution_count DESC

البته مرتب سازی پیش فرض این کوئری بر اساس تعداد بار اجرا است (رویه‌های ذخیره شده‌ی محبوب!)، می‌شود آن‌را بر اساس total_worker_time (فشار بر روی CPU سیستم)، total_logical_reads (فشار بر روی حافظه)، total_physical_reads (فشار I/O کوئری‌ها)، total_logical_writes نیز مرتب کرد و نتایج جالب توجهی را بدست آورد.


آیا می‌دانید کدامیک از رویه‌های ذخیره شده‌ی شما بیش از سایرین کامپایل مجدد شده است؟

select top 50
sql_text.text,
sql_handle,
plan_generation_num,
execution_count,
dbid,
objectid
from
sys.dm_exec_query_stats a
cross apply sys.dm_exec_sql_text(sql_handle) as sql_text
where
plan_generation_num >1
order by plan_generation_num desc

آیا می‌دانید آخرین باری که رویه‌های ذخیره شده‌ی شما ویرایش شده‌اند چه زمانی بوده است؟

SELECT NAME,
create_date,
modify_date
FROM sys.objects
WHERE TYPE = 'P'
ORDER BY
Modify_Date DESC,
NAME

مطالب
چرا نباید از کوئری‌های select * استفاده کرد؟

عموما اولین پاسخی که به این سؤال داده می‌شود این است که این نوع کوئری‌ها اطلاعات زیادی را باز می‌گردانند و در نتیجه ترافیک شبکه بی‌جهت افزایش خواهد یافت. اما اگر طراحی دیتابیس صحیح بوده و اصول نرمال سازی در آن پیاده سازی شده باشد، این پاسخ آنچنان صادق نخواهد بود (زیرا جداول اینگونه دیتابیس‌ها از تعداد فیلدهای بسیاری تشکیل نخواهند شد). برای مثال به نتیجه اجرای کوئری‌های زیر بر روی دیتابیس AdventureWorks با 89 هزار رکورد، دقت بفرمائید:
SELECT * FROM Production.TransactionHistoryArchive
WHERE ReferenceOrderID < 100

SELECT ReferenceOrderLineID FROM Production.TransactionHistoryArchive
WHERE ReferenceOrderID < 100

اختلاف ترافیک شبکه در این مثال تنها 15K یا حدودا 10 درصد است (180K در مقابل 165K). هر چند ارزش بررسی و برطرف کردن را دارد اما تفاوت حاصل آنچنان قابل ملاحظه نیست.
مهم‌ترین دلیلی که اینجا باید به آن دقت داشت، تفاوت چشمگیر execution plan این دو کوئری (Ctrl-L) و بحث index coverage است. اس کیوال سرور برای اجرای بهینه کوئری‌ها از ایندکس‌های موجود استفاده خواهد کرد. اگر ایندکس تعریف شده از تمامی فیلدهای درخواستی شما تشکیل شده باشد، دیگر حتی به سراغ جدول هم نخواهد رفت (به این مفهوم، پوشش ایندکسی گفته می‌شود).



برای تولید تصویر فوق، کلیدهای Ctrl+L را در management studio فشار دهید.
این دیتابیس را از آدرس زیر می‌توانید دریافت کنید:
http://www.codeplex.com/MSFTDBProdSamples

کوئری اول از مزایای پوشش ایندکسی برخودار نخواهد بود (از روش جستجوی Clustered Index استفاده می‌کند) و در حالت دوم از Index Seek استفاده می‌گردد. حالت Index Seek یک‌صد بار بهینه‌تر از استفاده از Clustered Index عمل می‌کند زیرا در حالت کوئری اول باید تمامی رکوردهای جدول بررسی شوند (این عدد از مقایسه نتایج execution plan بدست آمده است).
تنها در صورتیکه بر روی تمامی فیلدهای جدول ایندکس تعریف کرده باشید (که اصلا توصیه نمی‌شود)، کوئری اول توسط ایندکس‌ها پوشش داده شده و سریع اجرا خواهد شد.
بنابراین اگر از کندی اجرای کوئری‌ها با تعداد رکورد بالا شکایت دارید بهتر است نگاهی به نحوه تعریف آنها داشته باشید و تنها فیلدهایی را در کوئری تعریف کنید که به آنها نیاز دارید. در این حالت از مزایای پوشش ایندکسی برخودار شده ، کوئری‌های سریعتری را خواهید داشت و همچنین در این حالت میزان مصرف CPU و حافظه نیز بر روی سرور کمتر خواهد بود.
همچنین در حالت کوئری‌هایی از نوع دوم ذکر شده، موتور بهینه ساز اس کیوال سرور پیشنهادات بهتری را برای ایجاد ایندکس‌های جدید و گوشزد نمودن کمبود آنها با ارائه included columns مناسب، ارائه می‌دهد.
بعلاوه مشخص ساختن تعداد دقیق فیلدهای مورد نیاز، نگهداری برنامه را ساده‌تر ساخته و فیلدهای اضافه شده آتی سبب تغییر رفتار کوئری‌ها برنامه نخواهند شد و استفاده نکردن از آن نشانه این است که هیچ برآوردی از ابعاد واقعی کار در دست نیست.

مآخذ:
Speed Up Your Site! 8 ASP.NET Performance Tips
The real reason SELECT * queries are bad: index coverage


مطالب
LocalDB چیست؟

LocalDB نسخه‌ای جدید از Sql server express است که به توسعه دهندگان این اجازه را می‌دهد تا با نصب آن، از نصب کامل دیگر نسخه‌های Sql server جلوگیری نمایند. LocalDB برای برنامه‌هایی که به صورت Local و بر روی یک سیستم اجرا می‌شوند مورد استفاده قرار می‌گیرد. 

مزایای استفاده از این نسخه

  • فایل نصب با حجم بسیار کم. (28.2MB برای نسخه 32 بیتی و 33.7MB برای نسخه 64بیتی)
  • سادگی ( بدون نیاز به انجام تنظیمات خاص بر روی سیستم)
  • اجرا در محیطهایی که کاربر جاری دسترسی مدیریتی ندارد.(برای اجرای آن نیاز به Permissionهای مدیریتی نیست و یک کاربر سطح پایین هم می‌تواند آن را اجرا کند)
  • سادگی نصب
  • همانند Sql server Express سازگاری کاملی با T-Sql دارد. همچنین از Stored Procedureها ، داده‌های جغرافیایی و مکانی ( geometry and geography ها) ، Triggers و View‌ها پشتیبانی می‌کند.
  • سازگاری با Provider معمولی Sql server
  • عدم اجرای سرویس خاصی در حافظه برای مدیریت دیتابیس. پروسس‌های LocalDb هر زمان که نیاز باشد اجرا می‌شوند و هر زمان که به آنها نیاز نداشته باشیم به صورت اتوماتیک متوقف می‌شوند.
  • پشتیبانی از خصوصیت AttachDbFileName  در کانکشن استرینگ جهت استفاده از فایل بانک اطلاعات به صورت مستقیم
  • سرویس پک‌های جدید جهت LocalDB به راحتی برروی نسخه موجود نصب میشوند و نسخه قبلی را به روز رسانی میکنند.
  • نصب یک LocalDB برای همه کاربران یک کامپیوتر
  • پشتیبانی کامل از Silent Installation
  • امکان استفاده از آن توسط Asp.net
  • پشتیبانی از XML (XQuery و XPath) و BLOB
  • پشتیبانی از Ado.net sync framework
  • پشتیبانی از LINQ
  • پشتیبانی از Distributed transactions
  • کانکشن‌های نامحدود (البته به صورت Local)
 
 نیازمندی‌های نصب
  • نیاز به نصب Sql server 2012 native client . این مورد به همراه LocalDB روی سیستم نصب نمیشود
  • نیاز به دسترسی مدیریتی جهت نصب 
  • 140MB فضای خالی دیسک سخت
  • به روز رسانی دات نت فریم ورک 4 به 4.0.2 و یا نسخه‌های بالاتر
محدودیت ها
  • عدم پشتیبانی از Windows xp ، Window server 2003 و Windows 2000
  • عدم امکان نصب نسخه 32 بیتی بر روی ویندوز 64 بیتی (حتما باید نسخه 64 بیتی آن را نصب کنید)
  • فقط می‌توان به صورت Local از آن استفاده کرد. امکان استفاده تحت شبکه وجود ندارد و  فقط به کانکشن‌های Local پاسخ می‌دهد.
  • فقط توسط Sql server 2012 management studio در دسترس می‌باشد. LocalDB را نمی‌توان از طریق Management studio‌های قدیمی مدیریت کرد.
  • عدم پشتیبانی Visual Studio 2010 از LocalDB
  • عدم اجرا بر روی موبایل‌های هوشمند
  • محدودیت سایز بانک اطلاعات :  10GB
  • عدم پشتیبانی از قابلیت FileStream
  • محدودیت استفاده از فقط یک CPU
  • عدم امکان Debuging دستورات Sql در هنگام اتصال به LocalDB
 نحوه نصب
ابتدا Sql server LocalDB را دانلود نمایید. سپس برای نصب آن بر روی سیستم فقط کافی است که فایل نصاب برنامه را اجرا نموده و License مربوطه را قبول نمایید.همچنین در صورت نیاز به Silent Installation کافی است که از دستور زیر در خط فرمان استفاده نمایید: 
 msiexec /i SqlLocalDB.msi /qn IACCEPTSQLLOCALDBLICENSETERMS=YES
همچنین می‌توانید مراحل نصب را توسط فایل نصاب انجام دهید: 


نحوه اتصال به LocalDB توسط Sql Server Management Studio 

اگر net framework. خود را از نسخه 4 به 4.0.2 و یا نسخه‌های بعد از آن به روز رسانی کرده باشید می‌توان توسط Sql Server 2012 Management Studio به Sql server LocalDB وصل شد. عبارت local)\v11.0) را به عنوان نام سرور وارد نمایید.

مجددا لازم به ذکر است که امکان اتصال توسط Management Studio‌های قبلی به بانک LocalDB امکان پذیر نمی‌باشد. 


برای مطالعه بیشتر

اشتراک‌ها
نگاهی به Docker ها در ویندوز سرور 2016
With the release of Technical Preview 3 (TP3) for Windows Server 2016, Microsoft for the first time have enabled native Containers under the Windows platform. Integrated with this is the Docker support for Windows Server, meaning you can run Docker containers in a Windows environment 
نگاهی به Docker ها در ویندوز سرور 2016