مطالب
چرا نباید از کوئری‌های 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


اشتراک‌ها
انتشار Visual Studio 2022 version 17.6 Preview 1

GitHub Issues

The GitHub Issues integration allows you to search and reference your issues from the commit message box in VS, in response to this suggestion ticket. You can reference an issue or a pull request by typing # or clicking on the # button in the lower right side of the commit message text box. If you weren't already authenticated to access related issues, you will now be prompted to sign in to take advantage of this feature.

Line Unstaging

To continue improving our line-staging (aka interactive staging) feature, we've added unstage. You can now use the tool tip option to unstage changes, line by line, as requested here Unstage individual lines and hunks in a file - 4 votes

Arm64

We continue to build native support for Arm64 on Windows 11 for the most popular developer scenarios. We now support the .NET Multi-platform App UI (MAUI) workload on Arm64 Visual Studio.

C++

  • Available as a preview feature, you can now view Unreal Engine logs without leaving VS. To see the logs from the Unreal Engine Editor, click View > Other Windows > UE Log. To filter your logs, click on the "Categories" or "Verbosity" dropdowns. Since this is an experimental feature, feedback is greatly appreciated.
  • You can now import STM32CubeIDE projects for embedded development within Visual Studio with File > Open > Import STM32CubeIDE project. This generates a CMake project with device flashing and debugging settings for STLink. You must have the STM32CubeIDE installed with the board support package for your device. More details available here.
  • You can use the new CMake Debugger to debug your CMake scripts at build time. You can set breakpoints based on filenames, line numbers, and when CMake errors are triggered. Additionally, you can view call stacks of filenames and watch defined variables. Currently, this only works with bundled CMake, and projects targeting WSL or remote machines are not supported yet. We are actively working to add more support to the CMake debugger, and feedback is greatly appreciated. 
انتشار Visual Studio 2022 version 17.6 Preview 1
نظرات مطالب
سیلورلایت 5 و تاریخ شمسی
سلام جناب نصیری
من تو پروژه سیلور از OData استفاده کردم. وقتی می خواستم Max یک ستون رو برگردونم با پیغام زیر مواجه شدم.
.NotSupportedException: The method 'Max' is not supported
ظاهرا بعضی از متدها موقع کوئری نوشتن (LINQ to Entities) با OData و WCF سازگار نیستن و ساپورت نمیشوند.(البته تا جایی که من سرچ کردم و یه چیزایی فهمیدم).
This topic provides information about the way in which LINQ queries are composed and executed when you are using the WCF Data Services client and limitations of using LINQ to query a data service that implements the Open Data Protocol (OData). For more information about composing and executing queries against an OData-based data service, see Querying the Data Service (WCF Data Services).
Composing LINQ Queries
LINQ enables you to compose queries against a collection of objects that implements IEnumerable. Both the Add Service Reference dialog box in Visual Studio and the DataSvcUtil.exe tool are used to generate a representation of an OData service as an entity container class that inherits from DataServiceContext, as well as objects that represent the entities returned in feeds. These tools also generate properties on the entity container class for the collections that are exposed as feeds by the service. Each of these properties of the class that encapsulates the data service return a DataServiceQuery. Because the DataServiceQuery class implements the IQueryable interface defined by LINQ, the WCF Data Services you can compose a LINQ query against feeds exposed by the data service, which are translated by the client library into a query request URI that is sent to the data service on execution.
 Note:
The set of queries expressible in the LINQ syntax is broader than those enabled in the URI syntax that is used by OData data services. A NotSupportedException is raised when the query cannot be mapped to a URI in the target data service. For more information, see the Unsupported LINQ Methods in this topic.
لطفا اگر امکانش هست راهنمائی بفرمائید و اینکه حالا که ساپورت نمیشه چه راه حلی وجود داره برای Max گرفتن.
با تشکر

نظرات مطالب
مزیت‌های استفاده از رویه‌های ذخیره شده؛ واقعیت یا توهم؟!
مرسی از مطلبتون،
منظورتون از کوئری‌های Ad Hoc کوئری‌هایی ست که در زمان اجرا ساخته می‌شوند یا در سمت کلاینت قرار دارند هست؟ یا تعریف دیگری دارد؟
در مورد نکته‌ی دوم من این مطلب رو جایی خوندم که کوئری‌های Ad Hoc هر بار کامپایل میشن و Exec Plan شون بدست میاد و.... البته اون مطلب در مورد SQL Server 2000 بود.
مطالب
بهبود کارآیی برنامه‌های قدیمی که از SQL Server استفاده می‌کنند
برنامه‌های قدیمی، الزاما خیلی قدیمی هم نیستند؛ برنامه‌هایی هستند پر از کوئری‌های ذیل:
 SELECT * FROM table1 WHERE OrderDate ='12 Mar 2004'

SET @SQL = 'SELECT * FROM table2 WHERE OrderDate = ' + '''' + @Var + ''''
EXEC (@SQL)
ویژگی مهم این نوع کوئری‌ها که با جمع زدن رشته‌ها و یا مقدار دهی مستقیم فیلدها تشکیل شده‌اند، «غیر پارامتری» بودن آ‌ن‌ها است.
این نوع مشکلات با بکار گیری ORMها به نحو قابل توجهی کاهش یافته‌است؛ زیرا این نوع واسط‌ها در اغلب موارد، در آخر کار کوئری‌هایی پارامتری را تولید می‌کنند.


مشکل کوئری‌های غیر پارامتری چیست؟

استفاده‌ی وسیع از کوئری‌های غیرپارامتری با SQL Server، مشکلی را پدید می‌آورد به نام «Cache bloat» یا «کش پُف کرده» و این «پُف» به این معنا است که کش کوئری‌های اجرا شده‌ی بر روی SQL Server بیش از اندازه با Query plan‌های مختلف حاصل از بررسی نحوه‌ی اجرای بهینه‌ی آن‌ها پر شده‌است. هر کوئری که به SQL Server می‌رسد، جهت اجرای بهینه، ابتدا پردازش می‌شود و دستور العملی خاص آن، تهیه و سپس در حافظه کش می‌شود. وجود این کش به این خاطر است که SQL Server هربار به ازای هر کوئری رسیده، این عملیات پردازشی را تکرار نکند. مشکل از زمانی شروع می‌شود که SQL Server کوئری‌هایی را که از نظر یک برنامه نویس مانند هم هستند را به علت عدم استفاده‌ی از پارامترها، یکسان تشخیص نداده و برای هر کدام یک Plan جداگانه را محاسبه و کش می‌کند. این مساله با حجم بالای کوئری‌های رسیده دو مشکل را ایجاد می‌کند:
الف) مصرف حافظه‌ی بالای SQL Server که گاهی اوقات این حافظه‌ی اختصاص داده شده‌ی به کش کوئری‌ها به بالای یک گیگابایت نیز می‌رسد.
ب) CPU Usage بالای سیستم


سیستم قدیمی است؛ امکان تغییر کدها را نداریم.

بدیهی است بهترین راه حلی که در اینجا وجود دارد، پارامتری ارسال کردن کوئری‌ها به SQL Server است تا به ازای هر تغییری در مقادیر آن‌ها، این کوئری‌ها باز هم یکسان به نظر برسند و SQL Server سعی در محاسبه‌ی مجدد Plan آن‌ها نکند. اما ... اگر این امکان را ندارید، خود SQL Server یک چنین قابلیت‌هایی را به صورت توکار تدارک دیده‌است که باید فعال شوند.


فعال سازی پارامتری کردن خودکار کوئری‌ها در SQL Server

اگر نمی‌توانید کدهای یک سیستم قدیمی را تغییر دهید، SQL Server می‌تواند به صورت خودکار این‌کار را برای شما انجام دهد. در این حالت فقط کافی است یکی از دو دستور ذیل را اجرا کنید:
  --Forced
ALTER DATABASE dbName SET PARAMETERIZATION FORCED

--Simple
ALTER DATABASE dbName SET PARAMETERIZATION SIMPLE
حالت simple بیشتر جهت پارامتری کردن خودکار کوئری‌های select بکار می‌رود. اگر می‌خواهید تمام کوئری‌های select, insert, update و delete را نیز پارامتری کنید، باید از حالت forced استفاده نمائید.



فعال سازی بهبود کارآیی SQL Server با کوئری‌های Ad-Hoc زیاد

به کوئری‌های غیرپارامتری، کوئری‌های Ad-Hoc نیز گفته می‌شود. اگر سیستم فعلی شما، تعداد زیادی کوئری Ad-Hoc تولید می‌کند، می‌توان فشار کاری SQL Server را برای این مورد خاص، تنظیم و بهینه سازی کرد.
فعال سازی گزینه‌ی ویژه‌ی «Optimize for Ad hoc Workloads» سبب می‌شود تا SQL Server پس از مدتی به صورت خودکار کش Plan کوئری‌هایی را که به ندرت استفاده می‌شوند، حذف کند. همین مساله سبب آزاد شدن حافظه و بهبود کارآیی کلی سیستم می‌گردد. همچنین باید درنظر داشت که کش Plan کوئری‌ها نامحدود نیست و سقفی دارد. به همین جهت آزاد شدن آن، کش کردن کوئری‌هایی را که بیشتر استفاده می‌شوند، ساده‌تر می‌کند.
برای اعمال آن به یک بانک اطلاعاتی خاص، نیاز است دستورات ذیل را اجرا کرد:
 use dbName;
-- Optimizing for Ad hoc Workloads
exec sp_configure 'show advanced options',1;
RECONFIGURE;
go
exec sp_configure 'optimize for ad hoc workloads',1;
RECONFIGURE;
Go


برای مطالعه‌ی بیشتر
Fixing Cache Bloat Problems With Guide Plans and Forced Parameterization
Optimizing ad-hoc workloads
Optimizing for Ad hoc Workloads
اشتراک‌ها
از کند شدن Entity Framework دوری کنید
Generally speaking, I don't worry much about tweaking my LINQ queries when working with Entity Framework (this is also true when I'm working with SQL directly, by the way). I'm always telling my clients that if they want to speed up their data access they should look at their database design and, especially, how they're using indexes.
از کند شدن Entity Framework دوری کنید
اشتراک‌ها
مستند سازی Database

dbdescis a powerful tool to help you document your databases. It can produce detailed documents describing your databases

Currently dbdesc supports the following databases:
SQL Server 2000, 2005, 2008, 2008 R2, 2012, 2014
Microsoft Desktop Engine 2000 (MSDE) and SQL Server Express editions
MySQL 5.0
Oracle 9 and above
Microsoft Access 97 and above
Firebird 

با استفاده از کوئری زیر نیز می‌توانید نام و Description ستون‌ها و دیتاتایپ و ... آنها را بدست آورید.


 SELECT p.name
 ,p.value
 ,t.name AS TableName
 ,c.name AS ColumnName
 ,c.is_nullable
 ,c.max_length
 ,TYPE_NAME(c.system_type_id)
FROM sys.tables t
JOIN sys.columns c
ON t.object_id = c.object_id
LEFT JOIN sys.extended_properties p
ON p.major_id = t.object_id
AND p.minor_id = c.column_id
ORDER BY t.name DESC,c.name DESC

جهت بررسی بیشتر و آشنایی با Extended Properties in SQL Server به لینک Towards the Self-Documenting SQL Server Database  مراجعه کنید.

مستند سازی Database