این راهنما یکی از فصل‌های راهنمای جامع Wait Typeهای رایج SQL Server است و انتظار ASYNC_NETWORK_IO را از تعریف پایه تا عیب‌یابی حرفه‌ای، مثال‌های اجرایی و تصمیم اصلاحی بررسی می‌کند.

مقدمه و اهمیت مسئله

ASYNC_NETWORK_IO یکی از Wait Typeهای مرتبط با «مصرف نتیجه و شبکه» است. Wait Stats زبان مشاهده توقف‌های درونی موتور SQL Server هستند، اما هر توقف الزاماً مشکل نیست؛ موتور برای I/O، Lock، Worker، حافظه یا هماهنگی بین Taskها به‌طور طبیعی منتظر می‌ماند. مسئله زمانی آغاز می‌شود که نرخ و مدت انتظار با کندی واقعی، افت Throughput یا نقض SLA هم‌زمان شود.

این انتظار زمانی شکل می‌گیرد که SQL Server نتیجه را روی شبکه نوشته اما برنامه Client هنوز داده را با سرعت کافی مصرف یا تأیید نکرده است. علت می‌تواند پردازش ردیف‌به‌ردیف در برنامه، نتیجه بسیار بزرگ، فشار منابع Client یا تأخیر واقعی شبکه باشد. در یک عیب‌یابی قابل اتکا باید سه سطح از هم جدا شوند: آمار تجمعی Instance، Request و Task فعال در لحظه، و شاخص تخصصی زیرسیستم. این تفکیک مانع آن می‌شود که یک مقدار قدیمی یا طبیعی به‌عنوان Root Cause معرفی شود.

اثر کسب‌وکاری این انتظار می‌تواند چنین باشد: باز ماندن Request و Transaction، اشغال Connection و حافظه و گاهی طولانی‌تر شدن Lockها. هدف مقاله صفر کردن ASYNC_NETWORK_IO نیست؛ هدف این است که سهم زیان‌آور آن مشخص، علت قابل کنترل پیدا و نتیجه اصلاح با داده قبل و بعد اثبات شود.

تعریف فنی ASYNC_NETWORK_IO

این انتظار زمانی شکل می‌گیرد که SQL Server نتیجه را روی شبکه نوشته اما برنامه Client هنوز داده را با سرعت کافی مصرف یا تأیید نکرده است. علت می‌تواند پردازش ردیف‌به‌ردیف در برنامه، نتیجه بسیار بزرگ، فشار منابع Client یا تأخیر واقعی شبکه باشد. نام Wait Type یک برچسب تشخیصی است، نه Error Code و نه دستوری که مستقیماً اجرا شود. شمارنده‌ها از شروع سرویس یا آخرین پاک‌سازی ثبت می‌شوند و ممکن است ساعت‌ها یا روزها رفتارهای متفاوت را در یک مقدار جمع کنند.

قاعده طلایی: ASYNC_NETWORK_IO را فقط وقتی اولویت دهید که Delta آن در پنجره کندی رشد کند، Request متاثر پیدا شود و شاخص تخصصی «مصرف نتیجه و شبکه» همان داستان را تأیید کند.

Query پایه و نحو مشاهده

این Query امن و Read-only، ردیف ASYNC_NETWORK_IO را از DMV سراسری Wait Stats می‌خواند. برای اجرای DMVهای سطح Server معمولاً Permission مناسب مشاهده وضعیت سرور یا Permission معادل نسخه لازم است.

SELECT
        wait_type,
        waiting_tasks_count,
        wait_time_ms,
        signal_wait_time_ms
    FROM sys.dm_os_wait_stats
    WHERE wait_type = N'ASYNC_NETWORK_IO';

معنای ستون‌های کلیدی

• wait_type: نام دسته انتظار؛ در این مقاله مقدار هدف ASYNC_NETWORK_IO است.
• waiting_tasks_count: تعداد دفعات آغاز انتظار، نه تعداد Session یکتا.
• wait_time_ms: کل زمان انتظار و شامل signal_wait_time_ms است.
• signal_wait_time_ms: زمانی که Task آماده اجرا بوده اما برای Scheduler منتظر مانده است.
• wait_resource و resource_description: جزئیات منبع فقط در DMVهای Request و Waiting Task ظاهر می‌شوند.

نوع خروجی و دامنه آمار

خروجی DMV مجموعه‌ای از شمارنده‌های bigint و نام انتظار nvarchar است. آمار sys.dm_os_wait_stats در سطح Instance تجمع می‌یابد؛ بنابراین برای نسبت دادن ASYNC_NETWORK_IO به یک Database یا Query باید Snapshot لحظه‌ای، متن SQL و داده زیرسیستم را اضافه کرد.

علت‌های رایج و مسیر تشخیص

علت‌های محتمل باید به‌عنوان فرضیه مرتب شوند، نه حکم قطعی. برای ASYNC_NETWORK_IO مهم‌ترین فرضیه‌ها عبارت‌اند از:

• 1. مصرف آهسته Result Set در برنامه
• 2. SELECT بدون محدودسازی ستون و ردیف
• 3. فیلتر کردن داده در Client به جای Server
• 4. CPU، حافظه یا شبکه ضعیف سمت Client

اقدام آغازین پیشنهادی این است: Session، تعداد ردیف ارسالی، متن Query، مشخصات Client و زمان مصرف Result Set را با هم بررسی کنید. سپس تنها فرضیه‌ای را تغییر دهید که چند شاهد مستقل آن را پشتیبانی می‌کند. برای نمونه، Wait Delta و DMV تخصصی باید با زمان پاسخ برنامه و Query Plan در یک Timeline مشترک قرار گیرند.

نام این انتظار به معنای قطعی بودن مشکل شبکه نیست؛ طراحی برنامه Client در بسیاری از رخدادها عامل اصلی است. همچنین ممکن است یک علت بالادستی چند Wait مختلف تولید کند؛ برای مثال Blocking می‌تواند workerها را اشغال و THREADPOOL بسازد، یا Plan پرخوانش هم PAGEIOLATCH و هم فشار CPU ایجاد کند. به همین دلیل رابطه زمانی مهم‌تر از رتبه ساده جدول Waitها است.

مثال‌های عملی و قابل اجرا

مثال 1: خواندن شمارنده تجمعی ASYNC_NETWORK_IO

اولین گام این است که وجود و اندازه تاریخی ASYNC_NETWORK_IO را ببینید. ستون wait_time_ms شامل signal_wait_time_ms نیز هست و مقدار از زمان Startup یا آخرین پاک‌سازی Wait Stats تجمع یافته است.

SELECT
        wait_type,
        waiting_tasks_count,
        wait_time_ms,
        signal_wait_time_ms,
        CAST(wait_time_ms * 1.0 /
             NULLIF(waiting_tasks_count, 0) AS decimal(18,2)) AS avg_wait_ms
    FROM sys.dm_os_wait_stats
    WHERE wait_type = N'ASYNC_NETWORK_IO';

این خروجی Baseline است و رخداد جاری را اثبات نمی‌کند. زمان Startup، workload و Delta بعدی را ثبت کنید تا درباره اهمیت ASYNC_NETWORK_IO نتیجه‌گیری شود.

مثال 2: محاسبه Delta پنج‌ثانیه‌ای ASYNC_NETWORK_IO

دو Snapshot کوتاه نشان می‌دهد در بازه مشاهده چه مقدار انتظار جدید ساخته شده است. برای محیط واقعی، بازه را با چرخه کاری سامانه هماهنگ کنید و Snapshotها را در جدول مانیتورینگ پایدار نگه دارید.

IF OBJECT_ID(N'tempdb..#WaitStart') IS NOT NULL
        DROP TABLE #WaitStart;
    
    SELECT wait_type, waiting_tasks_count, wait_time_ms, signal_wait_time_ms
    INTO #WaitStart
    FROM sys.dm_os_wait_stats
    WHERE wait_type = N'ASYNC_NETWORK_IO';
    
    WAITFOR DELAY '00:00:05';
    
    SELECT
        w.wait_type,
        w.waiting_tasks_count - ISNULL(b.waiting_tasks_count, 0) AS delta_tasks,
        w.wait_time_ms - ISNULL(b.wait_time_ms, 0) AS delta_wait_ms,
        w.signal_wait_time_ms - ISNULL(b.signal_wait_time_ms, 0) AS delta_signal_ms
    FROM sys.dm_os_wait_stats AS w
    LEFT JOIN #WaitStart AS b ON b.wait_type = w.wait_type
    WHERE w.wait_type = N'ASYNC_NETWORK_IO';

Delta را به نرخ بر ثانیه و تعداد تراکنش نرمال کنید. یک پنجره پنج‌ثانیه‌ای برای آموزش است و در سامانه کم‌ترافیک ممکن است نماینده نباشد.

مثال 3: یافتن Requestهای فعال روی ASYNC_NETWORK_IO

وقتی ASYNC_NETWORK_IO در لحظه رخ می‌دهد، Session، وضعیت، منبع انتظار و Blocker را یکجا ثبت کنید. این Snapshot به اتصال آمار Instance-level به رخداد واقعی کمک می‌کند.

SELECT
        r.session_id,
        DB_NAME(r.database_id) AS database_name,
        r.status,
        r.command,
        r.wait_time,
        r.wait_resource,
        r.blocking_session_id,
        r.cpu_time,
        r.total_elapsed_time
    FROM sys.dm_exec_requests AS r
    WHERE r.wait_type = N'ASYNC_NETWORK_IO'
    ORDER BY r.wait_time DESC;

اگر خروجی خالی است، انتظار در همان لحظه فعال نیست؛ این موضوع با بالا بودن مقدار تجمعی تناقض ندارد و اهمیت Capture دوره‌ای را نشان می‌دهد.

مثال 4: بررسی Taskها و Contextهای منتظر ASYNC_NETWORK_IO

یک Request می‌تواند چند Task داشته باشد، به‌ویژه در Plan موازی. sys.dm_os_waiting_tasks جزئیات worker و resource_description را برای تحلیل سطح پایین‌تر فراهم می‌کند.

SELECT
        wt.session_id,
        wt.exec_context_id,
        wt.wait_duration_ms,
        wt.wait_type,
        wt.blocking_session_id,
        wt.resource_description
    FROM sys.dm_os_waiting_tasks AS wt
    WHERE wt.wait_type = N'ASYNC_NETWORK_IO'
    ORDER BY wt.wait_duration_ms DESC;

تعداد Taskها را با DOP، Blocking و ماهیت مصرف نتیجه و شبکه تفسیر کنید؛ یک Task منفرد و کوتاه با صف گسترده و پایدار یکسان نیست.

مثال 5: نمایش متن SQL عامل ASYNC_NETWORK_IO

برای رسیدن از Wait به اقدام اصلاحی باید متن Batch و Statement جاری را ثبت کرد. Offsetها باعث می‌شوند بخش در حال اجرای Batch جدا از متن کامل نمایش داده شود.

SELECT
        r.session_id,
        r.wait_time,
        r.wait_resource,
        SUBSTRING(st.text,
                  (r.statement_start_offset / 2) + 1,
                  ((CASE r.statement_end_offset
                       WHEN -1 THEN DATALENGTH(st.text)
                       ELSE r.statement_end_offset
                    END - r.statement_start_offset) / 2) + 1) AS current_statement,
        st.text AS batch_text
    FROM sys.dm_exec_requests AS r
    OUTER APPLY sys.dm_exec_sql_text(r.sql_handle) AS st
    WHERE r.wait_type = N'ASYNC_NETWORK_IO'
    ORDER BY r.wait_time DESC;

متن Query ممکن است اطلاعات حساس داشته باشد؛ آن را در مخزن مانیتورینگ امن نگه دارید و برای اصلاح ASYNC_NETWORK_IO حتماً Execution Plan و پارامترها را نیز جمع‌آوری کنید.

مثال 6: مشاهده Client و Connection منتظر مصرف نتیجه

برای ASYNC_NETWORK_IO باید بدانید کدام برنامه و میزبان نتیجه را آهسته دریافت می‌کند. پیوند Request و Connection مشخصات شبکه و برنامه را در کنار تعداد ردیف پردازش‌شده نشان می‌دهد.

SELECT
        r.session_id,
        s.host_name,
        s.program_name,
        c.client_net_address,
        c.net_transport,
        r.row_count,
        r.wait_time
    FROM sys.dm_exec_requests AS r
    JOIN sys.dm_exec_sessions AS s ON s.session_id = r.session_id
    JOIN sys.dm_exec_connections AS c ON c.session_id = r.session_id
    WHERE r.wait_type = N'ASYNC_NETWORK_IO'
    ORDER BY r.wait_time DESC;

تعداد ردیف زیاد در کنار یک Client مشخص، بررسی Pagination، Projection ستون‌ها و سرعت پردازش DataReader را در اولویت قرار می‌دهد.

مثال 7: پیدا کردن Requestهای دارای Result Set بزرگ

row_count یک تقریب عملی برای حجم نتیجه جاری است و باید با طول ردیف و زمان اجرا تفسیر شود. این Query درخواست‌های کاربر را بر اساس ردیف پردازش‌شده مرتب می‌کند.

SELECT TOP (20)
        r.session_id,
        DB_NAME(r.database_id) AS database_name,
        r.status,
        r.row_count,
        r.reads,
        r.total_elapsed_time,
        LEFT(st.text, 250) AS sql_text
    FROM sys.dm_exec_requests AS r
    OUTER APPLY sys.dm_exec_sql_text(r.sql_handle) AS st
    WHERE r.session_id > 50
    ORDER BY r.row_count DESC;

به‌جای انتقال همه ستون‌ها، فیلتر، Aggregation و Pagination را تا حد ممکن در SQL Server انجام دهید و اثر آن را با تست برنامه بسنجید.

مثال 8: مقایسه پروتکل و تعداد Connectionهای Client

انباشت Connectionهای یک برنامه می‌تواند مدت اشغال منابع را افزایش دهد. گزارش زیر Connectionها را بر اساس برنامه، میزبان، پروتکل و نوع انتقال گروه‌بندی می‌کند.

SELECT
        s.program_name,
        s.host_name,
        c.net_transport,
        c.protocol_type,
        COUNT_BIG(*) AS connection_count
    FROM sys.dm_exec_connections AS c
    JOIN sys.dm_exec_sessions AS s ON s.session_id = c.session_id
    WHERE s.is_user_process = 1
    GROUP BY s.program_name, s.host_name, c.net_transport, c.protocol_type
    ORDER BY connection_count DESC;

Connection Pooling سالم مفید است، اما Connection باز با Result Set نیمه‌مصرف‌شده باید در کد Client بسته و Dispose شود.

مثال 9: مقایسه ASYNC_NETWORK_IO با Waitهای هم‌خانواده

Wait Typeها در خلأ تفسیر نمی‌شوند. مقایسه ASYNC_NETWORK_IO با OLEDB، CXCONSUMER، LCK_M_S کمک می‌کند بفهمید علامت اصلی به کدام زیرسیستم نزدیک‌تر است.

SELECT
        wait_type,
        waiting_tasks_count,
        wait_time_ms,
        signal_wait_time_ms,
        CAST(100.0 * wait_time_ms /
             NULLIF(SUM(wait_time_ms) OVER (), 0) AS decimal(10,2)) AS family_percent
    FROM sys.dm_os_wait_stats
    WHERE wait_type IN (N'ASYNC_NETWORK_IO', N'OLEDB', N'CXCONSUMER', N'LCK_M_S')
    ORDER BY wait_time_ms DESC;

سهم خانواده برای Prioritization مفید است، ولی شدت کسب‌وکاری را نشان نمی‌دهد. زمان پاسخ، SLA و تعداد درخواست متاثر را هم اضافه کنید.

مثال 10: ساخت قاعده هشدار مستقل برای Delta ASYNC_NETWORK_IO

در مانیتورینگ بهتر است روی Delta یک بازه ثابت و نرخ هر ثانیه هشدار بسازید، نه روی مقدار تجمعی از Startup. مثال مستقل زیر با داده نمونه منطق سطح‌بندی را نمایش می‌دهد و در سامانه مانیتورینگ با Snapshot واقعی جایگزین می‌شود.

DECLARE @WindowSeconds int = 60;
    DECLARE @WaitDelta TABLE
    (
        wait_type nvarchar(60),
        delta_wait_ms bigint,
        delta_tasks bigint
    );
    
    INSERT INTO @WaitDelta (wait_type, delta_wait_ms, delta_tasks)
    VALUES (N'ASYNC_NETWORK_IO', 8400, 38);
    
    SELECT
        wait_type,
        delta_wait_ms,
        delta_tasks,
        CAST(delta_wait_ms * 1.0 / @WindowSeconds AS decimal(18,2)) AS wait_ms_per_second,
        CASE
            WHEN delta_wait_ms >= 30000 THEN N'بحرانی'
            WHEN delta_wait_ms >= 5000 THEN N'نیازمند بررسی'
            ELSE N'عادی'
        END AS alert_level
    FROM @WaitDelta;

آستانه‌های نمونه عمومی نیستند. آن‌ها را از Baseline، ظرفیت و SLA سامانه خود استخراج کنید تا برای ASYNC_NETWORK_IO هشدار کاذب تولید نشود.

خطاهای رایج در تحلیل

خطای نخست، مرتب کردن sys.dm_os_wait_stats از زمان Startup و معرفی اولین ردیف به‌عنوان علت حادثه است. این کار workloadهای شبانه، Backup، Maintenance و ساعت‌های پرترافیک را مخلوط می‌کند. Snapshot اختلافی با Timestamp و شمارنده workload، تصویری قابل مقایسه می‌سازد.

خطای دوم، صفر کردن شمارنده‌ها پیش از ذخیره Baseline است. پاک‌سازی ممکن است در آزمایش کنترل‌شده مفید باشد، اما روی Production تاریخچه مشترک تیم را از بین می‌برد. روش بهتر ذخیره دو Snapshot و محاسبه Delta در جدول مانیتورینگ است.

خطای سوم، اجرای درمان عمومی برای نام Wait است. درباره ASYNC_NETWORK_IO باید این هشدار را جدی گرفت: نام این انتظار به معنای قطعی بودن مشکل شبکه نیست؛ طراحی برنامه Client در بسیاری از رخدادها عامل اصلی است. تغییر باید دامنه محدود، معیار موفقیت و Rollback داشته باشد و در سطح Query بر تغییر سراسری ترجیح داده شود، مگر آنکه داده خلاف آن را ثابت کند.

خطای چهارم، نادیده گرفتن Permission، نسخه و تفاوت محیط است. برخی DMVها در Azure یا نسخه‌های قدیمی ستون و دسترسی متفاوت دارند. Queryهای این مقاله Read-only هستند، اما اجرای آن‌ها باید با حساب مانیتورینگ دارای حداقل دسترسی و در پنجره مناسب انجام شود.

ملاحظات کارایی

خود Queryهای DMV معمولاً سبک‌اند، ولی Polling بسیار سریع، دریافت مکرر متن و Plan همه Sessionها یا نگهداری بدون سیاست داده مانیتورینگ هزینه ایجاد می‌کند. برای ASYNC_NETWORK_IO فاصله نمونه‌برداری را بر اساس مدت رخداد انتخاب کنید؛ حادثه چندثانیه‌ای به Capture کوتاه‌تر و روند ظرفیت به بازه طولانی‌تر نیاز دارد.

برای مقایسه، Delta را بر ثانیه، تراکنش یا Request نرمال کنید. افزایش مطلق Wait در روزی با دو برابر شدن بار لزوماً Regression نیست. در کنار آن p50، p95، p99، نرخ Timeout، CPU، I/O و Blocking را نگه دارید تا بهینه‌سازی یک معیار، معیار دیگری را خراب نکند.

اگر از Extended Events یا Query Store استفاده می‌کنید، Predicate و Retention محدود انتخاب کنید. ثبت متن و Plan ممکن است داده حساس داشته باشد؛ سطح دسترسی، Masking گزارش و مدت نگهداری باید بخشی از طراحی Performance Monitoring باشد.

بهترین روش‌ها

• برای ASYNC_NETWORK_IO Baseline ساعتی و روزانه متناسب با الگوی بار بسازید.
• شمارنده تجمعی را به Delta بازه‌ای تبدیل و زمان Startup را همراه Snapshot ذخیره کنید.
• Wait را به Session، Query، Execution Plan و شاخص زیرسیستم متصل کنید.
• Waitهای مرتبط مانند OLEDB، CXCONSUMER، LCK_M_S را برای یافتن زنجیره علت بررسی کنید.
• هر بار فقط یک تغییر قابل سنجش اعمال و نتیجه را روی workload هم‌سطح مقایسه کنید.
• درمان Query-level را پیش از تغییر سراسری Instance ارزیابی کنید.
• برای تغییر تنظیمات، Script بازگشت و معیار توقف مشخص داشته باشید.
• گزارش فنی را به SLA و اثر کاربر نهایی پیوند دهید.

سناریوی واقعی سازمانی

فرض کنید سامانه a00b در ساعت اوج کند می‌شود و ASYNC_NETWORK_IO در فهرست Waitها بالاست. تیم ابتدا به‌جای Restart یا تغییر تنظیمات، دو Snapshot شصت‌ثانیه‌ای می‌گیرد، Sessionهای فعال را ثبت و مشخص می‌کند رشد انتظار دقیقاً با کدام Endpoint یا Job هم‌زمان است.

در مرحله دوم، شاخص‌های «مصرف نتیجه و شبکه» و Query Plan بررسی می‌شوند. فرضیه‌های اصلی عبارت‌اند از مصرف آهسته Result Set در برنامه، SELECT بدون محدودسازی ستون و ردیف، فیلتر کردن داده در Client به جای Server. تیم یک اصلاح محدود را در محیط مشابه اجرا، workload یکسان را تکرار و Delta انتظار، p95 و مصرف منابع را با Baseline مقایسه می‌کند.

موفقیت فقط با پایین آمدن رتبه ASYNC_NETWORK_IO اعلام نمی‌شود؛ باید باز ماندن Request و Transaction، اشغال Connection و حافظه و گاهی طولانی‌تر شدن Lockها کاهش یافته باشد و Regression جدید در Waitهای مرتبط یا صحت خروجی ایجاد نشود. همین چرخه اندازه‌گیری، فرضیه، تغییر و اعتبارسنجی، عیب‌یابی را از حدس به مهندسی قابل دفاع تبدیل می‌کند.

سؤالات متداول

سؤال 1: ASYNC_NETWORK_IO دقیقاً چه زمانی در SQL Server ثبت می‌شود؟

این انتظار زمانی شکل می‌گیرد که SQL Server نتیجه را روی شبکه نوشته اما برنامه Client هنوز داده را با سرعت کافی مصرف یا تأیید نکرده است. علت می‌تواند پردازش ردیف‌به‌ردیف در برنامه، نتیجه بسیار بزرگ، فشار منابع Client یا تأخیر واقعی شبکه باشد. ثبت یک انتظار کوتاه بخشی طبیعی از زمان‌بندی موتور است؛ اهمیت زمانی ایجاد می‌شود که Delta آن با کندی قابل مشاهده و افت SLA هم‌زمان باشد.

سؤال 2: برای شروع تحلیل ASYNC_NETWORK_IO کدام DMVها مناسب‌اند؟

sys.dm_os_wait_stats برای روند Instance، sys.dm_exec_requests برای Request جاری و sys.dm_os_waiting_tasks برای Task و منبع انتظار نقطه شروع هستند. با توجه به دسته مصرف نتیجه و شبکه باید DMV تخصصی همان زیرسیستم و Execution Plan نیز افزوده شود.

سؤال 3: آیا زیاد بودن ASYNC_NETWORK_IO به معنی نیاز فوری به سخت‌افزار جدید است؟

خیر. نام این انتظار به معنای قطعی بودن مشکل شبکه نیست؛ طراحی برنامه Client در بسیاری از رخدادها عامل اصلی است. پیش از خرید باید هزینه اصلاح Query، تنظیمات، معماری برنامه و زیرساخت با اندازه‌گیری قبل و بعد مقایسه شود؛ یک ارزیابی فنی حرفه‌ای می‌تواند از هزینه اشتباه جلوگیری کند.

سؤال 4: چه زمانی تحلیل حرفه‌ای ASYNC_NETWORK_IO برای یک کسب‌وکار توجیه دارد؟

وقتی انتظار با افت فروش، Timeout، ناتمام ماندن Job، افزایش زمان پاسخ یا نقض SLA هم‌بسته است، تحلیل ساختاریافته ارزش تجاری دارد. مشاوره SQL Server در این مرحله باید خروجی قابل سنجش مانند کاهش p95 و نرخ انتظار ارائه کند، نه فقط تغییر چند تنظیم.

سؤال 5: تفاوت ASYNC_NETWORK_IO با OLEDB چیست؟

ASYNC_NETWORK_IO در دسته مصرف نتیجه و شبکه تفسیر می‌شود، در حالی که OLEDB مرحله یا منبع متفاوتی را برجسته می‌کند. هم‌زمانی این دو ممکن است زنجیره علت و معلول باشد؛ تعریف هر Wait، منبع جاری و Timeline تعیین می‌کند کدام‌یک علامت و کدام‌یک علت نزدیک‌تر است.

سؤال 6: برای سفارش پروژه کاهش ASYNC_NETWORK_IO چه داده‌هایی باید آماده شود؟

بازه دقیق کندی، نسخه و Edition، Wait Delta، Query و Plan، شاخص‌های سیستم‌عامل، توپولوژی و SLA را آماده کنید. حذف اطلاعات حساس و فراهم کردن نمونه قابل بازتولید باعث می‌شود خدمت عیب‌یابی سریع‌تر، کم‌ریسک‌تر و قابل ارزیابی باشد.

سؤال 7: رایج‌ترین خطای تشخیصی درباره ASYNC_NETWORK_IO چیست؟

قضاوت با مقدار تجمعی از زمان Startup و تغییر تنظیمات بدون اتصال انتظار به Query و بازه حادثه رایج‌ترین خطاست. نام این انتظار به معنای قطعی بودن مشکل شبکه نیست؛ طراحی برنامه Client در بسیاری از رخدادها عامل اصلی است. Snapshot کوتاه، Baseline و مقایسه قبل و بعد این خطا را کاهش می‌دهد.

سؤال 8: اثر ASYNC_NETWORK_IO بر Performance چگونه اندازه‌گیری می‌شود؟

Delta wait_time_ms، تعداد Task، متوسط انتظار و نرخ بر ثانیه را کنار throughput، p95 زمان پاسخ و منابع سیستم ثبت کنید. باز ماندن Request و Transaction، اشغال Connection و حافظه و گاهی طولانی‌تر شدن Lockها بنابراین معیار فنی باید به معیار تجربه کاربر یا Job کسب‌وکار متصل شود.

سؤال 9: Best Practice اصلی برای مدیریت ASYNC_NETWORK_IO چیست؟

Session، تعداد ردیف ارسالی، متن Query، مشخصات Client و زمان مصرف Result Set را با هم بررسی کنید. تغییر را ابتدا در محیط آزمایش یا روی دامنه محدود اعمال کنید، معیار موفقیت را از قبل بنویسید و امکان بازگشت داشته باشید. پاک کردن Wait Stats بدون ذخیره Baseline یا اجرای چند تغییر هم‌زمان قابلیت استناد نتیجه را از بین می‌برد.

سؤال 10: ASYNC_NETWORK_IO با کدام نسخه‌های SQL Server سازگار است؟

نسخه‌های متداول SQL Server و Azure SQL. ستون‌ها و Permissionهای DMV ممکن است میان نسخه‌های On-premises، Azure SQL و نسخه‌های جدید تغییر کنند؛ Query تشخیصی را در مستندات همان نسخه کنترل و ابتدا با دسترسی Read-only مناسب اجرا کنید.

سؤالات مصاحبه SQL Server

پرسش مصاحبه 1: اگر ASYNC_NETWORK_IO بالاترین Wait باشد، آیا آن را Root Cause می‌دانید؟

پاسخ پیشنهادی: خیر؛ ابتدا بازه، Delta، workload و هم‌بستگی با کندی را ثابت می‌کنم. سپس بر اساس دسته مصرف نتیجه و شبکه سراغ Request، Plan و شاخص تخصصی می‌روم تا علامت از علت جدا شود.

پرسش مصاحبه 2: چگونه ASYNC_NETWORK_IO را بدون پاک کردن Wait Stats تحلیل می‌کنید؟

پاسخ پیشنهادی: دو Snapshot زمان‌دار می‌گیرم، اختلاف شمارنده‌ها را محاسبه و بر ثانیه یا تراکنش نرمال می‌کنم. این روش تاریخچه سایر تیم‌ها را نیز از بین نمی‌برد.

پرسش مصاحبه 3: اولین اقدام کم‌ریسک برای ASYNC_NETWORK_IO چیست؟

پاسخ پیشنهادی: Session، تعداد ردیف ارسالی، متن Query، مشخصات Client و زمان مصرف Result Set را با هم بررسی کنید. جمع‌آوری شواهد Read-only و تعیین Query یا منبع مسئول، پیش از هر تغییر پیکربندی، کم‌ریسک‌ترین اقدام است.

پرسش مصاحبه 4: چه شاخصی موفقیت اصلاح ASYNC_NETWORK_IO را ثابت می‌کند؟

پاسخ پیشنهادی: کاهش Delta و زمان پاسخ p95 در workload هم‌سطح، بدون بدتر شدن CPU، I/O، Blocking یا نرخ خطا. یک عدد منفرد در محیط کم‌بار مدرک کافی نیست.

پرسش مصاحبه 5: چه زمانی اصلاح ASYNC_NETWORK_IO را Rollback می‌کنید؟

پاسخ پیشنهادی: اگر معیار هدف بهتر نشود، Regression در Plan یا SLA دیگر ایجاد شود، یا فرض اولیه با داده جدید رد شود، تغییر را طبق برنامه بازگشت لغو و Baseline تازه را ثبت می‌کنم.

چک‌لیست نهایی

1. زمان Startup و مقدار اولیه ASYNC_NETWORK_IO ثبت شد.
2. Delta در بازه نماینده و نرخ بر ثانیه محاسبه شد.
3. Session، Task، متن Query و Plan مرتبط ذخیره شد.
4. شاخص تخصصی مصرف نتیجه و شبکه با Wait هم‌بسته شد.
5. Waitهای مرتبط OLEDB، CXCONSUMER، LCK_M_S بررسی شدند.
6. اثر کسب‌وکاری و SLA پیش از تغییر اندازه‌گیری شد.
7. تغییر محدود، معیار موفقیت و Rollback تعریف شد.
8. آزمون بعد از تغییر روی workload هم‌سطح تکرار شد.

جمع‌بندی

ASYNC_NETWORK_IO یک نشانه مهم در دسته مصرف نتیجه و شبکه است، اما فقط با Timeline و شواهد چندلایه به تصمیم اصلاحی تبدیل می‌شود. تعریف فنی، Delta، Request جاری، شاخص زیرسیستم و اثر SLA را کنار هم قرار دهید. اقدام اول پیشنهادی همچنان این است: Session، تعداد ردیف ارسالی، متن Query، مشخصات Client و زمان مصرف Result Set را با هم بررسی کنید.

برای مقایسه این انتظار با سایر گلوگاه‌ها، مقاله جامع Wait Typeهای رایج SQL Server و مسیر کامل عیب‌یابی را مطالعه کنید. این رویکرد کمک می‌کند اصلاح ASYNC_NETWORK_IO باعث انتقال پنهان مشکل به CPU، I/O، Lock، Memory یا Worker Pool نشود.