پشتیبانی از Change Data Capture

Change Data Capture یا CDC قابلیتی است که در Database Engine مربوط به SQL Server 2008 معرفی شد. وقتی پایگاه‌داده برای CDC پیکربندی می‌شود، Database Engine اطلاعات عملیات Insert، Update و Delete جدول‌های تحت پایش را در جدول‌های متناظر CDC ذخیره می‌کند. یکی از هدف‌های نگه‌داری تغییرها در جدول‌های جداگانه، اجرای عملیات استخراج، تبدیل و بارگذاری (Extract, Transform, Load یا ETL) بدون اثر منفی بر جدول مبدأ است.

در دو نسخهٔ قبلی Integration Services، توسعهٔ Package برای بازیابی داده از جدول‌های CDC و بارگذاری نتیجه در مقصد به چند مرحله نیاز داشت. Microsoft برای گسترش توانایی Integration Services در SQL Server 2012 و پشتیبانی از CDC، با Attunity، عرضه‌کنندهٔ نرم‌افزار یکپارچه‌سازی بلادرنگ داده، همکاری کرد. در نتیجه Componentهای جدید CDC برای Control Flow و Data Flow ارائه شدند و ساخت Packageهای مربوط به CDC ساده‌تر شد.

CDC در Control Flow

برای مدیریت پردازش Change Data با Integration Services دو نوع Package لازم است: Initial Load Package برای اجرای یک‌باره و Trickle-Feed Package برای اجرای پیوسته و زمان‌بندی‌شده. Componentها در هر دو یکسان‌اند، اما Control Flow متفاوت پیکربندی می‌شود. هر Package یک Variable از نوع String دارد تا وضعیت جاری پردازش را برای Componentهای CDC نگه دارد.

Control Flow با CDC Control Task آغاز می‌شود تا شروع Initial Load علامت‌گذاری یا بازهٔ Log Sequence Number یا LSN قابل پردازش در اجرای Trickle-Feed مشخص شود. سپس Data Flow Task شامل Componentهای CDC، Initial Load یا Change Data را پردازش می‌کند. Control Flow با CDC Control Task دیگری پایان می‌یابد که پایان Initial Load یا پردازش موفق بازهٔ LSN را ثبت می‌کند.

در CDC Control Task آغاز Trickle-Feed، ADO.NET Connection Manager اتصال به پایگاه‌دادهٔ SQL Server دارای CDC را تعریف می‌کند. عملیات کنترلی CDC و نام CDC State Variable نیز تعیین می‌شوند. می‌توان وضعیت CDC را به‌صورت اختیاری در جدول ماندگار کرد. اگر از جدول استفاده نشود، Package باید پس از پایان پردازش وضعیت را در Persistent Store بنویسد و پیش از اجرای بعدی آن را بخواند.

CDC در Data Flow

برای پردازش دادهٔ تغییریافته، Data Flow Task با CDC Source و CDC Splitter آغاز می‌شود. CDC Source دادهٔ تغییریافته را مطابق مشخصات CDC Control Task استخراج می‌کند و CDC Splitter هر ردیف را بررسی می‌کند تا Insert، Update یا Delete بودن تغییر را تعیین کند. سپس Componentهای مناسب به هر خروجی CDC Splitter متصل می‌شوند.

CDC Source

در CDC Source Editor، ADO.NET Connection Manager پایگاه‌داده، جدول و Capture Instance متناظر انتخاب می‌شوند. هم پایگاه‌داده و هم جدول باید در SQL Server برای CDC پیکربندی شده باشند. Processing Mode تعیین می‌کند همهٔ Change Dataها یا فقط Net Changeها پردازش شوند. CDC State Variable باید با Variable تعریف‌شده در CDC Control Task پیش از Data Flow Task یکسان باشد. Check Box با نام Include Reprocessing Indicator Column نیز می‌تواند ردیف‌های بازپردازش‌شده را برای رسیدگی جداگانه به خطا مشخص کند.

CDC Splitter

CDC Splitter از مقدار ستون _$operation برای تعیین نوع تغییر هر ردیف ورودی استفاده می‌کند و آن را به خروجی InsertOutput، UpdateOutput یا DeleteOutput می‌فرستد. این Transformation تنظیمی ندارد؛ Componentهای پایین‌دستی پردازش هر خروجی را جداگانه انجام می‌دهند.

طراحی انعطاف‌پذیر Package

در آغاز توسعه ممکن است استفاده از مقدارهای Hard-coded در Propertyها و Expressionها برای آزمایش منطق آسان‌تر باشد، اما برای بیشترین انعطاف باید از Variable استفاده کرد. ادامهٔ فصل بهبودهای Variable و Expression را بررسی می‌کند.

Variableها

یکی از مشکلات رایج، Scope اشتباه Variable بود. اگر هنگام افزودن Variable یک Task در Control Flow انتخاب شده بود، Variable در Scope همان Task ساخته می‌شد و Scope قابل تغییر نبود؛ بنابراین باید Variable حذف، انتخاب Task پاک و Variable دوباره در Scope Package ساخته می‌شد.

اکنون Variable جدید به‌طور پیش‌فرض در Scope خود Package ساخته می‌شود. برای تغییر Scope:

1. در پنجرهٔ Variables، Variable را انتخاب و دکمهٔ Move Variable در Toolbar را بزنید.
2. در Select New Scope، Executable موردنظر، شامل Package، Event Handler، Container یا Task، را انتخاب و OK کنید.

Expressionها

بهبودهای Expression، محدودیت اندازهٔ Result را رفع و Functionهای جدیدی به SQL Server Integration Services Expression Language اضافه می‌کنند.

طول نتیجهٔ Expression

در نسخه‌های پیشین اگر Result از نوع DT_WSTR یا DT_STR بود، کاراکترهای بیش از ۴۰۰۰ قطع می‌شدند. Result میانی بیش از این حد نیز Truncate می‌شد. این محدودیت اکنون حذف شده است.

Functionهای جدید

• LEFT: بخش چپ رشته را بدون استفاده از SUBSTRING برمی‌گرداند:

  LEFT(character_expression,number)

• REPLACENULL: مقدار NULL آرگومان نخست را با Expression دوم جایگزین می‌کند:

  REPLACENULL(expression, expression)

• TOKEN: رشته را با Delimiter به Token تقسیم و Occurrence تعیین‌شده را برمی‌گرداند:

  TOKEN(character_expression, delimiter_string, occurrence)

• TOKENCOUNT: شمار Tokenهای به‌دست‌آمده با Delimiter را برمی‌گرداند:

  TOKENCOUNT(character_expression, delimiter_string)

مدل‌های استقرار

علاوه بر تغییرهای گستردهٔ توسعهٔ Package در SSDT، مفهوم Deployment Model نیز دگرگون شده است.

مدل‌های استقرار پشتیبانی‌شده

• Package Deployment Model: مدل نسخه‌های پیشین که واحد استقرار در آن Package منفرد ذخیره‌شده به‌صورت فایل DTSX است. Package در فایل‌سیستم یا پایگاه‌دادهٔ MSDB مستقر می‌شود. حتی اگر Packageها گروهی Deploy شوند و Dependency داشته باشند، شیء یکپارچه‌ای برای معرفی مجموعه Packageهای مرتبط وجود ندارد.

• Package Deployment Model، ادامه: برای تغییر Propertyهای Task در زمان اجرا، Configهای ذخیره‌شده در فایل‌های DTSCONFIG استفاده می‌شوند. اجرای Package روی Integration Services Server با DTExec یا DTExecUI انجام می‌شود و مقدار Propertyها با آرگومان خط فرمان، رابط گرافیکی یا Configuration بازنویسی می‌شود.
• Project Deployment Model: واحد استقرار Project ذخیره‌شده در فایل ISPAC است؛ مجموعه‌ای از Packageها و Parameterها. Project در Integration Services Catalog مستقر می‌شود. به‌جای Configuration، Parameterها مقدار Propertyها را در زمان اجرا تعیین می‌کنند. پیش از اجرا، Execution Object در Catalog ساخته و در صورت نیاز Parameter Value یا Environment Reference به آن تخصیص داده می‌شود. سپس Execution Object از رابط SSMS، Stored Procedure یا Managed Code آغاز می‌شود.

Project جدید در SSDT به‌طور پیش‌فرض Project Deployment Model است. فرمان Convert To Package Deployment Model در منوی Project یا منوی راست‌کلیک Project، آن را تبدیل می‌کند، به شرط سازگاری؛ مثلاً Project دارای Parameter، که فقط در Project Deployment وجود دارد، قابل تبدیل نیست. پس از تبدیل Label جدیدی کنار نام Project ظاهر می‌شود، پوشهٔ Parameters حذف و Data Sources دوباره افزوده می‌شود.

قابلیت‌های Project Deployment Model

مزیت اصلی مدل جدید، مدیریت بهتر Package در چند محیط است. Package معمولاً روی یک Server توسعه، روی Server دیگری آزمایش و در Production اجرا می‌شود. مدل قدیمی برای Connection String محیط صحیح، به حداقل یک Configuration File و گاهی SQL Server Table یا Environment Variable نیاز داشت؛ راهی انعطاف‌پذیر ولی گیج‌کننده و مستعد خطا. مدل جدید همچنان مقدارهای زمان اجرا را از Package جدا می‌کند، اما آن‌ها را در Object Collectionهای Catalog نگه می‌دارد و روابط Package با Parameter، Environment و Environment Variable را تعریف می‌کند.

• Catalog: پایگاه‌داده‌ای اختصاصی برای Package و اطلاعات پیکربندی زمان اجرا؛ مدیریت از Stored Procedure و Viewهای Catalog یا رابط SSMS.
• Parameter: برای تغییر Propertyهای Task هنگام اجرا؛ در Scope پروژه یا Package ساخته می‌شود. Project Parameter بین همهٔ Packageها مشترک است و مانند Variable در Expression یا Task استفاده می‌شود.
• Environment: Containerی از Variableها که در زمان اجرا به Package متصل می‌شود. یک Package می‌تواند چند Environment داشته باشد ولی در هر اجرا فقط یکی فعال است؛ مانند Development، Test و Production.
• Environment Variable: مقدار Literalی که هنگام اجرا به Parameter تخصیص داده می‌شود. پس از Deploy، Parameter به Environment Variable مرتبط می‌شود و مقدار هنگام اجرا Resolve می‌گردد.

گردش‌کار Project Deployment

این Workflow هم تبدیل Objectهای Design-Time در SSDT به Objectهای پایگاه‌داده‌ای Catalog و هم بازیابی Object از Catalog برای Update یا استفاده به‌عنوان Template را پوشش می‌دهد. فایل ISPAC در چهار مرحله نقش دارد: Build، Deploy، Import و Convert.

Build

Project شامل یک یا چند Package در SSDT توسعه می‌یابد. برای Deploy به Catalog، Project Build و فایل ISPAC شامل اطلاعات Project، تمام Packageها و Parameterها ساخته می‌شود.

پیش از Build ممکن است دو کار لازم باشد:

• تعیین Entry-Point Package: اگر Package‌ای اجرای مستقیم یا غیرمستقیم Packageهای دیگر را آغاز می‌کند، روی آن راست‌کلیک و Entry-Point Package انتخاب شود تا مدیر Package آغازگر را تشخیص دهد.

• ساخت Project و Package Parameter: Parameterها مقدار لازم برای Task یا Expression را در زمان اجرا می‌دهند. در SSDT Design Default تعیین و در صورت نیاز Parameter به‌صورت Required علامت‌گذاری می‌شود تا بدون مقدار اجرا نشود.

هنگام توسعه، SSDT برای اجرای آزمایشی Task یا Package فایل ISPAC را در پوشهٔ bin Project می‌سازد. پس از پایان توسعه، از منوی Build یا کلید F5 برای آماده‌سازی ISPAC استفاده کنید.

Deploy

فرایند Deploy با ISPAC، Objectهای پایگاه‌داده‌ای Project، Package و Parameter را در Catalog می‌سازد. Integration Services Deployment Wizard نام Project مبدأ و Project مقصدی را که باید ساخته یا Update شود می‌گیرد. مقدار Literal یا Environment Variable نیز می‌تواند Server Default فعلی Parameter باشد. مقدارهای Wizard در Catalog ذخیره و Design Default داخل Package را Override می‌کنند.

Wizard از SSDT با راست‌کلیک Project و انتخاب Deploy یا با Double-click فایل ISPAC روی File System اجرا می‌شود.

Import

برای Update Package مستقرشده یا استفاده از آن به‌عنوان پایهٔ Package جدید، Project از Catalog یا ISPAC به SSDT Import می‌شود. Integration Services Import Project Wizard در فهرست Templateهای Project جدید قرار دارد.

Convert

Packageها و Configuration Fileهای قدیمی را می‌توان به نسخهٔ جدید Integration Services تبدیل کرد. Integration Services Project Conversion Wizard در SSDT و SSMS موجود است؛ Integration Services Package Upgrade Wizard نیز در صفحهٔ Tools در SQL Server Installation Center قرار دارد.

در SSDT، Project را باز، روی آن راست‌کلیک و Convert To Project Deployment Model را انتخاب کنید. Wizard فایل DTPROJ و فایل‌های DTSX را Upgrade می‌کند. در SSMS روی Projects زیر Catalog راست‌کلیک و Import Packages را انتخاب کنید؛ Wizard مقصد را می‌گیرد و ISPAC جدید می‌سازد.

گام‌های مشترک Upgrade:

• Update Execute Package Task: External Reference به DTSX به Project Reference برای Package همان Project تبدیل می‌شود. Child Package باید در Project و فهرست تبدیل باشد.
• ساخت Parameter: Configurationها می‌توانند به Parameter تبدیل شوند. Configuration Projectهای دیگر را نیز می‌توان افزود و Configurationها را از Package ارتقایافته حذف کرد. Wizard Propertyهای قابل تبدیل و Scope پروژه یا Package را دریافت می‌کند.
• پیکربندی Parameter: Server Value هر Parameter و Required بودن آن تعیین می‌شود.

Parameterها

Parameter در Project Deployment Model جایگزین Configuration است و اجازه می‌دهد بدون بازکردن Package، مقدارهای زمان اجرا تغییر کنند. Project-Level Parameter می‌تواند Propertyهای چند Package را مقداردهی کند؛ Package-Level Parameter فقط Propertyهای یک Package را پوشش می‌دهد.

Project Parameter

مقدار Project Parameter میان همهٔ Packageهای Project مشترک است. مراحل ساخت در SSDT:

1. در Solution Explorer روی Project.params دوبار کلیک کنید.
2. در Toolbar پنجره دکمهٔ Add Parameter را بزنید.
3. Name، Data Type و Value را تعیین کنید. این مقدار Design Default Value است.
4. فایل را ذخیره کنید.

Propertyهای اختیاری:

• Sensitive: پیش‌فرض False است. با True شدن، مقدار هنگام Deploy رمزگذاری می‌شود و در SSMS یا Viewهای T-SQL به‌صورت NULL دیده می‌شود؛ برای Connection Stringهای دارای Credential مهم است.
• Required: پیش‌فرض False. با True شدن باید هنگام یا پس از Deploy مقدار تعیین شود؛ Engine، Design Default را هنگام Deploy نادیده می‌گیرد.
• Description: مستندسازی برای مدیر Packageهای Catalog.

Package Parameter

فقط در Package محل ساخت معتبر است و با Package دیگر به اشتراک گذاشته نمی‌شود. زبانهٔ وسط Package Designer پنجرهٔ Parameters را باز می‌کند و رابط آن با Project Parameter یکسان است.

استفاده از Parameter

Parameter مانند Variable در Expressionهای Task، Data Flow Component یا Connection Manager استفاده می‌شود. در Expression Builder، Parameter در فهرست Variables And Parameters دیده و به Expression Text Box کشیده می‌شود. Evaluate Expression نتیجه را با Design Default نشان می‌دهد.

برای مقداردهی مستقیم Property یک Task، روی Task راست‌کلیک و Parameterize را انتخاب کنید. در پنجرهٔ Parameterize، Property و سپس Parameter جدید یا موجود انتخاب می‌شود. هنگام ساخت Parameter جدید، Propertyهای آن و Scope پروژه یا Package تعیین می‌شوند.

مقدار Parameter پس از Deploy

Design Default معمولاً برای تست در SSDT است. هنگام Deploy می‌توان Server Default در Deployment Wizard تعیین کرد یا هنگام ساخت Execution Object، Execution Value پیکربندی کرد.

شکل ۶-۲۲ مرحلهٔ ساخت هر نوع مقدار را نشان می‌دهد. اگر Execution Value وجود نداشته باشد، Engine از Server Default استفاده می‌کند؛ اگر آن هم وجود نداشته باشد، Design Default به کار می‌رود. Parameter Required باید Server Default یا Execution Value داشته باشد.

Server Default Value

Server Default می‌تواند Literal یا Environment Variable Reference باشد. در SSMS روی Project یا Package زیر Integration Services راست‌کلیک، Configure را انتخاب و Value مربوط به Parameter را تغییر دهید. این مقدار حتی اگر Design Default در SSDT تغییر و Project دوباره Deploy شود، باقی می‌ماند.

Execution Parameter Value

فقط به یک اجرای مشخص مربوط است و همهٔ مقدارهای دیگر را Override می‌کند. باید با Stored Procedure زیر صریحاً تعیین شود؛ در SSMS رابط گرافیکی برای آن وجود ندارد:

set_execution_parameter_value [ @execution_id = execution_id
            , [ @object_type = ] object_type
            , [ @parameter_name = ] parameter_name
            , [ @parameter_value = ] parameter_value

• execution_id: شناسهٔ Execution Instance که از View با نام catalog.executions به‌دست می‌آید.
• object_type: مقدار ۲۰ برای Project Parameter و ۳۰ برای Package Parameter.
• parameter_name: باید با نام Parameter در Catalog یکسان باشد.
• parameter_value: مقدار Execution Parameter.

Integration Services Catalog

Catalog قابلیت جدیدی برای تمرکز ذخیره‌سازی و مدیریت Packageها و اطلاعات پیکربندی مرتبط است. هر نمونهٔ SQL Server فقط یک Catalog می‌تواند داشته باشد. Project در مدل Project Deployment همراه Componentهایش به Catalog افزوده و در صورت انتخاب در Folder قرار می‌گیرد. هر Folder یا Root محتوا را به دو گروه Projects و Environments تقسیم می‌کند.

ایجاد Catalog

نصب Integration Services خودکار Catalog نمی‌سازد. مراحل:

1. در SSMS به نمونه متصل، روی Integration Services Catalogs راست‌کلیک و Create Catalog را انتخاب کنید.
2. در Create Catalog می‌توان Enable Automatic Execution Of Integration Services Stored Procedure At SQL Server Startup را فعال کرد. Procedure هنگام Restart عملیات Cleanup انجام می‌دهد و وضعیت Packageهایی را که هنگام توقف Service در حال اجرا بودند تنظیم می‌کند.
3. نام Catalog قابل تغییر نیست و SSISDB است. Password قوی وارد و OK کنید. Password، Database Master Key لازم برای رمزگذاری دادهٔ حساس Catalog را می‌سازد.

پس از ساخت، SSISDB دو بار در Object Explorer دیده می‌شود: زیر Databases و زیر Integration Services. در Databases مانند هر پایگاه‌داده Objectها بررسی می‌شوند؛ Node مربوط به Integration Services برای کارهای مدیریتی است.

Propertyهای Catalog

روی SSISDB زیر Integration Services راست‌کلیک و Properties را انتخاب کنید تا Catalog Properties باز شود.

Encryption

الگوریتم پیش‌فرض AES_256 است. با قرار دادن SSISDB در Single-User Mode می‌توان یکی از الگوریتم‌های DES، TRIPLE_DES، TRIPLE_DES_3KEY، DESX، AES_128 یا AES_192 را انتخاب کرد.

Integration Services با Encryption مقدارهای حساس Parameter را حفاظت می‌کند؛ هنگام Query کردن Catalog با SSMS یا API، مقدار به‌صورت NULL نمایش داده می‌شود.

Operationها

فعالیت‌هایی مانند Package Execution، Project Deployment و Project Validation در Tableهای Catalog ثبت می‌شوند. پایش با API یا با راست‌کلیک SSISDB و انتخاب Active Operations انجام می‌شود. پنجره شناسه، نوع، نام، زمان آغاز و Caller هر Operation را نشان می‌دهد و با Stop می‌توان Operation انتخابی را پایان داد.

دادهٔ قدیمی باید دوره‌ای Purge شود تا Catalog بی‌جهت بزرگ نشود. Propertyهای Catalog تعداد روزهای نگه‌داری را برای SQL Server Agent Job پاک‌سازی تعیین می‌کنند و Job را می‌توان غیرفعال کرد.

Project Versioning

هر بار Project هم‌نام در همان Folder دوباره Deploy شود، نسخهٔ قبلی تا سقف ده نسخه در Catalog می‌ماند. برای Restore:

1. Project را زیر SSISDB پیدا کنید.
2. روی آن راست‌کلیک و Versions را انتخاب کنید.
3. در Project Versions نسخه را انتخاب و Restore To Selected Version را بزنید.
4. Yes و سپس OK را بزنید. نسخهٔ انتخابی Current می‌شود و نسخهٔ دیگر همچنان برای Restore باقی می‌ماند.

حداکثر نسخه‌های نگه‌داری‌شده با Catalog Property قابل تغییر است. افزایش بالاتر از ده نیازمند پایش اندازهٔ SSISDB است. SQL Server Agent Job نیز می‌تواند نسخه‌های قدیمی را دوره‌ای حذف کند.

Objectهای Environment

پس از Deploy می‌توان Environmentها را همراه Parameterها برای تغییر مقدار زمان اجرا ساخت. Environment مجموعه‌ای از Environment Variableهاست؛ هر Variable مقداری را به Parameter می‌دهد و Environment Reference رابطهٔ Environment و Project را برقرار می‌کند.

Environmentها

می‌توان برای هر Server اجرای Package یک Environment، مثلاً Development، Test و Production ساخت:

1. زیر SSISDB پوشهٔ Environments متناظر با Folder پروژه را پیدا کنید.
2. روی آن راست‌کلیک و Create Environment را انتخاب کنید.
3. Name و در صورت نیاز Description را وارد و OK کنید.

Environment Variableها

Propertyهای Environment Variable مشابه Parameter هستند، زیرا مقدار Parameter را در زمان اجرا جایگزین می‌کنند. برای ساخت، Environment را زیر SSISDB پیدا کنید.

2. روی Environment راست‌کلیک و Properties را باز کنید.
3. Variables را انتخاب کنید.
4. در ردیف خالی Name، Type، Description اختیاری و Value را وارد کنید و در صورت نیاز Sensitive را فعال کنید. Variableهای دیگر را نیز اضافه و OK کنید.
5. همان مجموعه Variableها را به Environmentهای دیگری که با Project استفاده می‌شوند اضافه کنید.

Environment Referenceها

برای اتصال Environment Variable به Parameter، Environment Reference ساخته می‌شود. Reference می‌تواند Relative یا Absolute باشد. در Relative، Environment Folder و Project Folder باید Parent مشترک داشته باشند؛ جابه‌جایی Package بدون Environment باعث شکست اجرا می‌شود. Absolute رابطه را بدون نیاز به Parent مشترک حفظ می‌کند.

Environment Reference یک Property پروژه است:

1. Project را زیر SSISDB پیدا کنید.
2. روی آن راست‌کلیک و Configure را انتخاب کنید.
3. References را برای نمایش Referenceهای موجود انتخاب کنید.

4. Add را بزنید و Environment را در Browse Environments انتخاب کنید. Local Folder برای Relative و SSISDB برای Absolute است.
5. دو بار OK کنید و برای Environmentهای دیگر تکرار کنید.
6. در Configure Project به Parameters بروید.
7. دکمهٔ Ellipsis کنار Value را بزنید، Use Environment Variable را انتخاب و Variable مربوط را از Drop-down برگزینید.
8. دو بار OK کنید.

برای Project می‌توان چند Reference ساخت، اما در هر Package Execution فقط یک Environment فعال است. Integration Services مقدار Environment Variable را بر اساس Environment مرتبط با Execution Instance جاری ارزیابی می‌کند.

مدیریت

پس از توسعه و Deploy، کارهای مدیریتی برای ادامهٔ عملیات Server اهمیت دارند.

Validation

پیش از اجرا می‌توان احتمال موفقیت Project و Package را بررسی کرد، به‌ویژه وقتی Parameterها از Environment Variable استفاده می‌کنند. Validation وجود Server Default برای Parameter Required، اعتبار Environment Reference و سازگاری Data Type میان Parameter پروژه و Package و Environment Variable متناظر را کنترل می‌کند.

روی Project یا Package در Catalog راست‌کلیک، Validate را انتخاب و Environmentهای شامل در بررسی، همه، هیچ‌کدام یا یک مورد مشخص، را تعیین کنید. Validation Asynchronous است؛ نتیجه در Integration Services Dashboard، Active Operations یا API دیده می‌شود.

Package Execution

پس از Deploy و پیکربندی اختیاری Parameter و Environment Reference، باید Objectی به نام Execution ساخته شود. Execution ترکیب یکتای Package و Parameter Valueهای آن، شامل Server Default یا Environment Reference است. برای ساخت و آغاز:

1. Entry-Point Package را زیر SSISDB پیدا کنید.

2. روی Project راست‌کلیک و Execute را انتخاب کنید.
3. یا دکمهٔ Ellipsis کنار Value را برای Literal Execution Value بزنید، یا Environment را فعال و Environment موردنظر را از Drop-down انتخاب کنید.

Connection Managerها در زبانهٔ Connection Managers و Override کردن Property و Logging در Advanced قابل تنظیم‌اند. با OK اجرا آغاز می‌شود. چون Asynchronous است، پنجره لازم نیست باز بماند. Dashboard، Active Operations یا API برای پایش استفاده می‌شود.

برای زمان‌بندی، معمولاً Script T-SQL آغاز Execution ساخته و در فایل ذخیره می‌شود. SQL Server Agent Job با Step Type از نوع Operating System (CmdExec)، ابزار sqlcmd.exe را اجرا و Script را به‌عنوان Argument می‌دهد. Job با Service Account یا Proxy Account اجرا می‌شود و حساب باید مجوز ساخت و آغاز Execution را داشته باشد.

Logging و ابزارهای عیب‌یابی

تمرکز Package Storage و Execution روی Server، Logging سمت Server و گزارش‌های عملیاتی SSMS را برای پایش و رفع خطا فراهم می‌کند.

Package Execution Log

در Packageهای قدیمی یا Log Provider در هر Package پیکربندی و به Executableها متصل می‌شد، یا با Execute SQL Statement و Script Component راهکار Logging سفارشی ساخته می‌شد؛ هر دو زمان‌بر بودند.

بدون هیچ پیکربندی، Integration Services دادهٔ اجرا را در جدول [catalog].[executions] ذخیره می‌کند. ستون‌های مهم شامل Start Time، End Time و Status هستند. اطلاعات Environment مانند Physical Memory، Page File Size و CPUهای موجود نیز ثبت می‌شوند. Tableهای دیگر Parameter Valueهای اجرا، مدت هر Executable و Messageهای تولیدشده را نگه می‌دارند. می‌توان Queryهای Ad Hoc یا گزارش Reporting Services سفارشی ساخت.

Data Tap

Data Tap شبیه Data Viewer است، اما داده را در نقطه‌ای از Pipeline هنگام اجرای Package خارج SSDT ثبت می‌کند. Stored Procedure با نام catalog.add_data_tap روی Package مستقرشده در SSIS، Data Flow را Tap می‌کند. داده در فایل CSV ذخیره می‌شود و Package نیازی به تغییر ندارد.

Reportها

پیش از ساخت گزارش سفارشی، گزارش‌های داخلی SSMS را بررسی کنید. آن‌ها نتیجهٔ اجرا در ۲۴ ساعت گذشته، Performance و Error Message اجرای ناموفق را ارائه می‌کنند و Hyperlinkها از Summary به Detail می‌روند.

برای مشاهدهٔ Reportها روی SSISDB راست‌کلیک، Reports و سپس Standard Reports را انتخاب کنید. گزارش‌های موجود:

• All Executions
• All Validations
• All Operations
• Connections

امنیت

Packageها و Objectهای مرتبط با Encryption در Catalog ذخیره می‌شوند. فقط اعضای نقش جدید ssis_admin یا نقش sysadmin به همهٔ Objectها دسترسی دارند و می‌توانند Catalog و Folder بسازند و Stored Procedureها را اجرا کنند.

اعضای نقش‌های مدیریتی می‌توانند مجوز مدیریت Folder مشخص را به User واگذار کنند تا نیازی به نقش پرامتیاز نباشد. برای Folder-Level Access مجوز MANAGE_OBJECT_PERMISSIONS داده می‌شود.

برای مدیریت عمومی Permission، Properties یک Folder یا Securable Object را باز و به Permissions بروید؛ Security Principal را انتخاب و Grant یا Deny مناسب را تعیین کنید. این روش برای Folder، Project، Environment و Operation کاربرد دارد.

قالب فایل Package

Packageهای قدیمی DTSX به‌صورت XML بودند، اما ساختارشان برای Diff Tool و Source Control مناسب نبود. در نسخهٔ جدید فایل Pretty-Printed است، Propertyها به‌جای Element به‌شکل Attribute ذخیره می‌شوند، Attributeها الفبایی‌اند و Attributeهای دارای Default Value حذف شده‌اند. این تغییرها یافتن اطلاعات، مقایسهٔ خودکار و Merge Packageهای بدون Conflict را آسان‌تر می‌کنند.

Numeric Lineage Identifierهای بی‌معنا با Attributeی به نام refid و مقدار متنی مسیر Object جایگزین شده‌اند. نمونهٔ Refid برای نخستین Input Column در Aggregate Transformation داخل Data Flow Task:

Package\Data Flow Task\Aggregate.Inputs[Aggregate Input 1].Columns[LineTotal]

Annotationها نیز دیگر Binary Stream نیستند و به‌صورت Clear Text در XML ظاهر می‌شوند؛ بنابراین استخراج برنامه‌ای آن‌ها برای مستندسازی آسان‌تر است.

این صفحه در نسخهٔ اصلی عمداً بدون محتوای متنی است.