یکی از سخت‌ترین کارایی که همیشه توی مشاوره با شرکتای مختلف دارم، پیدا کردن ریشه اصلی مشکل‌هاست (البته بیشتر توی لایه داده و دیتابیس).

جالب اینجاست که هر شرکتی با شرکت دیگه زمین تا آسمون فرق داره و واقعاً نمیشه یه نسخه آماده واسه همه داد.

حالا چرا میگم چالش؟
چون برای اینکه بفهمم مشکل دقیقاً از کجاست، مجبورم برم با آدمای مختلف حرف بزنم. همین حرف زدن‌ها گاهی باعث میشه یه سری حساسیت‌ها به‌وجود بیاد.

🔸 چرا حساسیت؟
چون بعضی واحدها یا آدم‌ها سال‌هاست کسی به حرفشون گوش نداده. وقتی یکی پیدا میشه و بهشون فضا میده که بگن مشکل کجاست، ناخودآگاه سروصدا بلند میشه. این وسط اونایی که از این «شنیده نشدن» سود می‌بردن، احساس خطر می‌کنن و ممکنه ناراحت بشن.

حالا سؤال من اینه 👇
شما اگه توی همچین موقعیتی بودین، چیکار می‌کردین؟
خیلی دوست دارم تجربه‌هاتونو بدونم و یاد بگیرم.

چند وقت پیش دیتابیس یه مرکز درمانی ترکیده بود! 😅
هیچ بکاپی نمی‌شد ازش گرفت، حتی وقتی DBCC CHECKDB می‌زدیم وسط کار خطا می‌داد و قطع می‌کرد.
کاری که کردم این بود که روی یه دیسک دیگه (چون دیسک اصلی مشکل داشت) یه دیتابیس خام ساختم. بعد هرچی داده می‌شد با Import/Export منتقل کردم. اونایی هم که گیر کرده بودن رو با SELECT از محدوده‌های سالم کشیدم بیرون و ریختم توی دیتابیس مقصد.
حالا نکته جالب ماجرا اینجاست 👇
به مدیر IT گفتم: چرا به Memory Dump‌هایی که SQL Server تولید کرده بود اصلاً توجه نکردین؟
این یکی از مهم‌ترین وظایف DBA هست که لاگ‌ها رو چک کنه. وقتی Memory Dump رخ می‌ده یعنی یه مشکل جدی هست—چه سخت‌افزاری چه نرم‌افزاری—و باید سریعاً رسیدگی بشه. وگرنه نتیجه‌ش همینی میشه که دیدیم: فاجعه!
آخر سر هم یه توصیه دوستانه کردم:
مدیریت دیتابیس‌هاتون رو بدین دست یه آدم متخصص.
اگه همه پولتون رو بذارین برای ویلا و ماشین و خوش‌گذرونی، یه روز می‌بینین اطلاعاتتون پریده و تازه باید کلی هزینه کنین تا برگرده! 😁 (البته ما که راضی هستیم چون پول بیشتری میگیریم 😂 )

سلام
🔎 یه سوال مهم:
چرا ما برای هر کاری اینقدر مقاومت می‌کنیم که بریم سراغ متخصص؟ 😅
انگار وقتی می‌خوایم به یه متخصص پول بدیم، طرف قراره جونمون رو بگیره!
حتما باید یه بار خودمون تست کنیم، خرابش کنیم، آخرش با دو برابر هزینه و کلی اعصاب‌خوردی بریم سراغ متخصص 😬
مثال دم‌دستی: کولر، لوله‌کشی، حتی تعمیر گوشی... همیشه همین داستانه.
مشکل اینجاست که ما فقط "۱۰ دقیقه کار" رو می‌بینیم، نه سال‌ها تجربه و فوت‌وفن‌هایی که باعث میشه اون کار تمیز، بی‌دردسر و کم‌هزینه تموم بشه.
💾 این ماجرا توی دنیای دیتابیس هم دقیقا همینه:
خیلیا می‌گن "ای بابا این کارا که کاری نداره، خودم یه سرچ می‌کنم درستش می‌کنم" 🤓
نتیجه؟ دیتابیس میشه آزمایشگاه خطا، ایندکس‌ها می‌شن قاتل سرعت، بکاپ‌ها موقع نیاز به کار نمیان، و آخرش با هزینه‌ی بیشتر باید متخصص بیاد نجاتش بده 💥
❓ شما چی فکر می‌کنید؟
شده یه بار بخواید هزینه‌ی متخصص ندید، آخرش چند برابرش رو خرج کنید؟
(خاطرات دیتابیسی و غیر دیتابیسی همش قبوله 😂)
👋 و اگه حس می‌کنید دیتابیس‌تون نیاز به یه نگاه تخصصی داره، من اینجام تا قبل از اینکه کار به بحران برسه کمک کنم

وقتی DBA باشی و سرورها قهر می‌کنن! 🤷‍♂️

یکی از ویژگی‌های بارز یه DBA خفن، خونسردی و اعتماد به نفس در لحظه بحرانه. اگه تو شرایط اضطراری بخوای استرس بگیری، همه‌چی رو بدتر می‌کنی. 🥶 این یه اصله.

چند سال پیش، سرورهای ما یهو قهر کردن و عجیب غریب کند شدن. 🐢 جای من وسط سالن بود و از اونجایی که سیستممون سراسری بود، تلفن‌های واحد داشت سوراخ می‌شد 📞 و حضوری هم ملت قطاری می‌اومدن کنارم. 🏃‍♂️

خلاصه شروع کردیم به مانیتورینگ که ببینیم قضیه از چه قراره. یهو به خودم اومدم دیدم دور مانیتورم ۲۵ تا کله چیده شده! 👨‍👩‍👧‍👦 از هر واحدی یکی! یه لحظه احساس کردم تو یه آکواریومم و همه اومدن ماهی‌گیری! 🐟

اول به همه گفتم برن سر جاشون که من حداقل بتونم نفس بکشم. هنوز داشتم دنبال دلیل اصلی می‌گشتم که مدیرمون اومد و با قاطعیت گفت: «اول باید Linked Serverها رو قطع کنی! مشکل از اونجاست.» 😤

گفتم: «مدیر، ربطی به اونا نداره.» 🤔 گفت: «همینی که من میگم!» 😠 منم دیگه با آرامش گفتم: «من این کارو نمی‌کنم. بذارید کارم رو بکنم.» ✋

خلاصه با مدیر هم بحث کردم و رفت. کار رو اصلاح کردم و مشکل حل شد. ✅

بعد تو جلسه، مدیر برگشت گفت: «چرا حرف منو گوش نکردی؟» 🤨 گفتم: «چون شما تخصص این کار رو ندارید و در مواقع بحران، صلاحیت ندارید به من بگید چیکار کنم. من اینجا هستم که از تخصصم استفاده کنم. یا به من اعتماد دارید یا ندارید. اگه دارید، دیگه تو کارم دخالت نکنید.» 😉 ( البته بعدش هم همچنان اونجا مشغول به کار بودم 😁 . خداروشکر این فضا وجود داشت که بتونیم این مدلی صحبت کنیم)

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

شما چه تجربه یا خاطره مشابهی دارید؟ برامون بنویسید! 👇

وقتی Restore اشتباهی، تبدیل به فاجعه میشه 🤦‍♂️

امروز یه تماسی از یک مرکز درمانی داشتم که مغزم سوت کشید. 🤯

پشتیبان نرم‌افزارشون رفته دیتابیس یک ماه پیش رو روی دیتابیس اصلی ریستور کرده. 💀

یعنی قشنگ کل اطلاعات یک ماه رو به باد فنا داده! 🌬

از مسئولشون پرسیدم چرا اجازه دادین؟ میگه خب پشتیبان شرکته! 🤷‍♂️

میگم مگه DBA ندارید؟ 🧑‍💻 میگه نه،

اصلاً دسترسی SA هم نداریم و مدیریت دیتابیس کلا دست خودشونه. 🔒

اینجا بود که فهمیدم رسماً با دیوونه‌خونه طرفم. 🤪

این جور شرکت‌ها که حتی الفبای مدیریت دیتابیس رو بلد نیستن و همه چیز رو انحصاری دست خودشون می‌گیرن، واقعا شاهکارن. 👑

بابا اگه کاری رو بلد نیستید، بسپرید به دست متخصصش! 👨‍🔬

اینکه بیاید گند بزنید به داده‌های مردم و با یه "ببخشید" سر و تهشو هم بیارید، آخر بی‌مسئولیتیه. 😠

واقعاً خوش‌شانسید که به پست من نخوردید! 😈

یه وقتایی پیش اومده رفتین رستوران و سفارش غذا دادین، بعد پیشخدمت فقط بر اساس سفارش نفر اول همه رو قضاوت کرده؟ 😅

مثلاً نفر اول گفته "من فقط یه سوپ کوچیک می‌خوام"، بعد پیشخدمت فکر کرده همه هم مثل اونن، رفته برای همه سوپ کوچیک آورده! 🍲

در حالی‌که نفر دوم ته‌چین می‌خواسته، نفر سوم کله‌پاچه، نفر چهارم هم پیتزا.

این دقیقاً همون Parameter Sniffing تو SQL Server هست. 🤓

وقتی یک Stored Procedure اجرا میشه، SQL Server میاد برنامه‌ی اجرایی (Execution Plan) رو بر اساس پارامتر اولین نفری که صداش زده می‌سازه.

حالا اگه بقیه با شرایط متفاوت بیان، همون پلن برای همه استفاده میشه؛ مثل همون پیشخدمتی که فکر کرد همه فقط سوپ می‌خوان.

نتیجه؟

یکی سریع به جواب می رسه🍕

یکی نصفه‌جون می‌مونه 🍲

یکی هم کلاً معطل میشه 🥴

پس اگه دیدی کوئری‌ها گاهی پرواز می‌کنن و گاهی زمین‌گیر میشن، شاید پای یه پیشخدمت به اسم Parameter Sniffing وسطه.

برجام، یک تراکنش پر از Rollback! 🤦‍♂️
ده سال پیش که برجام (Transaction) استارت خورد 🚀، گفتن همه تحریم‌ها موقتاً برداشته میشه. ما هم با یه خبر غیرقطعی (Dirty Page) کلی ذوق‌زده شدیم و با همین داده‌ای که هنوز Commit نشده بود، رفتیم جلو! 🏃‍♂️

این وسط کل دنیا هم Lock بودن 🔒 و منتظر بودن ببینن تهش چی میشه. ولی ما زرنگ بودیم! با یه Query غیررسمی (یعنی با WITH(NOLOCK) 😉) خبر برداشتن تحریم‌ها رو شنیدیم و باهاش عشق و حال کردیم. 🎉

همین وسط بود که یهو یه ترامپ (DBA) اومد و دکمه خروج از برجام رو زد! 🤯 یعنی اون تراکنش رو Kill کرد و فرستاد تو وضعیت Rollback! 💥

حالا بعد از ده سال، بالاخره این فرآیند Rollback مشخص شده و داره به اتمام می‌رسه. 😭 کلی تصمیم مهم روی شرکت و زندگی‌مون گرفته بودیم که همه‌شون بر اساس همون داده‌های کثیف بودن. 😩 تازه فهمیدیم یه «مکانیزم ماشه» هم داشته که ما ندیده بودیم! 💥 (داده اصلی تازه خودش رو نشون میده!)

حالا برو تو Query‌هات همینطوری جلو هر جدول یه WITH(NOLOCK) بذار و شاد باش که همه Blocking‌ها رو از بین بردی! 🥳 ولی کی مکانیزم ماشه کدنویسی‌ت فعال بشه و کل شرکت رو بفرسته هوا، خدا میدونه! 🤷‍♂️

همینقدر دقیق و خطرناک! 😉

سلام دوستان

Execution Plan و Statistics در SQL Server: داستانی از فرار از زندان 😂

تصور کنین که "SQL Server" یه زندان بزرگ و پر از زندانیه. هر زندانی همون Query ماست که می‌خواد از زندان فرار کنه. 🏃‍♂️

The Execution Plan (نقشه فرار) 🗺

Execution Plan دقیقاً همون نقشه‌ایه که مایکل اسکافیلد تو بدنش تتو کرده بود! یه نقشه دقیق و مرحله به مرحله برای فرار. این نقشه به زندانی (کوئری) می‌گه که چطور باید از دست نگهبانا (موتور دیتابیس) فرار کنه، از چه تونل‌هایی بگذره (Index Seek) و از کجا دیوارو خراب کنه (Table Scan)! 🤯

اگه مایکل اسکافیلد، نقشه‌اش رو خوب نمی‌کشید یا مثلاً به جای کندن دیوار، سعی می‌کرد با نگهبان‌ها دوست بشه، قطعاً هیچوقت به خارج از زندان نمی‌رسید. تو دنیای ما هم اگه Execution Plan بهینه نباشه، کوئری ما یا خیلی طول می‌کشه یا اصلاً اجرا نمی‌شه. به عبارت دیگه، به جای فرار، میره سلول انفرادی! 💀



The Statistics (آمار و اطلاعات) 📊

Statistics همون اطلاعاتیه که مایکل اسکافیلد از زندان داشت. مثلاً می‌دونست که چند نفر زندانی تو هر بخش هستن، نگهبان‌ها چه زمانهایی شیفتشون عوض می‌شه و... . این اطلاعات بهش کمک می‌کرد که نقشه فرارش رو دقیق‌تر و هوشمندانه‌تر بکشه.

اگه Statistics به روز نباشن، مثل این می‌مونه که مایکل اسکافیلد فکر کنه هنوز همون نگهبانای قبلی سر پستشونن، در حالی که همه عوض شدن و نقشه‌هاش دیگه کار نمی‌کنه. نتیجه چی می‌شه؟ فرار شکست می‌خوره و نگهبانا هم بهش می‌خندن! 😂

نتیجه اخلاقی:

برای فرار موفق و سریع از زندان SQL Server، هم باید یه نقشه فرار (Execution Plan) بهینه داشته باشی و هم اطلاعاتت (Statistics) باید دقیق و به روز باشن. پس هر وقت کوئریت کند شد، یاد فرار از زندان مایکل اسکافیلد بیفت و برو سراغ نقشه و آمار! 🏃‍♂️

سلام دوستان



📸 Snapshot Isolation تو SQL Server مثل صف بانک می‌مونه.

مردم عادی همه تو صف وایسادن تا کارشون راه بیفته 🧑‍🤝‍🧑.(تراکنش های Read Committed یا مدلهای دیگه ای از Isolation به غیر از Nolock یا Read Uncommitted)

ولی یهو یه آقای خیلی پولدار با حساب چند ده میلیاردی 💰 میاد، اصلا کاری به صف نداره. مستقیم میره پیش رئیس بانک 👔.

کارمندای بدبخت بانک (SQL Server) که سرشون شلوغه 🤯، با دستور رئیس یه لحظه کار همه رو ول می‌کنن و سریع کار این آقا رو راه میندازن.(Snapshot Isolation)

بعدشم برمی‌گردن برای کار همون صف و انگار نه انگار اتفاقی افتاده!(Blocking)

یعنی هرکی داره تو دنیای خودش توی صف پیش میره، ولی اون آقای میلیاردی یه نسخه‌ی ویژه (Snapshot) داره و هیچ دعوایی هم با بقیه پیش نمیاد 😅.

نتیجه:

✅ کار همه انجام میشه.

✅ صف به هم نمی‌ریزه.

✅ کسی که پول داره همیشه در اولویته 😁 (همون بند پ خودمون)

بریم بایک مثال خفن دیگه تفاوت Index Scan و Index Seek رو بهتون بگم.

🔍 Index Scan

مثل خانمی که به شوهرش شک کرده 😅

شروع می‌کنه همه‌چیزو زیر و رو کردن: 📱 موبایل، 🎒 کیف، 📂 پرونده‌ها، حتی جیب شلوار!

یعنی از اول تا آخر همه‌چیزو می‌گرده تا بلکه یه سرنخ پیدا کنه.

🎯 Index Seek

اما این یکی خیلی هدفمنده 😎

صبح راه می‌افته دنبال شوهرش، صاف میره سر اصل ماجرا 👉 همون جایی که می‌دونه جوابش هست.(بعد همونجا پاره اش می کنه 😁 )

سلام

✍️ امروز یکی از دوستانم با مشکلی در SQL Server Always On Availability Group روبه‌رو شد.

بین دو سرور، کلاستر راه‌اندازی شده بود و حتی در سرویس SQL Server هم تیک مربوط به کلاستر خورده بود، اما هنگام ایجاد Availability Group خطای عجیبی نمایش داده می‌شد.

🔎 مراحل بررسی که انجام دادم:

1️⃣ اول از همه مطمئن شدم که سرویس کلاستر در حال اجراست.

2️⃣ بعد وضعیت نودها رو بررسی کردم تا هر دو در حالت Up باشند.

3️⃣ وجود File Share Witness رو هم چک کردم (اگر نباشه این خطا رو ایجاد نمی‌کنه، ولی بودنش همیشه بهتره).

4️⃣ در نهایت داخل SQL Server این کوئری رو اجرا کردم:



SELECT * FROM sys.dm_hadr_cluster

اینجا مشخص شد که برای سرویس، هیچ کلاستری تعریف نشده!

✅ راه‌حل ساده بود:

یک‌بار قابلیت Always On Availability Group رو از داخل SQL Server Configuration Manager غیرفعال و دوباره فعال کردم. مشکل برطرف شد.

💡 گفتم این تجربه رو اینجا هم به اشتراک بذارم، شاید به کارتون بیاد.

#Alwayson #Availability_Group #HA #DBA

اگه دقت کرده باشید بچه‌ها وقتی یه اسباب‌بازی دستشونه، به هیچ‌وجه ول‌کن نیستن. 😅
هرکی هم بخواد بگیره سریع میگه: «مال خودمه!»
تا وقتی یا بازیشون تموم بشه (🔒 Commit) یا حواسشون پرت یه چیز دیگه بشه (❌ Rollback)، اون اسباب‌بازی رو ول نمی‌کنن.

Transaction توی SQL Server هم دقیقاً همین مدلیه!
وقتی بازه، رکورد یا جدول رو محکم گرفته و به هیچکس دیگه نمی‌ده.
یا باید کارش رو درست تموم کنه (Commit) یا بی‌خیال بشه و همه چی رو پس بده (Rollback).

توی خونه‌های پرجمعیت، اگه پدر و مادرها مدیریت نمی‌کردن، بچه‌ها همدیگه رو تیکه‌پاره می‌کردن! 😅
قانون جنگل بود:
🍞 هرکی زودتر بیدار می‌شد غذا گیرش می‌اومد، وگرنه گشنه می‌موند.
🛏 هرکی زورش بیشتر بود، اتاق و تخت مال خودش می‌شد و بقیه باید وسط هال عشق می‌کردن!
اینجا بود که پدر و مادرها (و هنوز هم) وارد می‌شدن و منابع رو بین بچه‌ها عادلانه تقسیم می‌کردن. نتیجه؟ دیگه جنگ‌های قبیله‌ای داخلی از بین می‌رفت و همه در صلح و صفا زندگی می‌کردن. ✌️
فقط اگه بچه‌ای دست درازی می‌کرد، با سلاح کشنده‌ای به نام دمپایی 👡 مواجه می‌شد!
حالا توی SQL Server هم Resource Governor همین نقش رو داره. ⚙️
منابع رو بین یوزرها تقسیم می‌کنه تا درگیر نشن. و اگه یه کوئری هم بخواد زور بگه و منابع بیشتری بگیره، با Kill شدن و خطا (همون دمپایی معروف 😁) روبه‌رو میشه.
شما تا حالا از Resource Governor استفاده کردین؟

سلام عزیزان

🚀 یه پست خفن دیگه 🚀
ما توی SQL Server چیزی داریم به اسم Cost Threshold for Parallelism (CTFP).
ولی خب این یعنی چی؟ 🤔

🔧 مثال خودمونی:
همه‌مون حداقل یه بار اسباب‌کشی داشتیم. کارگر باربر رودیدین؟
تا یه حدی بار رو تنهایی مثل بنز 🚛 میندازه رو کولش و می‌بره.
اما وقتی بار خیلی سنگین بشه، دیگه یه نفر جواب نمی‌ده و چند نفر باید با هم دست‌به‌کار شن.

🔍 تشبیه:
هر کارگر = یه CPU 🖥
اون حد توان = CTFP
وقتی هزینه‌ی اجرای یه Query از اون حد بیشتر بشه:
👉 یه CPU تنها نمی‌تونه
👉 چند CPU با هم می‌پرن وسط
👉 و تا وقتی اون بار سنگین جابه‌جا بشه، کارای سبک‌تر باید وایسن تو صف ⏳
📌 نتیجه‌گیری:
تا می‌تونید Queryهاتون رو بهینه بنویسید 💡
هزینه کم = سرعت بیشتر = CPU خوشحال 😎

⚖️ نکته مهم در تنظیم CTFP:
اگه خیلی زیاد باشه → یه CPU ممکنه زیر بار سنگین له بشه 😵‍💫
اگه خیلی کم باشه → حتی بارهای سبک هم چند CPU رو درگیر می‌کنن و همه‌چی کند میشه 🐌

سلام دوستان

🔑 توی SQL Server یه چیزی داریم به اسم Trace Flag، کلیدای مخفی که رفتارای پشت‌صحنه رو عوض می‌کنن.

حالا یعنی چی؟ 🤔

فرض کن با پارتنر عزیزت بحثت شده و رسماً در حالت پاره‌پوره هستید 😅

یه گل می‌خری 🌹 (یعنی یه Trace Flag فعال می‌کنی)

یهو رفتار طرف تغییر می‌کنه و همه‌چی دوباره گل و بلبل میشه! 🕊✨

ولی از اون ور، ممکنه یه جمله اشتباهی بگی و یکی از اون Trace Flagها فعال شه…

نتیجه؟ 😬 یه لاگ مفصل از غرغرها روی سرت میاد پایین! (مثل وقتی تو SQL Server می‌زنی 3704 و لاگهای ریزتر می‌بینی 📜)

نکته عجیبش چیه؟ 🤨

چه توی SQL Server چه تو زندگی واقعی، خیلی از این Trace Flagها Undocumented هستن!

یعنی هیچ راهنما و مستندی براشون نیست. باید خودت مورد عنایت قرار بگیری تا یاد بگیری 😅



📚 برای اینکه توی SQL Server بیشتر در موردش بدونید، این لینک میتونه مفید باشه



https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-traceon-trace-flags-transact-sql?view=sql-server-ver17

ما توی SQL Server یه قابلیتی داریم به اسم Audit Log.
حالا یعنی چی؟

فرض کن داری با ماشینت توی خیابون حرکت می‌کنی:
از یه طرف دوربین‌ها همه‌جا هستن، از یه طرف پلیس نامحسوس رد میشه، اون وسط هم پلیس ایستاده داره سرعت رو می‌گیره. یعنی هر حرکتت رصد میشه و کافیه یه خطا کنی، سریع مچت رو می‌گیرن 🚨

دقیقاً همین کار رو Audit Log توی دیتابیس انجام می‌ده.

یا اگه بخوام یه مثال دیگه بزنم: شنیدین میگن خدا برای هر آدمی یه فرشته گذاشته که حتی وقتی دستتو می‌کنی توی دماغت هم یادداشت می‌کنه؟ 😅
چرا؟ برای اینکه اون دنیا جای حاشا نباشه و فیلمشو بذارن جلوت.
Audit Log هم حکم همون فرشته رو داره. هرکاری کنی ثبت میشه، تا فردا روز نشه گفت: «من نبودم، دستم خورد!» 😉

🤔 تا حالا خواستی دقیق بدونی جداول سیستمی SQL Server چطوری کار می‌کنن و چه روابطی با هم دارن؟

یه روش خیلی باحال برای یادگیری هست:
1️⃣ یه SQL Server روی سیستمت نصب کن.
2️⃣ یه ابزار مانیتورینگ مثل Profiler یا ترجیحاً XEvents اجرا کن.
3️⃣ شروع کن با SSMS کار کردن. مثلاً:

لیست دیتابیس‌ها رو باز کن.

روی گزینه‌های مختلف کلیک کن.

🔎 اینجا هر Query که توسط SSMS اجرا میشه (برای همون کاری که تو انجام دادی) توی ابزار لیست میشه و می‌تونی ببینی.

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

⚡️ نتیجه؟ درک عمیق‌تر و واقعی‌تر از SQL Server 🚀

سلام دوستان



🛒 یادتونه سال‌ها قبل از اینکه هایپراستار بیاد، برای هر چیزی مجبور بودیم بریم یه فروشگاه مخصوص همون؟

هیچ مرجعی نبود که یک‌جا همه نیازها رو پوشش بده.

وقتی هایپراستار اومد، ملت استقبال کردن چون همه‌چی یه جا جمع بود:



✅ برندهای خوب

✅ اجناس درست‌حسابی

✅ خرید راحت‌تر



نتیجه؟ دسترسی ساده‌تر به کالاها و در عوض فروش مغازه‌های اطراف به شدت افت کرد.



حالا دقیقاً همین اتفاق توی دنیای SQL Server و Data Warehouse (DW) میفته.



📊 توی DW:

داده‌ها از منابع مختلف (مثل همون فروشگاه‌ها یا کارخانه‌ها) جمع میشن.

برای رکوردها Master Data پیاده‌سازی میشه (یه کدینگ واحد برای کالاها).

داده‌ها تمیز و پاکسازی میشن (کالاهای خراب و برندهای ضعیف حذف میشن).

و در نهایت کاربر با یه منبع داده‌ی مرتب و درست سروکله می‌زنه و می‌تونه به صورت تجمیعی به همه نیازهای گزارش‌گیری و تصمیم‌گیری دسترسی داشته باشه—بدون اینکه مجبور باشه بره سراغ تک‌تک سیستم‌ها.



⚠️ پس اگه جایی اومدن براتون DW و BI راه انداختن ولی این اتفاقا نیفتاد… احتمالاً یه جای کار می‌لنگه 😉