SQLZOO؛ سایتی برای فراگیری SQL
- LocalDb نیاز دارد که پروفایل کاربر بارگذاری شده باشد
- بصورت پیش فرض وهله LocalDb متعلق به یک کاربر بوده، و خصوصی است
در قسمت قبل دیدیم چگونه باید پروفایل کاربر را بدرستی بارگذاری کنیم. در این مقاله به مالکیت وهلهها (instance ownership) میپردازیم.
مشکل وهله خصوصی
در پایان قسمت قبلی، اپلیکیشن وب را در این حالت رها کردیم:
همانطور که مشاهده میکنید با خطای زیر مواجه هستیم:
System.Data.SqlClient.SqlException: Cannot open database "OldFashionedDB" requested by the login. The login failed.
Login failed for user 'IIS APPPOOL\ASP.NET v4.0'.
این بار پیغام خطا واضح و روشن است. LocalDb با موفقیت اجرا شده و اپلیکیشن وب هم توانسته به آن وصل شود، اما این کانکشن سپس قطع شده چرا که دسترسی به وهله جاری وجود نداشته است. اکانت ApplicationPoolIdentity (در اینجا IIS APPPOOL\ASP.NET v4.0) نتوانسته به دیتابیس LocalDb وارد شود، چرا که دیتابیس مورد نظر در رشته اتصال اپلیکیشن (OldFashionedDB) وجود ندارد. عجیب است، چرا که وصل شدن به همین دیتابیس با رشته اتصال جاری در ویژوال استودیو با موفقیت انجام میشود.
همانطور که در تصویر بالا مشاهده میکنید از ابزار SQL Server Object Explorer استفاده شده است. این ابزار توسط SQL Server Data Tools معرفی شد و در نسخههای بعدی ویژوال استودیو هم وجود دارد و توسعه یافته است. چطور ممکن است ویژوال استودیو براحتی بتواند به دیتابیس وصل شود، اما اپلیکیشن وب ما با همان رشته اتصال نمیتواند دیتابیس را باز کند؟ در هر دو صورت رشته اتصال ما بدین شکل است:
Data Source=(localdb)\v11.0;Initial Catalog=OldFashionedDB;Integrated Security=True
پاسخ این است که در اینجا، دو وهله از LocalDb وجود دارد. بر خلاف وهلههای SQL Server Express که بعنوان سرویسهای ویندوزی اجرا میشوند، وهلههای LocalDb بصورت پروسسهای کاربری (user processes) اجرا میشوند. هنگامی که کاربران مختلفی سعی میکنند به LocalDb متصل شوند، برای هر کدام از آنها پروسسهای مجزایی اجرا خواهد شد. هنگامی که در ویژوال استودیو به localdb)\v11.0) وصل میشویم، وهله ای از LocalDb ساخته شده و در حساب کاربری ویندوز جاری اجرا میشود. اما هنگامی که اپلیکیشن وب ما در IIS میخواهد به همین دیتابیس وصل شود، وهله دیگری ساخته شده و در ApplicationPoolIdentity اجرا میشود. گرچه ویژوال استودیو و اپلیکیشن ما هر دو از یک رشته اتصال استفاده میکنند، اما در عمل هر کدام به وهلههای متفاوتی از LocalDb دسترسی پیدا خواهند کرد. پس مسلما دیتابیسی که توسط وهله ای در ویژوال استودیو ساخته شده است، برای اپلیکیشن وب ما در IIS در دسترس نخواهد بود.
یک مقایسه خوب از این وضعیت، پوشه My Documents در ویندوز است. فرض کنید در ویژوال استودیو کدی بنویسیم که در این پوشه یک فایل جدید میسازد. حال اگر با حساب کاربری دیگری وارد ویندوز شویم و به پوشه My Documents برویم این فایل را نخواهیم یافت. چرا که پوشه My Documents برای هر کاربر متفاوت است. بهمین شکل، وهلههای LocalDb برای هر کاربر متفاوت است و به پروسسها و دیتابیسهای مختلفی اشاره میکنند.
به همین دلیل است که اپلیکیشن وب ما میتواند بدون هیچ مشکلی روی IIS Express اجرا شود و دیتابیس را باز کند. چرا که IIS Express درست مانند LocalDb یک پروسس کاربری است. IIS Express توسط ویژوال استودیو راه اندازی میشود و روی حساب کاربری جاری اجرا میگردد، پس پروسس آن با پروسس خود ویژوال استودیو یکسان خواهد بود و هر دو زیر یک اکانت کاربری اجرا خواهند شد.
راه حل ها
درک ماهیت مشکل جاری، راه حالهای مختلفی را برای رفع آن بدست میدهد. از آنجا که هر راه حل مزایا و معایب خود را دارد، بجای معرفی یک راه حال واحد چند راهکار را بررسی میکنیم.
رویکرد 1: اجرای IIS روی کاربر جاری ویندوز
اگر مشکل، حسابهای کاربری مختلف است، چرا خود IIS را روی کاربر جاری اجرا نکنیم؟ در این صورت ویژوال استودیو و اپلیکیشن ما هر دو به یک وهله از LocalDb وصل خواهند شد و همه چیز بدرستی کار خواهد کرد. ایجاد تغییرات لازم نسبتا ساده است. IIS را اجرا کنید و Application Pool مناسب را انتخاب کنید، یعنی همان گزینه که برای اپلیکیشن شما استفاده میشود.
قسمت Advanced Settings را باز کنید:
روی دکمه سه نقطه کنار خاصیت Identity کلیک کنید تا پنجره Application Pool Identity باز شود:
در این قسمت میتوانید از حساب کاربری جاری استفاده کنید. روی دکمه Set کلیک کنید و نام کاربری و رمز عبور خود را وارد نمایید. حال اگر اپلیکیشن را مجددا اجرا کنید، همه چیز باید بدرستی اجرا شود.
خوب، معایب این رویکرد چیست؟ مسلما اجرای اپلیکیشن وب روی اکانت کاربری جاری، ریسکهای امنیتی متعددی را معرفی میکند. اگر کسی بتواند اپلیکیشن وب ما را هک کند، به تمام منابع سیستم که اکانت کاربری جاری به آنها دسترسی دارد، دسترسی خواهد داشت. اما اجرای اپلیکیشن مورد نظر روی ApplicationPoolIdentity امنیت بیشتری را ارائه میکند، چرا که اکانتهای ApplicationPoolIdentity دسترسی بسیار محدودتری به منابع سیستم محلی دارند. بنابراین استفاده از این روش بطور کلی توصیه نمیشود، اما در سناریوهای خاصی با در نظر داشتن ریسکهای امنیتی میتواند رویکرد خوبی باشد.
رویکرد 2: استفاده از وهله مشترک
یک راه حال دیگر استفاده از قابلیت instance sharing است. این قابلیت به ما این امکان را میدهد تا یک وهله LocalDb را بین کاربران یک سیستم به اشتراک بگذاریم. وهله به اشتراک گذاشته شده، توسط یک نام عمومی (public name) قابل دسترسی خواهد بود.
سادهترین راه برای به اشتراک گذاشتن وهلههای LocalDb استفاده از ابزار SqlLocalDB.exe است. بدین منظور Command Prompt را بعنوان مدیر سیستم باز کنید و فرمان زیر را اجرا نمایید:
sqllocaldb share v11.0 IIS_DB
Data Source=(localdb)\.\IIS_DB;Initial Catalog=OldFashionedDB;Integrated Security=True
پیش از آنکه اپلیکیشن وب ما بتواند به این وهله متصل شود، باید لاگینهای مورد نیاز برای ApplicationPoolIdentity را ایجاد کنیم. راه اندازی وهله ساده است، کافی است دیتابیس را در SQL Server Object Explorer باز کنید. این کار اتصالی به دیتابیس برقرار میکند و آن را زنده نگاه میدارد. برای ایجاد لاگین مورد نظر، میتوانیم در SQL Server Object Explorer یک کوئری اجرا کنیم:
create login [IIS APPPOOL\ASP.NET v4.0] from windows; exec sp_addsrvrolemember N'IIS APPPOOL\ASP.NET v4.0', sysadmin
اسکریپت بالا به اکانت ApplicationPoolIdentity سطح دسترسی کامل میدهد. در صورت امکان بهتر است از سطوح دسترسی محدودتری استفاده کنید، مثلا دسترسی به دیتابیس یا جداولی مشخص. حالا میتوانید اپلیکیشن را مجددا اجرا کنید و همه چیز بدون خطا باید کار کند.
معایب این روش چیست؟ مشکل اصلی در این رویکرد این است که پیش از آنکه اپلیکیشن ما بتواند به وهله مشترک دسترسی داشته باشد، باید وهله مورد نظر را راه اندازی و اجرا کنیم. بدین منظور، حساب کاربری ویندوزی که مالکیت وهله را دارد باید به آن وصل شود و کانکشن را زنده نگه دارد، در غیر اینصورت وهله LocalDb قابل دسترسی نخواهد بود.
رویکرد 3: استفاده از SQL Server Express
از آنجا که نسخه کامل SQL Server Express بعنوان یک سرویس ویندوزی اجرا میشود، شاید بهترین راه استفاده از همین روش باشد. کافی است یک نسخه از SQL Server Express را نصب کنیم، دیتابیس مورد نظر را در آن بسازیم و سپس به آن متصل شویم. برای این کار حتی میتوانید از ابزار جدید SQL Server Data Tools استفاده کنید، چرا که با تمام نسخههای SQL Server سازگار است. در صورت استفاده از نسخههای کامل تر، رشته اتصال ما بدین شکل تغییر خواهد کرد:
Data Source=.\SQLEXPRESS;Initial Catalog=OldFashionedDB;Integrated Security=True
create login [IIS APPPOOL\ASP.NET v4.0] from windows; exec sp_addsrvrolemember N'IIS APPPOOL\ASP.NET v4.0', sysadmin
حال اجرای مجدد اپلیکیشن باید با موفقیت انجام شود. استفاده از این روش مسلما امکان استفاده از LocalDb را از ما میگیرد. ناگفته نماند که وهلههای SQL Server Express همیشه در حال اجرا خواهند بود چرا که بصورت سرویسهای ویندوزی اجرا میشوند. همچنین استفاده از این روش ممکن است شما را با مشکلاتی هم مواجه کند. مثلا خرابی رجیستری ویندوز میتواند SQL Server Express را از کار بیاندازد و مواردی از این دست. راهکارهای دیگری هم وجود دارند که در این مقاله به آنها نپرداختیم. مثلا میتوانید از AttachDbFilename استفاده کنید یا از اسکریپتهای T-SQL برای استفاده از وهله خصوصی ASP.NET کمک بگیرید. اما این روشها دردسرهای زیادی دارند، بهمین دلیل از آنها صرفنظر کردیم.
مطالعه بیشتر درباره LocalDb
- WMI Provider MSI still failing to install in 16.6
- View History on context menu in Solution Explorer doesn't do anything
- Cannot generate shim for X509Certificate2 with Visual Studio 2019 16.6.0
- Add Controller and Add New Scaffolded Item dialogs are not showing all data contexts after upgrading Visual Studio Enterprise 16.5.6->16.6.0
- Cannot open new json file
- About Microsoft Visual Studio frozen.
- Visual Studio 2019 16.6.0 Microsoft Fakes Issue
- VSSDK IVsHierarchy Regression in VS 16.6.x
- Windows 10 SDK (10.0.19041.1)- ARM64 memcpy crashes when accessing unaligned uncached memory
- Add script to SQL Server Database project does not open User Scripts list
- Fakes generation with ref argument
- Frequent soft hang with Code Analysis callstack in Open Folder project
- Visual Studio Class Designer dark theme support
- Added support for Text Template Transformation Toolkit (T4) in .NET Core projects
- Separate IntelliCode team completions model acquisition from model production.
- Addressed an issue where users may have experienced critical update or installation failures due to the WMIProvider package that would block use of the IDE. Failures in this component no longer block use of the IDE.
- Fixed a problem causing the product to stop responding when working with Xamarin projects on certain scenarios.
- Fixed a bug where VS would crash when attempting to decrypt an invalid UWP code-signing certificate
در این مقاله چه چیزی را پوشش خواهیم داد:
· راه اندازی داکر
· پیکرهبندی container image
· وصل شدن به sql
· ساخت یک پروژه ساده net core.
· ایجاد دیتابیس
· ثبت رکورد در دیتابیس
قبل از هرچیز باید داکر را بر روی سیستم عامل خود (لینوکس) نصب نماید. چون نصب داکر بر روی لینوکس از حوصلهی این مقاله خارج میباشد، میتوانید با مراجعه به این لینک docker را نصب کنید. پس از نصب docker، برای اطمینان حاصل نمودن از نصب، با دستور docker version میتوان کانفیگ داکر را مشاهده کرد:
دانلود و نصب sql server بر روی داکر
قبل از هرچیز باید Image اسکیوال سرور را بر روی داکر دانلود نمائید. برای این کار وارد سایت dockerhub شوید و عبارت microsoft/mssql-server-linux را جستجو کنید.
همانطور که در تصویر نیز مشاهد میکنید، این بسته 10 میلیون بار دریافت شدهاست! در ادامه دستور زیر را در ترمینال خود Paste کنید و منتظر بمانید تا دانلود شود:
docker pull microsoft/mssql-server-linux:2017-latest
برای اجرای image sql از دستور زیر استفاده میکنیم:
sudo docker run -e 'ACCEPT_EULA=Y' -e 'SA_PASSWORD=<YourStrong!Passw0rd>' \ -p 1433:1433 --name sql1 \ -d mcr.microsoft.com/mssql/server:2017-latest
Set the SA_PASSWORD : پسورد environment variable ای که شما انتخاب میکنید.
p 1433:1433- : شماره پورتی که Docker container بر روی آن اجرا میشود.
-d microsoft/mssql-server-linux:2017-latest : نام Image ای که میخواهیم اجرا کنیم.
همانطور که ملاحظه میکنید، در قسمت status، عبارت up به معنای در حال اجرا بودن container است. اگر عبارت دیگری را مشاهده کردید، با دستور dockr start id و وارد کردن شماره image خود میتوانید آن را اجرا کنید.
تا اینجا توانستیم sql server را اجرا کنیم. برای توضیحات بیشتر به این لینک مراجعه کنید.
وصل شدن به sql
برای وصل شدن به دیتابیس باید connection string دیتابیس مربوطه را داشته باشیم. با توجه به کانفیگهایی که در بالا انجام دادیم، connection string ما به شکل زیر خواهد بود:
Server Host: localhost Port: 1433 Authentication: SQL Server Authentication Login: SA Password: <StrongPasswordYouSet>
sudo docker exec -it sql1 "bash"
/opt/mssql-tools/bin/sqlcmd -S localhost -U SA -P '<YourNewStrong!Passw0rd>'
تا اینجای کار sql server آمادهی اجرا دستورات شما میباشد. در ادامه میخواهیم چند دستور سادهی sql را بر روی آن اجرا کنیم.
ساخت دیتابیس
با دستور sqlcmd زیر، ابتدا یک دیتابیس را میسازیم:
CREATE DATABASE TestDB
ساخت جدول
در ادامه، دستور زیر را برای ساخت جدول مینویسیم:
CREATE TABLE Inventory (id INT, name NVARCHAR(50), quantity INT)
ایجاد رکورد
مرحله بعدی، ایجاد یک رکورد جدید در دیتابیس میباشد:
INSERT INTO Inventory VALUES (1, 'banana', 150); INSERT INTO Inventory VALUES (2, 'orange', 154);
در آخر با استفاده از دستور go، کوئریهای بالا را اجرا میکنیم. اکنون باید یک دیتابیس جدید به نام TestDB و یک جدول جدید نیز به نام Inventory همچنین یک رکورد جدید در آن ثبت شده باشد. برای مشاهدهی تغییرات بالا، از دستورات زیر استفاده میکنیم:
- با دستور زیر لیست دیتابیسهای موجود را میتوان دید:
SELECT Name from sys.Databases
SELECT * FROM Inventory WHERE quantity > 152;
تا اینجا توانستیم docker را بر روی سیستم راه ندازی و همچنین sql server را بر روی آن نصب و اجرا کنیم. همچنین با دستورات sqlcmd توانستیم بر روی sql کوئری بزنیم.
ساخت و وصل شدن یک پروژهی net core. و وصل شدن به sql server
حال میخواهیم با یک پروژهی سادهی net core. به sql server فوق وصل شده و یک جدول را به دیتابیس مذکور اضافه کرده و یک کوئری اضافه کردن رکوردی را به آن جدول بنویسیم. برای شروع، یک پروژهی خالی net core. را ایجاد میکنیم. برای مثال یک پروژهی api را ایجاد میکنیم:
dotnet new webapi -o dockerapi
dotnet add package Microsoft.EntityFrameworkCore.SqlServer dotnet add package Microsoft.EntityFrameworkCore.Design
public class Students { public int Id { get; set; } public string Name { get; set; } public string Phone { get; set; } }
dotnet ef dbcontext scaffold "Server=localhost,1433\\Catalog=tutorial_database;Database=<YOUR_DATABASE_NAME>;User=SA;Password=<StrongPasswordYouSet>;" Microsoft.EntityFrameworkCore.SqlServer
"ConnectionStrings": { "TestingDatabase": "Server=localhost:1433\\Database=<YourDatabaseName>;User=SA;Password=<StrongPasswordYouSet>;" }
dotnet ef migrations add <NAME_OF_MIGRATION>
همانطور که مشاهده میکنید، migrations اضافه شده و موجودیت هم اضافه شدهاست. حال باید بر روی migrations خود آپدیت بزنیم:
ef database update
SELECT TABLE_NAME FROM dockerdb.INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = 'BASE TABLE'
- Power Shell Command Builder | pspcommunity.org
- فایرفاکس 8 فردا معرفی می شود، امکان دانلود از امروز « WinBeta.Net | Where Tech Becomes Life | www.winbeta.net
- وبینار و پادکست آزاد و رایگان Agile | دنیای چابک | blog.irscrum.com
- New SQL Server 2012 Labs and Presentations | blogs.msdn.com
- اضافه کردن Watermark به PDF تولیدی توسط iTextSharp | footheory.com
- دریافت کتاب رایگان Windows Phone Blue Book | www.robmiles.com
- لیست موارد منسوخ شده در SQL Server | technet.microsoft.com
ابزار Memory Optimization Advisor
Memory Optimization Advisor یک Wizard مانند است که از آن برای گرفتن مشاوره در مورد تبدیل جداول موجود مبتنی بر دیسک سخت، به نمونههای بهینه سازی شده برای حافظه میتوان استفاده کرد. کار آن بررسی ساختار جداولی است که قصد مهاجرت آنها را دارید. برای مثال همانطور که پیشتر نیز عنوان شد، جداول بهینه سازی شده برای حافظه محدودیتهایی دارند؛ مثلا نباید کلید خارجی داشته باشند. این Wizard یک چنین مواردی را آنالیز کرده و گزارشی را ارائه میدهد. پس از اینکه مراحل آنرا به پایان رساندید و مشکلاتی را که گزارش میدهد، برطرف نمودید، کد تبدیل جدول را نیز به صورت خودکار تولید میکند.
برای دسترسی به آن، فقط کافی است بر روی نام جدول خود کلیک راست کرده و گزینهی memory optimization advisor را انتخاب کنید.
در دو قسمت اول این Wizard، کار بررسی ساختار جدول در حال مهاجرت صورت میگیرد. اگر نوع دادهای در آن پشتیبانی نشود یا قیود ویژهای در آن تعریف شده باشند، گزارشی را جهت رفع، دریافت خواهید کرد. پس از رفع آن، به صفحهی گزینههای مهاجرت میرسیم:
همانطور که ملاحظه میکنید، گروه فایل ایجاد شده در قسمت قبل، به صورت خودکار انتخاب شدهاست.
در ادامه میتوان نام دیگری را برای جدول مبتنی بر دیسک وارد کرد. در اینجا به صورت خودکار کلمهی old به آخر نام جدول اضافه شدهاست. در حین تولید جدول جدید بهینه سازی شدهی بر اساس ساختار جدول فعلی، این جدول قدیمی به صورت خودکار تغییر نام خواهد یافت و کلیه اطلاعات آن حفظ میشود.
همچنین تخمینی را نیز از مقدار حافظهی مورد نیاز برای نگهداری این جدول جدید درون حافظهای نیز ارائه میدهد. در این مثال چون رکوردی در جدول انتخابی وجود نداشتهاست، تخمین آن صفر است. عدد ارائه شده توسط آن بسیار مهم است و باید به همین میزان برای سیستم خود حافظه تهیه نمائید و یا از حافظهی موجود استفاده کنید.
در پایین صفحه میتوان انتخاب کرد که آیا دادههای جدول فعلی، به جدول درون حافظهای انتقال یابند یا خیر. به علاوه نوع ماندگاری اطلاعات آن نیز قابل تنظیم است. اگر گزینهی آخر را انتخاب کنید به معنای حالت SCHEMA_ONLY است. حالت پیش فرض آن SCHEMA_AND_DATA میباشد که در قسمتهای قبل بیشتر در مورد آن بحث شد.
در دو صفحهی بعد، کار انتخاب hash index و range index انجام میشود:
در اینجا hash index بر روی فیلد ID تولید شدهاست، به همراه تعیین bucket count آن و در صفحهی بعدی range index بر روی فیلد تاریخ تعریف گردیدهاست:
در آخر میتوان با کلیک بر روی دکمهی Script، صرفا دستورات T-SQL تغییر ساختار جدول را دریافت کرد و یا با کلیک بر روی دکمهی migrate به صورت خودکار کلیه موارد تنظیم شده را اجرا نمود.
خلاصهی این مراحل که توسط دکمهی Script آن تولید میشود، به صورت زیر است:
USE [testdb2] GO EXEC dbo.sp_rename @objname = N'[dbo].[tblNormal]', @newname = N'tblNormal_old', @objtype = N'OBJECT' GO USE [testdb2] GO SET ANSI_NULLS ON GO CREATE TABLE [dbo].[tblNormal] ( [CustomerID] [int] NOT NULL, [Name] [nvarchar](250) COLLATE Persian_100_CI_AI NOT NULL, [CustomerSince] [datetime] NOT NULL, INDEX [ICustomerSince] NONCLUSTERED ( [CustomerSince] ASC ), CONSTRAINT [tblNormal_primaryKey] PRIMARY KEY NONCLUSTERED HASH ( [CustomerID] )WITH ( BUCKET_COUNT = 131072) )WITH ( MEMORY_OPTIMIZED = ON , DURABILITY = SCHEMA_AND_DATA ) GO INSERT INTO [testdb2].[dbo].[tblNormal] ([CustomerID], [Name], [CustomerSince]) SELECT [CustomerID], [Name], [CustomerSince] FROM [testdb2].[dbo].[tblNormal_old] GO
علاوه بر memory optimization advisor مخصوص جداول، ابزار دیگری نیز به نام Native compilation advisor برای آنالیز رویههای ذخیره شده تهیه شدهاست:
آیا سیستم فعلی ما واقعا نیازی به ارتقاء به جداول درون حافظهای دارد؟
تا اینجا در مورد نحوهی ایجاد جداول درون حافظهای و یا نحوهی تبدیل جداول موجود را به ساختار جدید بررسی کردیم. ولی آیا واقعا یک چنین تغییراتی برای ما سودمند هستند؟ برای پاسخ دادن به این سؤال ابزاری به نام AMR به management studio 2014 اضافه شدهاست (Analyze, Migrate, Report). کار آن تحت نظر قرار دادن جداول و رویههای ذخیره شدهی بانک اطلاعاتی است و سپس بر اساس بار سیستم، تعداد درخواستهای همزمان و میزان استفاده از جداول و تراکنشهای مرتبط با آنها، گزارشی را ارائه میدهد. بر این اساس بهتر میتوان تصمیم گرفت که کدام جداول بهتر است به جداول درون حافظهای تبدیل شوند.
برای تنظیم آن باید مراحل ذیل طی شوند:
در Management Studio، به برگهی Object Explorer آن مراجعه کنید. سپس پوشهی Management آنرا یافته و بر روی گزینهی Data Collection کلیک راست نمائید:
در اینجا گزینهی Configure Management Data Warehouse را انتخاب نمائید. در صفحهی باز شده، ابتدا بانک اطلاعاتی مدنظر را انتخاب نمائید. همچنین بهتر است بر روی دکمهی new کلیک کرده و یک بانک اطلاعاتی جدید را برای آن ایجاد نمائید، تا دچار تداخل اطلاعاتی و ساختاری نگردد:
در ادامه نام کاربری را که قرار است کار مدیریت ثبت و جمع آوری اطلاعات را انجام دهد، به همراه نقشهای آن انتخاب نمائید:
و در آخر در صفحهی بعدی بر روی دکمهی Finish کلیک کنید.
پس از ایجاد و انتخاب بانک اطلاعاتی Management Data Warehouse، نوبت به تنظیم گزینههای جمع آوری اطلاعات است:
در اینجا ابتدا سرور جاری را انتخاب کنید. پس از آن به صورت خودکار در لیست بانکهای اطلاعاتی قابل انتخاب، تنها همان بانک اطلاعاتی جدیدی را که برای مرحلهی قبل ایجاد کردیم، میتوان مشاهده کرد.
در صفحهی بعد، گزینهی «Transaction Performance Collection Sets» را انتخاب نمائید که دقیقا گزینهی مدنظر ما جهت یافتن آماری از وضعیت تراکنشهای سیستم است.
در ادامه بر روی گزینههای next و finish کلیک کنید تا کار تنظیمات به پایان برسد.
اکنون اگر به لیست وظایف تعریف شده در SQL Server agent مراجعه کنید، میتوانید، وظایف مرتبط با جمع آوری دادهها را نیز مشاهده نمائید:
وظایف Stored Procedure Usage Analysis هر نیم ساعت یکبار و وظایف Table Usage Analysis هر 15 دقیقه یکبار اجرا میشوند. البته امکان اجرای دستی این وظایف نیز مانند سایر وظایف SQL Server وجود دارند.
همچنین در پوشهی management، گزینهی Data collection نیز دو زیر شاخه اضافه شدهاند که نمایانگر آنالیز میزان مصرف جداول و رویههای ذخیره شده میباشند:
پس از این کارها باید مدتی صبر کنید (مثلا یک ساعت) تا سیستم به صورت معمول کارهای متداول خودش را انجام دهد. پس از آن میتوان به گزارشات AMR مراجعه کرد.
برای اینکار بر روی بانک اطلاعاتی Management Data Warehouse که در ابتدای عملیات ایجاد شد، کلیک راست نمائید و سپس مراحل ذیل را طی کنید:
Reports > Management Data Warehouse > Transaction Performance Analysis Overview
در گزارش ایجاد شده، ذیل گزینهی usage analysis لینکهایی وجود دارند که با مراجعه به آنها، چارتهایی از میزان مصرف بانکهای اطلاعاتی مختلف سیستم ارائه میشود. اگر پیام No data available را مشاهده کردید، یعنی هنوز باید مقداری صبر کنید تا کار جمع آوری اطلاعات به پایان برسد.
در این چارتها بانکهای اطلاعاتی که در سمت راست، بالای تصویر قرار میگیرند، انتخاب مناسبی برای تبدیل به بانکهای اطلاعاتی درون حافظهای هستند. محور افقی آن از چپ به راست بیانگر میزان کاهش سختی انتقال یک جدول به جدول درون حافظهای است (با درنظر گرفتن تمام مسایلی که باید تغییر کنند یا نوعهای دادهای که باید اصلاح شوند) و محور عمودی آن نمایانگر میزان بالا رفتن پاسخ دهی سیستم در جهت انجام کار بیشتر است.
هر زمان هم که کار تصمیمگیری شما به پایان رسید، میتوانید بر روی گزینهی Data collection کلیک راست کرده و آنرا غیرفعال نمائید.
برای مطالعه بیشتر
SQL Server 2014 Field Benchmarking In-Memory OLTP and Buffer Pool Extension Features
New AMR Tool: Simplifying the Migration to In-Memory OLTP
A Tour of the Hekaton AMR Tool
SQL Server 2014 Memory Optimization Advisor
Getting started with the AMR tool for migration to SQL Server In-memory OLTP Tables
How to Use Microsoft's AMR Tool
SQL Server 2014's Analysis, Migrate, and Report Tool
در این مقاله قصد داریم نحوه مونیتور کردن میزان مصرف CPU توسط اس کیوال سرور را بررسی کنیم. برای بدست آوردن میزان CPU مصرفی اس کیوال سرور میتوان به اسکریپت زیر رجوع کرد:
DECLARE @CPU_BUSY int, @IDLE int
SELECT @CPU_BUSY = @@CPU_BUSY, @IDLE = @@IDLE WAITFOR DELAY '000:00:01'
SELECT (@@CPU_BUSY - @CPU_BUSY)/((@@IDLE - @IDLE + @@CPU_BUSY - @CPU_BUSY) *1.00) *100 AS 'CPU Utilization by sqlsrvr.exe'
در ادامه قصد داریم، هر 5 دقیقه به صورت خودکار بررسی کنیم که آیا میزان مصرف CPU در اس کیوال سرور بالای 50 درصد است؟ و اگر بله، ایمیلی را به مسؤول مربوطه جهت بررسی ارسال کنیم.
بنابراین اولین کاری که باید صورت گیرد، فعال سازی Database Mail در اس کیوال سرور است که به صورت پیش فرض غیرفعال است. برای این منظور تنها کافی است اسکریپت زیر را بر روی سرور اجرا کنید:
USE [master]
GO
sp_configure 'show advanced options',1
GO
RECONFIGURE WITH OVERRIDE
GO
sp_configure 'Database Mail XPs',1
GO
--RECONFIGURE
GO
-- Create a New Mail Profile for Notifications
EXECUTE msdb.dbo.sysmail_add_profile_sp
@profile_name = 'DBA_Notifications',
@description = 'Profile for sending Automated DBA Notifications'
GO
-- Set the New Profile as the Default
EXECUTE msdb.dbo.sysmail_add_principalprofile_sp
@profile_name = 'DBA_Notifications',
@principal_name = 'public',
@is_default = 1 ;
GO
-- Create an Account for the Notifications
EXECUTE msdb.dbo.sysmail_add_account_sp
@account_name = 'SQLMonitor',
@description = 'Account for Automated DBA Notifications',
@email_address = 'nasiri@site.net', -- Change This
@display_name = 'SQL Monitor',
@mailserver_name = 'mail.site.net' -- Change This
GO
-- Add the Account to the Profile
EXECUTE msdb.dbo.sysmail_add_profileaccount_sp
@profile_name = 'DBA_Notifications',
@account_name = 'SQLMonitor',
@sequence_number = 1
GO
این اسکریپت برای اس کیوال سرورهای 2005 به بعد طراحی شده و تنها دو سطر آنرا پیش از اجرا باید ویرایش کنید. سطر مربوط به email_address و mailserver_name . آدرس ایمیل درحقیقت آدرس ایمیل قسمت from پیغام ارسالی را تشکیل میدهد. نام سرور میل هم، منظور آدرس smtp server شما در شبکه است.
یا اگر علاقمند بودید که اینکار را توسط ویزاردهای management studio انجام دهید (که در نهایت هیچ تفاوتی با اسکریپت فوق نخواهد داشت)، میتوان به این مقاله رجوع کرد.
پس از اجرای اسکریپت فوق، برای بررسی صحت عملکرد فوق میتوان دستور زیر را اجرا کرد:
--test
EXECUTE msdb.dbo.sp_send_dbmail
@recipients = 'nasiri@site.net', -- Change This
@Subject = 'Test Message generated from SQL Server DatabaseMail',
@Body = 'This is a test message from SQL Server DatabaseMail'
تا اینجا اس کیوال سرور برای ارسال ایمیل آماده شد. در ادامه قصد داریم یک job جدید در اس کیوال سرور ایجاد کنیم تا تمام موارد فوق را لحاظ کند.
مطابق تصویر فوق ابتدا یک job جدید را آغاز خواهیم کرد.
در ادامه اسکریپت زیر را جهت اجرا به آن معرفی میکنیم. توسط این اسکریپت، میزان جاری مصرف CPU اس کیوال سرور محاسبه شده و اگر این میزان بیشتر از 50 بود، یک ایمیل به مسؤول مربوطه با ذکر میزان CPU usage ارسال میگردد.
DECLARE @CPUUsage INT
DECLARE @CPU_BUSY INT,
@IDLE INT
SELECT @CPU_BUSY = @@CPU_BUSY,
@IDLE = @@IDLE
WAITFOR DELAY '000:00:01'
SELECT @CPUUsage = (@@CPU_BUSY - @CPU_BUSY) / ((@@IDLE - @IDLE + @@CPU_BUSY - @CPU_BUSY) * 1.00)
* 100 -- CPU Utilization by sqlsrvr.exe
IF @CPUUsage > 50
BEGIN
DECLARE @msg NVARCHAR(1000)
SET @msg = 'Please check SQL server, CPU usage is ' + CAST(@CPUUsage AS NVARCHAR(50))
+ '%.'
EXECUTE msdb.dbo.sp_send_dbmail
@recipients = 'nasiri@site.net', -- Change This
@copy_recipients = 'nasiri@site.net', -- Change This
@Subject = 'CPU overload',
@Body = @msg
,@importance = 'High'
END
و در آخر زمان اجرای آن را به هر روز، هر 5 دقیقه یکبار تنظیم خواهیم کرد.
اگر نیاز به راه حلی پختهتر و بررسی متوسط چندین مقدار قبلی ، مقایسه آنها و سپس ارسال ایمیل داشتید، میتوان به فصل 14 کتاب Super SQL Server Systems مراجعه کرد.
PowerShell For SQL Full Course
f you’re a SQL Data Pro, check out this demo-packed course to explore using PowerShell to manage SQL Server and Azure SQL Database. Hear about the background of PowerShell, and learn PowerShell basics, such as how to get help, use cmdlets, and load modules. Look at task automation and configuration, and learn how to provision, deploy, and manage SQL Server in Azure Virtual Machines and Azure SQL Database. Plus, see how to use the SQLPS module to administer SQL Server, both on-premises and in Azure Virtual Machines. Don’t miss this practical PowerShell training