پاور BI میں اضافی ریفریش: بڑے ڈیٹاسیٹس کو موثر طریقے سے ہینڈل کرنا

ہر پاور BI کا نفاذ آخرکار ایک ہی دیوار سے ٹکرا جاتا ہے: ڈیٹا سیٹ اتنا بڑا ہو جاتا ہے کہ مکمل ریفریشز میں بہت زیادہ وقت لگتا ہے، بہت زیادہ وسائل استعمال ہوتے ہیں، اور صارفین کو ڈیٹا کی ضرورت سے پہلے ونڈوز کے دستیاب وقت سے تجاوز کر جاتا ہے۔

50 ملین قطاروں کے ساتھ ایک ٹرانزیکشن ٹیبل، جو ہر 4 گھنٹے میں مکمل طور پر تازہ ہوجاتی ہے، اس میں زیادہ وقت نہیں لگتا - یہ ڈیٹا کو دوبارہ لوڈ کرنے میں وسائل ضائع کرتا ہے جو تبدیل نہیں ہوا ہے۔ انکریمنٹل ریفریش اس کو صرف نئے اور تبدیل شدہ ریکارڈ لوڈ کرکے حل کرتا ہے، جبکہ تاریخی ڈیٹا کو برقرار رکھتے ہوئے جو تبدیل نہیں ہوتا ہے۔ صحیح طریقے سے ہو گیا، ایک ڈیٹا سیٹ جس کو پہلے ریفریش ہونے میں 3 گھنٹے لگے تھے 10 منٹ سے کم وقت میں کرنٹ لایا جا سکتا ہے۔

یہ گائیڈ پاور BI میں پہلے اصولوں سے لے کر ایڈوانس کنفیگریشن تک کے اضافی ریفریش کا احاطہ کرتی ہے — بشمول وہ عام غلطیاں جو نفاذ کو توڑ دیتی ہیں اور بہترین طرز عمل جو انہیں پروڈکشن کے لیے قابل اعتماد بناتی ہیں۔

اہم ٹیک ویز

• تاریخ کے لحاظ سے اضافی ریفریش پارٹیشنز ڈیٹا سیٹس، ہر ریفریش سائیکل پر صرف حالیہ ڈیٹا لوڈ کرنا
• فیکٹ ٹیبل پر ڈیٹ ٹائم کالم اور دو پاور کوئری پیرامیٹرز (رینج اسٹارٹ، رینج اینڈ) کی ضرورت ہوتی ہے۔
• پرانے پارٹیشنز میں تاریخی ڈیٹا کو برقرار رکھا جاتا ہے جو کہ ابتدائی لوڈ کے بعد دوبارہ استفسار نہیں کیا جاتا
• 10 سے زیادہ پارٹیشنز کے ساتھ اضافی ریفریش کے لیے پاور BI پریمیم (یا فیبرک) درکار ہے۔
• ڈیٹا کی تبدیلیوں کا پتہ لگانے کا اختیار صرف ان پارٹیشنز کو ریفریش کرنے سے پروسیسنگ کو مزید کم کرتا ہے جہاں ڈیٹا تبدیل ہوتا ہے۔
• ہائبرڈ ٹیبلز (درآمد اور DirectQuery کا امتزاج) تاریخی درآمدی پارٹیشنز کے ساتھ ساتھ ریئل ٹائم ڈیٹا کو فعال کرتے ہیں
• مناسب ترتیب کے لیے پاور کوئری فولڈنگ کو سمجھنے کی ضرورت ہوتی ہے — غیر فولڈ کیے جانے والے سوالات انکریمنٹل ریفریش کو توڑ دیتے ہیں
• XMLA اینڈ پوائنٹ اور تھرڈ پارٹی ٹولز کے ذریعے پارٹیشن ہیلتھ کی نگرانی خاموش ناکامیوں کو روکتی ہے

---

کس طرح اضافی ریفریش کام کرتا ہے۔

اضافی ریفریش کو سمجھنا یہ سمجھنے سے شروع ہوتا ہے کہ پاور BI ڈیٹا کو کیسے تقسیم کرتا ہے۔

معیاری درآمدی ماڈل میں، پورا ڈیٹا سیٹ ایک ہی پارٹیشن میں رہتا ہے۔ ہر ریفریش اس پارٹیشن کو مکمل طور پر بدل دیتا ہے۔ چھوٹے ڈیٹاسیٹس کے لیے، یہ ٹھیک ہے۔ بڑی میزوں کے لیے، یہ اوپر بیان کردہ مسائل پیدا کرتا ہے۔

اضافی ریفریش حقائق کی میز کو متعدد پارٹیشنز میں تقسیم کرتا ہے، ہر ایک مخصوص تاریخ کی حد کا احاطہ کرتا ہے:

• پارٹیشن 1: 2020-01-01 سے 2020-12-31 (تاریخی، کبھی تازہ نہیں ہوا)
• پارٹیشن 2: 2021-01-01 سے 2021-12-31 (تاریخی، کبھی تازہ نہیں ہوا)
• پارٹیشن 3: 2022-01-01 سے 2022-12-31 (تاریخی، کبھی تازہ نہیں ہوا)
• پارٹیشن 4: 2023-01-01 سے 2023-12-31 (تاریخی، کبھی تازہ نہیں ہوا)
• پارٹیشن 5: 2024-01-01 سے 2024-12-31 (ماہانہ تازہ)
• پارٹیشن 6: 2025-01-01 سے 2025-03-31 (روزانہ تازہ کیا جاتا ہے)
• پارٹیشن 7: 2025-04-01 سے موجودہ (فی گھنٹہ یا ڈیمانڈ پر تازہ کیا جاتا ہے)

ہر شیڈول ریفریش پر، صرف حالیہ پارٹیشنز (اس مثال میں 5، 6، اور 7) پر کارروائی کی جاتی ہے۔ تاریخی تقسیم اس وقت سے برقرار ہیں جب انہیں پہلی بار لوڈ کیا گیا تھا۔ اس کا مطلب ہے کہ ریفریش سائیکل کل ڈیٹا کے صرف ایک حصے پر کارروائی کرتا ہے — ڈرامائی طور پر وقت، میموری اور سورس سسٹم کے بوجھ کو کم کرتا ہے۔

---

شرائط اور تقاضے

اضافی ریفریش کو ترتیب دینے سے پہلے، تصدیق کریں کہ یہ شرائط پوری ہو گئی ہیں:

لائسنسنگ: پاور BI پرو (حدود کے ساتھ) اور پاور BI پریمیم/فیبرک (مکمل صلاحیت) میں اضافی ریفریش دستیاب ہے۔ پرو کے ساتھ، آپ 10 ریفریش پیریڈز تک کنفیگر کر سکتے ہیں۔ پریمیم اس حد کو ہٹاتا ہے اور "ڈیٹا کی تبدیلیوں کا پتہ لگانے" کی خصوصیت کو شامل کرتا ہے۔

ڈیٹ ٹائم کالم: فیکٹ ٹیبل میں ڈیٹ ٹائم کالم ہونا ضروری ہے (ڈیٹ کلید انٹیجر نہیں — ایک حقیقی ڈیٹ ٹائم ٹائپ ہونا چاہیے) جسے پاور BI ڈیٹا کو تقسیم کرنے کے لیے استعمال کرے گا۔ یہ عام طور پر لین دین کی تاریخ، ایونٹ کا ٹائم اسٹیمپ، یا تخلیق کردہ کالم ہے۔

کوئیری فولڈنگ: پاور کوئری استفسار جو فیکٹ ٹیبل کو لوڈ کرتا ہے اسے استفسار فولڈنگ کو سپورٹ کرنا ضروری ہے — پاور کوئری ٹرانسفارمیشن کے مراحل کو سورس سوال (SQL، وغیرہ) میں ترجمہ کرنے کی صلاحیت جسے سورس سسٹم انجام دیتا ہے۔ اگر استفسار فولڈنگ ٹوٹ جاتا ہے تو، اضافی ریفریش خاموشی سے ناکام ہوجاتا ہے — یہ مقصد کو شکست دیتے ہوئے ہر ریفریش پر تمام ڈیٹا لوڈ کرتا ہے۔

ذریعہ سسٹم سپورٹ: سورس کو ڈیٹ رینج فلٹرنگ کو موثر طریقے سے سپورٹ کرنا چاہیے۔ ڈیٹ ٹائم کالم پر انڈیکس کے بغیر سورس ٹیبل سست ریفریشز پیدا کرے گا حتیٰ کہ انکریمنٹل ریفریش کنفیگر کیے گئے ہیں، کیونکہ ہر پارٹیشن ریفریش تاریخ کی حد میں ریکارڈز تلاش کرنے کے لیے مکمل ٹیبل اسکین کرے گا۔

---

مرحلہ وار ترتیب

مرحلہ 1: مطلوبہ پاور کوئری پیرامیٹرز بنائیں

پاور BI ڈیسک ٹاپ میں، پاور کوئری ایڈیٹر کھولیں۔ پیرامیٹرز کا نظم کریں → نیا پیرامیٹر پر جائیں۔

بالکل اس طرح دو پیرامیٹرز بنائیں (نام کیس کے لحاظ سے حساس ہیں اور ان کا بالکل مماثل ہونا چاہیے):

یہ پیرامیٹرز Date/Time کی قسم کے ہونے چاہئیں، Date کے نہیں۔ وہ رن ٹائم پر پاور BI کے ریفریش انجن کے ذریعے اوور رائڈ ہو جائیں گے، لیکن انہیں ترقی اور جانچ کے لیے درست ڈیفالٹ اقدار کی ضرورت ہے۔

مرحلہ 2: ان پیرامیٹرز کا استعمال کرتے ہوئے فیکٹ ٹیبل کو فلٹر کریں

پاور کوئری ایڈیٹر میں، اپنی فیکٹ ٹیبل منتخب کریں۔ پیرامیٹرز کا استعمال کرتے ہوئے ڈیٹ ٹائم کالم پر فلٹر لگائیں:

= Table.SelectRows(Source, each [TransactionDate] >= RangeStart and [TransactionDate] < RangeEnd)

یہ فلٹرنگ مرحلہ اہم ہے: اسے ڈیٹا سورس میں فولڈ کرنا ضروری ہے۔ فولڈنگ کی توثیق کرنے کے لیے، استفسار کے آخری مرحلے پر دائیں کلک کریں اور چیک کریں کہ آیا "آبائی سوال دیکھیں" دستیاب ہے۔ اگر یہ خاکستری ہو گیا ہے تو فولڈنگ ٹوٹ گئی ہے — اس بات کی تحقیق کریں کہ اس کے اوپر کون سے تبدیلی کے مراحل فولڈ چین کو توڑ رہے ہیں۔

مرحلہ 3: استفسار فولڈنگ کی توثیق کریں

استفسار فولڈنگ سب سے زیادہ اس وجہ سے ٹوٹ جاتا ہے:

• حسب ضرورت فنکشنز جن کا SQL میں ترجمہ نہیں کیا جا سکتا
• دو سوالات کو ضم کرنا (شامل ہونا) جہاں ایک یا دونوں فولڈ نہیں ہوتے ہیں۔
• متن کی تبدیلی کے کچھ افعال (Text.Upper, Text.PadStart)
• فہرست آپریشنز کا استعمال کرتے ہوئے (List.Contains)
• ایک انڈیکس کالم شامل کرنا
• کچھ قسم کے تبادلوں کے آپریشن

اگر فولڈنگ ٹوٹ جاتی ہے، تو استفسار کو ری فیکٹر کریں تاکہ مسئلہ کی کارروائیوں کو ڈیٹ فلٹر کے بعد کے ایک قدم پر آگے بڑھایا جا سکے — یا پاور کوئری کے بجائے سورس ڈیٹا بیس میں ایک منظر میں تبدیلی کو انجام دیں۔

مرحلہ 4: انکریمنٹل ریفریش پالیسی کو کنفیگر کریں

پاور BI ڈیسک ٹاپ میں، فیلڈز پین → انکریمنٹل ریفریش میں فیکٹ ٹیبل پر دائیں کلک کریں۔

ترتیب کے اختیارات:

• گزشتہ N کیلنڈر کے سالوں/مہینے/دنوں میں قطاریں ذخیرہ کریں: یہ ماڈل میں رکھی گئی کل تاریخی ونڈو کی وضاحت کرتا ہے۔ اس سے پرانا ڈیٹا ماڈل سے خود بخود ہٹا دیا جاتا ہے (گرا دیا گیا پارٹیشن)۔

• صرف آخری N کیلنڈر کے سالوں/مہینے/دنوں میں قطاروں کو ریفریش کریں: یہ رولنگ ونڈو کی وضاحت کرتا ہے جو ہر سائیکل پر دوبارہ تازہ ہوتی ہے۔ اس ونڈو سے پرانے ڈیٹا کو تاریخی (غیر متغیر) سمجھا جاتا ہے اور اسے دوبارہ کبھی تازہ نہیں کیا جاتا ہے۔

• ڈیٹا کی تبدیلیوں کا پتہ لگائیں: (صرف پریمیم) ایک علیحدہ ڈیٹ ٹائم کالم (عام طور پر ایک "آخری ترمیم شدہ" کالم) کا استعمال کرتا ہے اس بات کا پتہ لگانے کے لیے کہ کن تاریخی پارٹیشنز نے ڈیٹا کو تبدیل کیا ہے اور صرف ان پارٹیشنز کو دوبارہ پروسیس کیا جاتا ہے۔

5 سال کی تاریخ کے ساتھ لین دین کے ڈیٹا بیس کے لیے مثال کی ترتیب:

• پچھلے 5 سالوں میں قطاریں ذخیرہ کریں
• صرف آخری 3 دنوں میں قطاریں تازہ کریں

یہ 5 سال کے ڈیٹا پر مشتمل پارٹیشنز بناتا ہے، لیکن ہر سائیکل پر صرف پچھلے 3 دنوں کے پارٹیشنز کو ہی تازہ کیا جاتا ہے۔

مرحلہ 5: شائع کریں اور تصدیق کریں

رپورٹ پاور BI سروس میں شائع کریں۔ پبلشنگ کے بعد پہلی ریفریش میں بعد کے ریفریشز سے زیادہ وقت لگے گا — یہ تمام تاریخی ڈیٹا لوڈ کرتا ہے اور پہلی بار تمام پارٹیشنز بناتا ہے۔ یہ متوقع ہے۔

---

ایڈوانس کنفیگریشن: ڈیٹا کی تبدیلیوں کا پتہ لگائیں۔

پریمیم میں "ڈیٹا کی تبدیلیوں کا پتہ لگائیں" کا اختیار کارکردگی کی ایک اور پرت کا اضافہ کرتا ہے۔ یہ ایک نامزد کالم (عام طور پر ایک last_modified_date کالم) سے استفسار کرکے اس بات کا تعین کرنے کے لیے کام کرتا ہے کہ آیا کسی تاریخی تقسیم کے کسی ریکارڈ کو اپ ڈیٹ کیا گیا ہے۔ صرف ان پارٹیشنز کو ریفریش کیا جاتا ہے جہاں ڈیٹا حقیقت میں تبدیل ہوا ہو۔

ڈیٹا کی تبدیلیوں کا پتہ لگائے بغیر: 3 دن کی رولنگ ونڈو ہمیشہ ریفریش ہوتی ہے، چاہے پچھلے 3 دنوں میں کوئی ڈیٹا تبدیل نہ ہو۔

ڈیٹا کی تبدیلیوں کا پتہ لگانے کے ساتھ: ریفریش انجن چیک کرتا ہے کہ آیا ہر پارٹیشن پر کارروائی کرنے کا فیصلہ کرنے سے پہلے رولنگ ونڈو کے کسی ریکارڈ میں ترمیم کی گئی تھی۔ اگر پیر کے ڈیٹا کو پیر کی رات کو تازہ کیا گیا تھا اور اس کے بعد سے کسی ریکارڈ میں ترمیم نہیں کی گئی تھی، تو منگل کی رات کی تازہ کاری پیر کی تقسیم کو چھوڑ دیتی ہے۔

یہ خاص طور پر ان منظرناموں کے لیے قابل قدر ہے جہاں:

• ماخذ کا ڈیٹا ایک بار لکھا جاتا ہے اور شاذ و نادر ہی اپ ڈیٹ کیا جاتا ہے (غیر تبدیل شدہ ضمیمہ صرف واقعات)
• رولنگ ونڈو بڑی ہے (مثال کے طور پر، 30 دن) لیکن زیادہ تر دنوں میں کوئی تبدیلی نہیں ہوتی ہے۔
• سورس سسٹم کے استفسار کی صلاحیت محدود ہے۔

ڈیٹا کی تبدیلیوں کا پتہ لگانے والے کالم کو سورس ڈیٹا بیس میں انڈیکس کیا جانا چاہیے — ریفریش انجن ہر ریفریش سائیکل پر ہر پارٹیشن کے لیے اس کالم سے استفسار کرتا ہے۔

---

ہائبرڈ ٹیبلز: ریئل ٹائم + تاریخی ڈیٹا

Power BI Fabric/Premium نے ہائبرڈ ٹیبل متعارف کرایا ہے — درآمدی موڈ (تاریخی پارٹیشنز) اور DirectQuery موڈ (موجودہ دن کا ڈیٹا) کا ایک طاقتور مجموعہ۔ یہ ڈیش بورڈز کو قابل بناتا ہے جو تاریخی درآمدی ڈیٹا کے ساتھ موجودہ منٹ میں اپ ڈیٹ شدہ ڈیٹا دکھاتا ہے۔

ہائبرڈ ٹیبل کی ترتیب میں:

• تاریخی پارٹیشنز (کل اور پرانے) امپورٹ موڈ میں ہیں — تیز، کیشڈ، مکمل طور پر جمع
• موجودہ دن کی تقسیم DirectQuery موڈ میں ہے - سوالات سورس ڈیٹا بیس کے خلاف براہ راست چلتے ہیں۔

صارف کا تجربہ ہموار ہے - سوالات دونوں طریقوں کو شفاف طریقے سے پھیلاتے ہیں۔ "اس ہفتے کی فروخت بمقابلہ گزشتہ ہفتہ" کے لیے ایک استفسار درآمدی تقسیم سے کل کا ڈیٹا اور آج کا ڈیٹا DirectQuery کے ذریعے کھینچتا ہے، ان کو ایک نتیجہ میں یکجا کرتا ہے۔

ہائبرڈ ٹیبلز کے لیے تحفظات:

• DirectQuery کی کارکردگی مکمل طور پر ماخذ ڈیٹا بیس کی کارکردگی پر منحصر ہے - ایک سست ڈیٹا بیس کا مطلب ہے موجودہ دنوں کے سست سوالات
• DirectQuery پارٹیشن امپورٹ موڈ آپٹیمائزیشن سے فائدہ نہیں اٹھاتا (کوئی ورٹی پیک کمپریشن، کوئی پری ایگریگیشن نہیں)
• ایک پریمیم یا فیبرک ورک اسپیس کی ضرورت ہے۔

---

انکریمنٹل ریفریش ہیلتھ کی نگرانی

اضافی ریفریش کی ناکامیاں اکثر خاموش رہتی ہیں - ماڈل "کامیابی سے تازہ کاری" کے طور پر ظاہر کرتا ہے یہاں تک کہ اگر کچھ پارٹیشنز ناکام ہو جائیں یا مکمل ریفریش پر واپس آ جائیں۔ پیداوار کی وشوسنییتا کے لیے نگرانی ضروری ہے۔

XMLA اینڈ پوائنٹ انسپیکشن: پاور BI پریمیم ایک XMLA اینڈ پوائنٹ کو ظاہر کرتا ہے جس سے SQL سرور مینجمنٹ اسٹوڈیو (SSMS)، ٹیبلر ایڈیٹر، یا Azure Analysis Services جیسے ٹولز جڑ سکتے ہیں۔ وہاں سے، آپ پارٹیشن میٹا ڈیٹا سے استفسار کر سکتے ہیں کہ ہر پارٹیشن کے لیے آخری ریفریش ٹائم اور آیا کوئی پارٹیشن خرابی کی حالت میں ہے۔

ٹیبلر ایڈیٹر 2 (مفت): XMLA کے ذریعے پریمیم ورک اسپیس سے جڑیں اور ماڈل میں پارٹیشنز ٹیبل کا معائنہ کریں۔ ہر پارٹیشن اپنا نام، تاریخ کی حد، آخری ریفریش ٹائم اسٹیمپ، اور ریاست دکھاتا ہے۔ یہ انکریمنٹل ریفریش مسائل کی تشخیص کے لیے سب سے زیادہ عملی ٹول ہے۔

پاور بی آئی ایکٹیویٹی لاگ: ایڈمن ایکٹیویٹی لاگ ریفریش آپریشنز کو ریکارڈ کرتا ہے، بشمول کون سے پارٹیشنز پر کارروائی کی گئی تھی اور کوئی خرابی۔ Power BI REST API کے ذریعے دستیاب ہے۔

** ناکامی کے عام نمونے:**

---

پریکٹس میں فولڈنگ کی تصدیق کا سوال

استفسار فولڈنگ سب سے عام وجہ ہے کہ اضافی ریفریش اپنے وعدہ کردہ کارکردگی کے فوائد فراہم کرنے میں ناکام ہوجاتی ہے۔ عام فولڈنگ وقفوں کی تشخیص اور اسے ٹھیک کرنے کا طریقہ یہاں ہے۔

ٹیسٹ 1: مقامی سوال دیکھیں۔ Power Query میں RangeStart/RangeEnd فلٹر مرحلہ شامل کرنے کے بعد، قدم پر دائیں کلک کریں۔ اگر "دیکھیں مقامی سوال" دستیاب ہے اور تاریخ کی حد کو فلٹر کرنے والی WHERE شق کے ساتھ SQL استفسار دکھاتا ہے، فولڈنگ کام کر رہی ہے۔

ٹیسٹ 2: تیار کردہ SQL کو چیک کریں۔ مقامی استفسار میں کچھ ایسا ہونا چاہئے:

WHERE [TransactionDate] >= @RangeStart AND [TransactionDate] < @RangeEnd

اگر WHERE شق غائب ہے، فولڈنگ ٹوٹ گئی ہے اور ماخذ سے تمام ڈیٹا لوڈ کرنے کے بعد پاور کوئری کے انجن میں فلٹر لگایا جا رہا ہے۔

فولڈنگ کو بحال کرنا: اگر اپنی مرضی کی تبدیلی سے فولڈنگ ٹوٹ جاتی ہے، تو اسے ڈیٹ فلٹر کے مرحلے کے بعد منتقل کریں، یا سورس ڈیٹا بیس میں SQL ویو میں تبدیلی انجام دیں اور پاور BI کو ٹیبل کے بجائے ویو سے جوڑیں۔

---

اکثر پوچھے گئے سوالات

کیا انکریمنٹل ریفریش تمام ڈیٹا ذرائع کے ساتھ کام کرتا ہے؟

انکریمنٹل ریفریش کسی بھی ڈیٹا سورس کے ساتھ کام کرتا ہے جو استفسار کی فولڈنگ اور ڈیٹ رینج فلٹرنگ کو سپورٹ کرتا ہے، بشمول SQL Server، Azure SQL، PostgreSQL، Snowflake، BigQuery، Azure Synapse، اور Databricks۔ یہ ان ذرائع کے ساتھ اچھی طرح سے کام نہیں کرتا جو استفسار فولڈنگ کو سپورٹ نہیں کرتے (ایکسل فائلز، فلیٹ CSV، کچھ REST APIs) — ان صورتوں میں، مکمل ریفریش کی ضرورت ہے۔ فولڈ نہ ہونے والے ذرائع کے لیے، پاور BI کے مربوط ہونے سے پہلے SQL ڈیٹا بیس میں ڈیٹا کو اسٹیجنگ کرنا تجویز کردہ حل ہے۔

بڑھتی ہوئی ریفریش کے لیے کون سا پاور BI لائسنس درکار ہے؟

اضافی ریفریش پاور BI پرو (10 ریفریش ادوار تک محدود)، پاور BI پریمیم فی صلاحیت، پاور BI پریمیم فی صارف (PPU)، اور مائیکروسافٹ فیبرک کی صلاحیتوں میں دستیاب ہے۔ "ڈیٹا کی تبدیلیوں کا پتہ لگائیں" خصوصیت اور ہائبرڈ ٹیبلز کو پریمیم یا فیبرک کی ضرورت ہوتی ہے۔ 10 سے زیادہ تاریخی پارٹیشنز کے ساتھ زیادہ تر انٹرپرائز کے نفاذ کے لیے، پریمیم یا فیبرک کی ضرورت ہوتی ہے۔

انکریمنٹل ریفریش دیر سے پہنچنے والے ڈیٹا کو کیسے ہینڈل کرتا ہے؟

تاخیر سے پہنچنے والا ڈیٹا — وہ ریکارڈ جو اپنی ٹرانزیکشن کی تاریخ کے بعد پہنچتے ہیں (مثال کے طور پر، دسمبر کا لین دین جو جنوری کے ڈیٹا ایکسٹریکٹ میں آتا ہے) — کو رولنگ ریفریش ونڈو کو اتنی چوڑی سیٹ کرکے سنبھالا جاتا ہے کہ دیر سے آنے والوں کو پکڑ سکے۔ اگر ڈیٹا 7 دن کی تاخیر سے پہنچ سکتا ہے، تو رولنگ ونڈو کو 14 دن پر سیٹ کرنا یقینی بناتا ہے کہ جب متعلقہ پارٹیشن کو دوبارہ ریفریش کیا جائے تو دیر سے آنے والوں کو پکڑ لیا جائے۔ متبادل طور پر، آخری ترمیم شدہ کالم کے ساتھ ڈیٹیکٹ ڈیٹا چینجز آپشن رولنگ ونڈو کی ترتیب سے قطع نظر دیر سے آنے والوں کو پکڑتا ہے۔

کیا انکریمنٹل ریفریش صرف حقائق پر نہیں، ڈائمینشن ٹیبلز پر کام کر سکتا ہے؟

انکریمنٹل ریفریش کو بڑے فیکٹ ٹیبلز کے لیے ڈیزائن کیا گیا ہے اور اس کے لیے ڈیٹ ٹائم فلٹر کالم کی ضرورت ہے۔ زیادہ تر ڈائمینشن ٹیبلز (مصنوعات، گاہک، مقامات) میں مناسب ڈیٹ ٹائم پارٹیشن کالم نہیں ہوتا ہے اور وہ اتنے چھوٹے ہوتے ہیں کہ مکمل ریفریش مناسب ہو۔ دھیرے دھیرے تبدیل ہونے والی ڈائمینشن ٹیبلز کے لیے جو بڑی ہو چکی ہیں (50M+ قطاروں والی کسٹمر ٹیبلز)، ایک متبادل نقطہ نظر یہ ہے کہ ماخذ ڈیٹا بیس میں SQL ویوز کو استعمال کیا جائے تاکہ حال ہی میں تبدیل شدہ ریکارڈز کو فلٹر کیا جا سکے اور پاور BI کے بجائے ڈیٹا بیس لیئر میں ہسٹری ریٹینشن کو ہینڈل کیا جا سکے۔

میں کیسے دیکھوں کہ میرے انکریمنٹل ریفریش ماڈل میں کون سے پارٹیشنز موجود ہیں؟

سب سے آسان طریقہ یہ ہے کہ ٹیبلر ایڈیٹر (مفت ورژن 2) کو XMLA اینڈ پوائنٹ کے ذریعے اپنے پاور BI پریمیم ورک اسپیس سے جوڑیں۔ ٹیبلز → [آپ کی میز] → پارٹیشنز کے تحت، آپ کو تمام تخلیق شدہ پارٹیشنز ان کی تاریخ کی حدود اور آخری پروسیس شدہ ٹائم اسٹیمپ کے ساتھ نظر آئیں گے۔ SQL سرور مینجمنٹ اسٹوڈیو (SSMS) XMLA کے ذریعے بھی جڑتا ہے اور آبجیکٹ ایکسپلورر میں تقسیم کی تفصیلات دکھاتا ہے۔

اگر اضافی ریفریش جزوی طور پر ناکام ہوجائے تو کیا ہوگا؟

اگر ریفریش درمیان میں ناکام ہو جاتی ہے تو پاور BI ناکام پارٹیشنز کو دوبارہ آزماتا ہے۔ ناکامی سے پہلے کامیابی سے مکمل ہونے والی پارٹیشنز پر دوبارہ کارروائی نہیں کی جاتی ہے — صرف ناکام پارٹیشنز کو دوبارہ آزمایا جاتا ہے۔ دوبارہ کوشش کرنے کے اس رویے کا مطلب ہے کہ اضافی ریفریش مکمل ریفریش کے مقابلے میں عارضی سورس سسٹم کی بندش کے لیے زیادہ لچکدار ہے۔ اگر کوئی پارٹیشن مسلسل ناکام ہو جاتا ہے، تو پارٹیشن اپنی آخری کامیابی سے بھری ہوئی حالت میں رہتا ہے جبکہ نئے پارٹیشنز کو عام طور پر ریفریش کیا جاتا ہے۔

---

اگلے اقدامات

انکریمنٹل ریفریش کسی بھی پاور BI کے نفاذ کے لیے بنیادی ہے جو بڑے ٹرانزیکشنل ڈیٹا سیٹس کو ہینڈل کرتا ہے۔ اسے شروع سے ہی حاصل کرنا — مناسب استفسار فولڈنگ، مناسب رولنگ ونڈوز، اور نگرانی کے ساتھ — کارکردگی کے ان مسائل کو روکتا ہے جو بعد میں مہنگی تعمیر نو پر مجبور کرتے ہیں۔

ECOSIRE کی پاور BI کارکردگی کو بہتر بنانے کی خدمات میں بڑے پیمانے پر انٹرپرائز ڈیٹا سیٹس کے لیے اضافی ریفریش ڈیزائن اور نفاذ شامل ہے۔ اپنے موجودہ ریفریش فن تعمیر کا جائزہ لینے اور اصلاح کے مواقع کی نشاندہی کرنے کے لیے ہم سے رابطہ کریں۔