محمد رجبی محمد رجبی
نحوه تعریف Linked Server و دریافت اطلاعات از سروری دیگر
‫۹ سال و ۱۰ ماه قبل، چهارشنبه ۱۲ آذر ۱۳۹۳، ساعت ۱۲:۳۱
با سلام و احترام؛ ضمن سپاس از نوشتن این مطلب، نکات تکمیلی زیر برای خوانندگان ارائه می‌گردد:
پس از ایجاد Linked Server به طریقی که در مطلب فوق بدان اشاره گردید، به دو صورت می‌توان به اجرای دستورات در Server دیگر پرداخت. به شکل Distributed Query و یا استفاده از تابع ()OPENQUERY .
برای مثال دو SQL Instance به نام‌های SQL1 و SQL2 موجود است که قصد داریم عملیاتی را از SQL2 با استفاده از امکان Distributed Query و OpenQuery در SQL1 انجام دهیم، برای مثال:
  :Distributed Query 
SELECT * FROM [SQL2].[test].[dbo].[emp]
:OPENQUERY 
 SELECT * from OPENQUERY([SQL2], 'SELECT * FROM [test].[dbo].[emp]')
در استفاده از OpenQuery باید جانب احتیاط را رعایت نمود، چنانچه قصد اجرای دستورات ساده ای را در Remote Server دارید، توصیه می‌شود از Distributed Query استفاده شود و اگر دستورات پیچیده و محاسباتی هستند استفاده از OPENQUERY هزینه کمتری دارد. همچنین در نظر داشته باشید چنانچه در دستورات مربوط به جدولی ستونی با دیتا تایپ XML وجود داشت قادر به اجرای دستورات به هر دو شکل نخواهید بود، در واقع کوئری‌های توزیع شده این مورد را پشتیبانی نمی‌کنند. برای مثال پس از اجرای دستورات زیر با پیغام خطا زیر مواجه می‌شوید: «Xml data type is not supported in distributed queries»
SELECT * FROM [نام Linked Server].[AdventureWorks].[Person].[Person]
GO
SELECT * FROM OPENQUERY([نام Linked Server ],'SELECT * FROM [AdventureWorks].[Person].[Person]')
همچنین در نظر داشته باشید چنانچه در دستورات مربوط به جدولی ستونی با دیتا تایپ CLR وجود داشت قادر به اجرای دستورات به شکل OpenQuery خواهید بود ولی در صورت استفاده از Distributed Query  با خطایی مواجه می‌شوید با این پیغام  «Objects exposing columns with CLR types are not allowed in distributed queries» 
SELECT * FROM [نام Linked Server] .[AdventureWorks].[Person].[Address]
GO
SELECT * FROM OPENQUERY([نام Linked Server] ,'SELECT * FROM [AdventureWorks].[Person].[Address]')
برای کسب اطلاعات بیشتر به لینک زیر مراجعه فرمائید:
می توانید برای جداولی که حاوی داده می‌باشند نیز از امکان Partitioning استفاده نمائید. برای جدول Orders سناریوی مورد بررسی، بدون استفاده از PartitionSchema به شکل زیر ایجاد می‌شود: 

CREATE TABLE Orders
(
OrderID INT IDENTITY(1,1) NOT NULL,
OrderDate DATETIME NOT NULL,
OrderFreight MONEY NULL,
ProductID INT NULL,
CONSTRAINT PK_Orders PRIMARY KEY CLUSTERED (OrderID ASC, OrderDate ASC)
ON [PRIMARY]
) ON [PRIMARY]
GO
می‌توانید به شکل زیر محتوای جدول که در فایل گروپ PRIMARY قرار گرفته را در سایر پارتیشن‌ها قرار داد.
 ALTER TABLE Orders DROP CONSTRAINT PK_Orders
 WITH (MOVE TO psOrderDateRange (OrderDate))
 Go
از آنجایی که هر Data File شامل یک مسیر فیزیکی است (در یک Filegroup قرار می‌گیرد)، بنابراین این امکان وجود دارد که محتوای یک جدول حجیم را به چندین قسمت در سطح کنترلر تقسیم نمود، اگر سوالتان در خصوص اینکه «پارتیشن‌ها را بعد از اینکه آرشیو شدند، می‌توان از وضعیت آرشیو خارج نمود» و منظور Read Only نمودن پارتیشن‌ها است همانگونه که در متن ذکر شده "چک باکس Read Only ... چنانچه روی یک Filegroup تنظیم گردد، عملیات مربوط به Write روی داده‌های آن قابل انجام نیست و برای Filegroup هایی که جنبه نگهداری آرشیو را دارند، قابل استفاده است. و چنانچه Filegroup ای را از حالت Read Only دوباره خارج کنیم، می‌توان عملیات Write را دوباره برای آن انجام داد." در این حالت به منظور بالا بردن  Performance می‌توانید از RAID 0 یا RAID 1 جهت بهره مندی از Fast read استفاده کنید.
محمد رجبی محمد رجبی
Resource Governor در 2008 SQL Server
‫۹ سال و ۱۰ ماه قبل، چهارشنبه ۲۱ آبان ۱۳۹۳، ساعت ۱۷:۰۷
در SQL Server 2012 به منظور تضمین عملکرد تعداد پشتیبانی از مخازن منابع از 20 عدد به 64 عدد افزایش یافته است. همچنین در SQL Server 2014 پشتیبانی از I/O نیز اضافه گردید.(تا پیش از ارائه نسخه 2014 محدودیت روی منابع تنها به CPU و حافظه خلاصه می‌شد)
با سلام -همانطور که می‌دانیم؛ هدف فرآیند آرشیو حذف گروهی از داده‌ها از بانک اطلاعاتی می‌باشد. این داده‌ها دیگر مورد نیاز در سیستم عملیاتی نمی‌باشند ولی می‌خواهیم آنها را حفظ نمائیم. تکنیک‌های متفاوتی برای این منظور وجود داشته است از قبیل:
- Application partitioning: به طور کلی جهت دستیابی به اطلاعات (از محیط عملیاتی و یا محیط‌های گزارشی گیری با ماهیت آرشیو) از درون خود برنامه کاربردی با ماشین مورد نظر ارتباط برقرار می‌گردید.
-(Partition Views (DPVs: جداول یکسانی ایجاد می‌گردید، که هر یک حاوی قسمتی از اطلاعات بودند و بدین ترتیب برای دستیابی به تمامی داده‌های این جداول با ایجاد یک View (پیوند میان این جداول) کلیه اطلاعات قابل دسترسی بود.
در تکنیک پارتیشنینگ کلیه محتوای جدول بصورت یکجا قابل دستیابی است، همچنین جهت آرشیو با استفاده از عملگر  Switch این امکان را داریم که در کسری از ثانیه (با تنها انتقال Meta data) به آرشیو اطلاعات بپردازیم.
تا پیش از انتشار نسخه 2012 توان پشتیبانی از 1.000 پارتیشن وجود داشت این امکان در نسخه 2014 به 15.000 پارتیشن رسیده است.
همانگونه که ذکر گردید جهت آرشیو از عملگر Switch استفاده می‌شود (و نه عملگر Merge) همچنین در خصوص نحوه انجام پارتیشن بندی از آنجا که تابع یک Data type می‌گیرد الزامی به نوع Date نیست و مطابق شکل می‌تواند نوع آن Int نیز باشد، ولی عملیات آرشیو در ذات خود به اطلاعات تاریخچه ای اشاره می‌کند. جهت اطلاعات بیشتر به لینک Partitioned Tables and Indexes مراجعه شود.


در مثال مذکور از Partition Key در زمان تعریف یک Primary Key Constraint روی جدول به منظور داشتن ساختار Aligned Index ، استفاده نموده ایم.
در هنگام ایجاد یک Primary Key Constraint بطور خودکار یک Unique Clustered Index  نیز روی ستون (های) شرکت یافته در تعریف  Primary Key ایجاد می‌شود و بدین ترتیب Table براساس این فیلد (ها) به شکل Sort شده نگهداری می‌شود، ضمن اینکه هر Table می‌تواند، شامل 1 عدد Clustered Index و 249 عدد Nonclustered Index باشد.
با سلام، ابتدا از سوال آخر شروع میکنم، چنانچه تمایل دارید از امکان پارتیشنینگ در آرشیو بانک اطلاعاتی تان استفاده کنید همانگونه که در متن اشاره شده، باید جداول به شکل Aligned Index تعریف شوند.(پس نیاز به Filegroup می‌باشد)
در مورد فشرده سازی به هیچ وجه هدف افزایش سرعت در پرس و جو‌ها نیست بلکه کاهش حجم، هدف غائی است. همینطور هدف از ایجاد ایندکس در این است که هر رکورد در مکان صحیح خود به هنگام درج قرار گیرد و بدین ترتیب چنانچه مجموعه مرتب شده باشد، مرتبه اجرائی از (O(n به  (O( Log n کاهش می‌یابد و ... به همین خاطر است که در سیستم‌های OLTP توصیه شده از Index هوشمندانه استفاده شود (بدلیل اینکه عملیات درج، بروزرسانی و حذف به کندی صورت نگیرد) و در سیستم‌های DSS برعکس به دلیل ماهیت غیر عملیاتی بودن آنها استفاده فراوان از Index توصیه شده است.
بطور کلی ساختار ایندکس پایه در SQL Server عبارتند از: ایندکس‌های Clustered ، ایندکس‌های Nonclustered در Heap و  ایندکس‌های Nonclustered در یک ایندکس‌های Clustered شده؛ روش ذخیره فیزیکی داده بین این ایندکس‌ها متفاوت است و همچنین روشی که SQL Server برای پیمایش ایندکس در B-Tree استفاده می‌کند بسته به این سه نوع متفاوت خواهد بود.  
محمد رجبی محمد رجبی
استفاده از قابلیت پارتیشن بندی در آرشیو جداول بانک‌های اطلاعاتی SQL Server
‫۹ سال و ۱۱ ماه قبل، چهارشنبه ۱۴ آبان ۱۳۹۳، ساعت ۱۷:۱۰
با سلام و احترام
پیشنهاد می‌کنم مطلب "Download "Partitioned Table and Index Strategies Using SQL Server 2008" white paper " را مطالعه فرمائید. به منظور پیاده سازی این قابلیت در بانک اطلاعاتی تان یک راه حل می‌تواند اینگونه باشد که یک DB جدید ایجاد نمائید که در آن تمامی زیرساخت‌ها ایجاد شود (ایندکس، Partition Function و ...) در ادامه به انتقال داده‌های از بانک عملیاتی به DB جدید بپردازید. برای مشاهده جزئیات به این مطلب مراجعه نمائید.
محمد رجبی محمد رجبی
معرفی و استفاده از DDL Triggers در SQL Server
‫۹ سال و ۱۲ ماه قبل، چهارشنبه ۲ مهر ۱۳۹۳، ساعت ۱۴:۰۴
با سلام و احترام؛ همانطور که در متن به عرض رسانده شده:
" از عبارت  ON  برای مشخص کردن محدوده Trigger در سطح SQL Instance (در این صورت ON All SERVER نوشته می‌شود) و یا در سطح Database (در این حالت ON DATABASE نوشته می‌شود)  استفاده می‌شود و از عبارت FOR  برای مشخص کردن رویداد یا گروه رویدادی که سبب فراخوانی  Trigger می‌شود، استفاده  خواهد شد.  "
در خصوص مثالی که اشاره کردید، به نظرم می‌رسد از Trigger برای این منظور استفاده نمی‌شود (در حوزه‌ی بکاپ و ریستور)، شاید اگر قصدتان به منظور ثبت log و ... بایست از Auditing استفاده کنید. به این منظور در Auditing با توجه به جدول زیر می‌توان اقدام به ثبت موارد نمود:
Server-Level Audit Action Groups  
Action group name 
 Event Class   Description 
 BACKUP_RESTORE_GROUP   Audit Backup/Restore  
 یک دستور Backup یا Restore صادر شود  
به طور مختصر Auditing به شرح زیر است:
 بررسی SQL Server Audit
 بازبینی (Auditing) شامل پیگیری و ثبت رویدادهایی است که در سطح SQL Instance و یا Database‌های روی یک سیستم اتفاق می‌افتد. چندین سطح برای Auditing در SQL Server وجود دارد که به صلاحدید و نیازمندی‌های نصب شما وابسته است. شما می‌توانید گروه اقدامات بازبینی سرویس دهنده (server audit action groups) را به ازای هر SQL Instance و گروه اقدامات بازبینی بانک اطلاعاتی (database audit action groups) را  به ازای هر بانک اطلاعاتی ثبت کنید. رویداد Audit هر زمان عملی که مورد رسیدگی قرار گرفته اتفاق افتد، رخ می‌دهد.
تا پیش از SQL SERVER 2008، شما باید از خصیصه‌های متعددی برای انجام یک مجموعه کامل بازبینی (Auditing) برای نمونه DDL Trigger، DML Trigger و SQL Trace، بر روی یک SQL Instance استفاده می‌کردید.
SQL SERVER 2008، همه قابلیت‌های Auditing را روی یک audit specification ترکیب می‌کند. Audit Specification با تعریف یک شی بازبینی (audit object) در سطح سرویس دهنده برای ثبت (logging) یک دنباله بازبینی (audit trial) آغاز می‌شود. توجه شود که بایست یک شیء بازبینی ایجاد کنید پیش از اینکه یک Server Audit Specification و یا Database Audit Specification ایجاد کنید.
Server Audit Specification، گروه اقدامات در سطح سرویس دهنده را جمع آوری می‌کند که با رویدادهای وسیعی فعال می‌شوند، این گروه اقدامات تحت عنوان  Server-Level Audit Action Groups تشریح شده اند. شما می‌توانید یک Server Audit Specification را به ازای هر Audit ایجاد کنید چرا که هر دو در محدوده یک SQL Instance ایجاد می‌شوند.
Database Audit Specification، گروه اقدامات در سطح بانک اطلاعاتی را جمع آوری می‌کند که با رویدادهای وسیعی فعال می‌شود. این گروه اقدامات تحت عنوان‌های Database-Level Audit Action Groups و Database-Level Audit Actions تشریح شده اند.می توانید یک Database Audit Specification را به ازای هر Audit در بانک اطلاعاتی SQL Server ایجاد کنید.
همچنین می‌توانید هر گروه اقدامات بازبینی(audit action groups) یا رویدادهای بازبینی(audit events) را به یک Database Audit Specification اضافه کنید. گروه اقدامات بازبینی، گروه اقدامات از پیش تعریف شده ای هستند و رویدادهای بازبینی اقدامات تجزیه ناپذیری هستند که توسط موتور بانک اطلاعاتی مورد رسیدگی قرار می‌گیرند، هر دو در محدوده بانک اطلاعاتی (Database) هستند. این اقدامات برای Audit فرستاده می‌شوند تا در Target (که می‌تواند یک فایل، Windows Security Log و یا Windows Application Log باشد) ذخیره شوند. برای نوشتن در Windows Security Log لازم است که Service Account سرویس دهنده شما به Policy، Generate security audits اضافه شده باشد، به صورت پیش فرض Local System، Local Service و Network Service بخشی از این Policy می‌باشند. پس از اینکه Audit را ایجاد و فعال کردید، Target ورودی‌ها را دریافت خواهد کرد. 
Server-Level Audit Action Groups (گروه اقدامات بازبینی در سطح سرویس دهنده)
این گروه اقدامات به گروه رویداد Security Audit شبیه هستند. به طور خلاصه این گروه اقدامات، اقداماتی را که در یک SQL Instance شامل می‌شوند، در بر می‌گیرد. برای مثال اگر گروه اقدام مناسب با Server Audit Specification اضافه شده باشد هر شیء در هر Schema که مورد دستیابی قرار می‌گیرد، ثبت می‌شود. اقدامات در سطح سرویس دهنده به شما اجازه نمی‌دهد که جزئیات اقدامات در سطح بانک اطلاعاتی را فیلتر کنید. یک بازبینی در سطح بانک اطلاعاتی برای انجام به جزئیات دقیق فیلتر کردن نیاز دارد، برای مثال اجرای دستور Select روی جدول Customers برای login هایی که در گروه Employee هستند.
Database-Level Audit Action Groups (گروه اقدامات بازبینی در سطح بانک اطلاعاتی)
این گروه اعمال به کلاس‌های رویداد Security Audit  شبیه هستند.
Database-Level Audit Actions
اقدامات در سطح بانک اطلاعاتی، اقدامات بازبینی خاصی را به طور مستقیم روی Database، Schema و اشیاء Schema (از قبیل جداول، View ها، رویه‌های ذخیره شده، توابع و ... ) فراهم می‌کند. این اقدامات برای فیلدها (Columns) صدق نمی‌کنند.
Audit-Level Audit Action Groups
شما می‌توانید اقداماتی را که در فرآیند Auditing هستند، بازبینی کنید که می‌تواند در محدوده سرویس دهنده یا بانک اطلاعاتی باشد. در محدوده بانک اطلاعاتی تنها برای database audit specification رخ می‌دهد.
  جهت بررسی بیشتر به این لینک مراجعه شود.