معماری کلان داده ای شرکت شمارو چه کسی تبیین می کنه؟
براساس چه استراتژی ساختار معماری داده ای خودتون رو پیاده سازی می کنید؟

مثلا فرض کنید ۲۰ تا شعبه دارید. آیا اینها به صورت مستقل اطلاعات وارد می کنند و بعد در شعبه مرکزی داده ها جمع آوری میشه و گزارش میگیرید؟
مثلا کدینگ هارو چطوری حل می کنید؟
کیفیت داده اطلاعات رو چطوری بررسی می کنید؟
سطوح دسترسی داده ای رو چطور مدیریت می کنید؟
متولی اینها چه کسی یا کسانی هستند؟

یکی از چالش های درست طراحی نشدن معماری کلان داده ای، دقیقا عدم توسعه پذیری اون معماری هست.

بعد تغییر این زیرساخت به شدت هزینه برداره و خیلی چیزها باید تغییر کنه.
دوست دارم نظراتتون رو بشنوم و یاد بگیرم.

احتمالا شما هم در گیر و دار ازدواج ، درگیر وام ازدواج شدین( به دلیل شیرینی امر ازدواج وام ازدواج رو مثال زدم وگرنه همه وام هارو شامل میشه 😁 )
شما اول که داخل یک صف هستید تا نوبتتون بشه و درخواستتون رو مطرح کنید( کد شما در صف اجرا قرار میگیره تا نوبتش بشه و بهش منابع تخصیص داده بشه)
حالا زمانی که میخواین اقدام کنید ،‌متصدی باجه به شما میگه مثلا فلان مدرک کمه. حتما باید کپی کارت ملی عمه گرامی هم بیاری 😂 تا بهم وام بدیم. روی پرونده شما یک برچسب میچسبونه که این وام در انتظار کارت ملی عمه اش هست.
یکی دیگه میاد بهش یک برچسب می چسبونه که منتظر عقدنامه هستیم ازدواج سفید قبول نمی کنیم 😂 .

(اینجا کد شما یک برچسبی به نام Wait میخوره که یا منتظر CPU هست یا Memory یا در انتظار آزاد شدن یک جدول و....)
حالا هروقت اون مدارک رو شما بیارید و اون برچسب برداشته بشه اون وام لعنتی بهتون داده میشه( هروقت منبع مورد نظر بهتون تخصیص داده بشه ، کدتون اجرا میشه)
این کل مفهوم Wait ها در SQL Server هست.
حالا شما میتونید وضعیت بیشترین Wait هایی که روی سیستم اتفاق افتاده از
select * from sys.dm_os_wait_stats
اینجا ملاحظه کنید.
درواقع به زبون مثالمون بخوام بیانش کنم ، داره لیست وامهایی که پرداخت شده و انواع نقصی مدارک و تعدادشون و مدت زمان انتظار برای جبران اون نقص مدارک رو به شما میگه.
حالا اگه میخواین ببینید چند نفر در صف انتظار وام هستند و الان منتظر چه مدارکی هستند از کد زیر میتونید استفاده کنید.
select * from sys.dm_os_waiting_tasks
این داره میگه کدهایی که درحال اجرا هستند هر کدوم منتظر چه منبعی هستند تا بتونن اجرا بشن.
به واسطه رفتار این Wait ها میشه سرنخ کندی رو پیدا کرد.
یعنی اگه توی بانکها بیان همین لیست انتظارها و وامهای گرفته شده رو بررسی کنن و علل گیر کردن اونها رو بررسی کنن شاید این فرآیندش خیلی سریعتر بشه.

توی این فیلم در خصوص قوانین نرمال سازی و اصول طراحی جدول صحبت می کنم.
#مکتبخونه

حتما براتون پیش اومده که رفتین مثلا تره باری یا یک میوه فروشی ، شروع به جداکردن میوه ها کردین ، بعد اون متصدی غرفه اومده بالا سرتون که داداش جدا نکن درهمه. (البته الان وضعیت بهتر شده ولی قبلا زیاد بود)
حالا اگه شما میخواستین میوه های خوب رو جداکنید احتمالا مجبور بودین هزینه بیشتری پرداخت کنید.
آفرین ، SQL Server هم دقیقا همینه. وقتی یک نتیجه ای به شما میده اون نتیجه درهمه ، هیچ مرتب سازی نداره. یعنی برای اینکه شما نتیجه نهایی رو مرتب شده داشته باشین ، باید هزینه اونو بپردازین و قید کنید که براساس چی مرتب بشه.
اما یک چالش، شاید دیده باشین در کدهای مختلف که مثلا طرف یک VIEW نوشته یا یک Inline-Function نوشته و داخلش اومده یک Order گذاشته و SQL Server بهش خطا داده. این طرف هم رفته پیش مدیر فنیش که مثلا حمیدرضا این چرا خطا میده؟
حمیدرضا هم یک ژست ما خیلی خفنیم گرفته 😁 گفته برو یک Top 100 percent بذار حل میشه. این بنده خدا هم رفته گذاشته و تونسته اون Object رو ایجاد کنه. تو دلش گفته وای خدا،‌این حمیدرضا چه خفنه خیلی وارده 😁
ولی کجا گندش درمیاد.؟ زمانی که دوست عزیزمون یک Select از View میزنه و انتظار داره نتیجه مرتب شده برگردونده بشه ولی امااااااااا اصلا از این خبرا نیست.
اینجاست که حمیدرضا باید بره تو افق محو بشه 😂
حمیدرضا ندونسته که اون مرتب سازی داخل View , Function , CTE برای این هست که صرفا شما میخوای مثلا از Top یا Offset استفاده کنی و یک تعدادی رکورد برگردونی و داری میگی براساس چی مرتب باشه که من ۱۰-۱۰۰-۱۰۰۰ تای اول یا آخرش رو برگردونم. همین به خدا 😉 .
یعنی توی هر جایی چیزی غیر از این شنیدین اشتباهه.
هر نتیجه ای که قراره بگیرین و مرتب باشه باید در بیرونی ترین Select قید کنید که براساس چی مرتب باشه.
وقتی داخل یک View میاین مینویسین Top 100 percent یعنی همه دیتا رو براساس مثلا فیلد تاریخ مرتب کن و برگردون.کجا برگردونه؟ آفرین اون Select درونی توی View. حالا زمانی که من میخوام از View استفاده کنم اون میاد داخلش داده هارو فیلتر میکنه که میشه همه داده ها وبراساس تاریخ مرتب میکنه. حالا روی این نتیجه میاد Select میزنه ولی اینجا که شما هیچ مرتب سازی قید نکردین! دوباره مرتب سازی شما بهم میخوره و باید حتما این رو قید کنید که براساس چی باید مرتب بشه.
امیدوارم این توضیح من برای همیشه این مساله رو در ذهنتون حل کنه که کاربرد Order by , Offset در کلا Table Expression ها برای چیه.

امروز داشتم به مانیتورینگ نگاه می کردم ، دیدم توی یک بازه یک دفعه CPU به شدت رفته بالا و Wait ها هم زیاد بودن.
بررسی کردم دیدم یک کدی هست که یک دفعه ظاهر شده و تعداد دفعات اجراش زیاده.
زمان اجرای کد حدودا ۲ دقیقه بود و همچنین Logical Read بیش از ۲ میلیون داشت.
همچنین CPU هم به شدت درگیر شده بود.
اومدم پلن کد رو بررسی کردم . دیدم عزیز دل ، جان جانان ، آقامون SQL Server 😁 داره یک هشدار زیبای Implicit Convert میده.
دیدم توی شرط دوتا فیلد دارن باهم چک میشن که یکی bigint بود و یکی Nvarchar . همین باعث شده بود که پلن درستی ایجاد نشه و از ایندکس روی اون فیلد بهره نبره و کل جدول هربار اسکن بشه .
با تغییر اون فیلد Nvarchar به Bigint ( به خاطر اینکه داده هاشون یکی بودن و نیازی به Nvarchar نبود)‌ زمان اجرای کد مربوطه شد ۲۰۰ میلی ثانیه و Logical Read به زیر ۱۰۰ رسید.
حالا این دوست عزیز Implicit Convert چیست؟
زمانی که توی شرط ها فیلدی که قراره جستجو بشه ،‌نوع داده اش با نوع داده ای که داره بهش پاس داده میشه برابر نباشه‌، SQL Server میاد اینهارو بهم تبدیل میکنه.
همین باعث میشه یک فاجعه رخ بده. یعنی چی؟ دیگه اون جداول آماری Statistics مورد استفاده قرار نمیگیره و کل جدول رو مورد عنایت قرار میده. 😂
به همین راحتی کدتون میتونه یک فاجعه ای مثل کد بالا رو خلق کنه.

دقت کردین میگن پشت تلفن هر حرفی رو نگید و هر کلمه ای رو نگید. ممکنه که بیان روی خطتون و ...
یعنی یک سرویس مخفی اون سمت هست که همیشه حواسش به شما هست 😂
دقیقا توی تعریف Nonclustered Index ها هم همین صادقه.
زمانی که شما دارید یک Clustered Index تعریف می کنید ( که این در اکثر مواقع با PK همراهه و میتونه دوجین فیلد رو باهم PK قرار بده)
یک کلید داره که میتونه یک فیلد باشه میتونه ترکیبی از چند فیلد باشه.
حالا هر ایندکس غیر کلاستری که تعریف می کنید همیشه به صورت یک ستون مخفی این کلید کلاستر داخلش قرار داره.
فرض کنید شما مثلا یک فیلد از نوع UniqueIdentifier دارید یکی از نوع Varchar یکی هم از نوع INT و ترکیب اینهارو اومدین یک PK گرفتین که کلاستر ایندکس شما هم شده.
حالا هر ایندکس دیگه ای بسازید این سه تا فیلد عزیز توی همه ایندکس های شما وجود داره.
حتما میگین خوب باشه مگه جای تورو تنگ کرده؟ 😅
نه عزیز دل ، جای منو که تنگ نکرده ولی باعث میشه ایندکس شما به شدت بزرگ بشه.
سایز جدول و دیتابیس شما افزایش پیدا کنه.
هرباری هرکدوم از این فیلدهای کلیدی کلاستر تغییر کنن توی همه ایندکس ها باید این تغییرات اعمال بشه و الی آخر.
یعنی قشنگ مثل یک دومینو هست که اولش خراب بشه همینطوری خیاری همه رو پشت هم خراب میکنه. 😂
نکته اخلاقی : در تعریف PK ها باید دقت کنید. الزامی نداره ایندکس کلاستر شما با PK شما یکی باشه. PK برای ارتباط با جداول دیگه در نظر گرفته میشه ولی ایندکس کلاستر برای ساختار ذخیره سازی و مسائل دیگه است.

سلام دوستان عزیزم
امیدوارم حالتون عالی عالی باشه
خوب بالاخره دوره Performance Tuning در مکتب خونه منتشر شد

در این دوره در خصوص چالش های Performance و نحوه مانیتورینگ ورفع این چالش ها صحبت کردم.

از لینک زیر میتونید دوره رو تهیه کنید

https://maktabkhooneh.org/course/%D8%A2%D9%85%D9%88%D8%B2%D8%B4-sql-server-performance-tuning-mk6185/?v=1&affiliate_code=y7p0k0

کد تخفیف : COUPON-48513

امیدوارم مفید واقع بشه.

سلام خدمت دوستان عزیزم
سال نو رو خدمت همه عزیزان تبریک عرض می کنم.
از خداوند سالی توام با سلامتی ، رزق زیاد ، شادی و موفقیت رو برای تک تک عزیزان در کنار خانواده محترم خواستارم.
امیدوارم در پایان امسال دعا کنید که خدایا سال جدید رو مثل امسال ما قرار بده.

نوروز مبارک 💐💐💐

سلام خدمت دوستان عزیزم
امیدوارم که عالی باشین
ما برای شرکت سلامت الکترونیک تامین (ساتا) نیازمند یک نیروی DBA هستیم.
تسلط به مفاهیم و ساختارهای Replication , HA و Database Maintenance برامون حائز اهمیته.
به دلیل اینکه هم تعداد دیتابیس ها زیاده . هم ساختار Replication پیچیده ای هست.
هم اینکه حساسیت داده ای بسیار بالاست.
محل کار هم تهرانسر هست.
کار هم به صورت حضوریه.

عزیزانی که تمایل دارند رزومه هاشون رو برای من بفرستند.

شاد باشین
@Hamidreza_Sadeghian

سلام دوستان عزیزم



🚨 توی چند روز اخیر دو مورد Disaster برای دو مرکز مختلف رخ داد.

هرکدوم از این مراکز دو تا سرور داشتند که HA بودند و کلاستر مدام از دسترس خارج می‌شد.

هر دو نود می‌رفتند توی حالت Resolving... 😵‍💫

🔍 طی بررسی لاگ‌های کلاستر و لاگ‌های تولیدشده توسط SQL Server

دیدم Memory Dump‌های مختلفی توسط SQL Server ایجاد شده.

📉 معمولاً زمانی که یک Memory Dump توسط SQL Server ایجاد می‌شه، یعنی یک خطای حاد وجود داره.

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

🛠 در اولین مورد فهمیدیم یک باگ در Query Store هست در نسخه ۲۰۲۲

که با نصب Service Pack مشکل حل شد.

💽 در مورد دوم هم دیسک مشکل داشت و باعث شده بود کدهایی که اجرا می‌شن، خطای Access Violation بدن.

با اصلاح دیسک‌ها، مسأله حل شد.

✅ اینجاست که وجود یک DBA واقعی حیاتی می‌شه...

🤔 شما تجربه‌ی مشابهی داشتین؟

خوشحال می‌شم بدونم چطور باهاش برخورد کردین. 💬

سلام خدمت دوستان عزیزم
امیدوارم حالتون عالی باشه
ما برای تپسی شاپ ، به یک نیروی BI حرفه ای نیازمندیم.

این شخص باید به این موارد مسلط باشه یا حداقل کارکرده باشه:
- معماری BI و DW
- SSAS
-ETL(SSIS)
-T-SQL Querying
-DAX and MDX
-Power BI

کار به صورت حضوری بوده و دفتر آن نیز در تهران هست.
دفتر هم محدوده سینما آزادی هست.

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

@hamidreza_Sadeghian

🌐 افزایش حملات سایبری در دوران جنگ، و اهمیت توجه به SQL Injection

سلام به همه دوستان عزیزم،
امیدوارم حالتون خوب و دلاتون آروم باشه.

در این روزهای پرتنش که حملات سایبری هم شدت گرفته، یکی از حملاتی که بیشتر از همیشه باید جدی گرفته بشه، SQL Injection هست.

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

چند سوال کلیدی که باید از خودمون بپرسیم:

آیا نقاط ضعف مربوط به Injectionها در سیستم رو شناسایی و برطرف کردید؟

آیا اطلاعات حساس و مهم رو رمزنگاری کردید؟

آیا دسترسی‌ها رو در سطح Schema تفکیک کردید، یا همچنان با یک یوزر Owner به کل دیتابیس متصل می‌شید؟

آیا ساختار Backup شما به گونه‌ای هست که در صورت نفوذ بتونید داده‌ها رو بازیابی کنید؟

آیا از Backupها نسخه‌ی دوم تهیه و در مکان امن نگهداری می‌کنید؟

آیا روی سرور دیتابیس، فایروال فعال و پیکربندی‌شده دارید؟

آیا آخرین Service Packها و Patchهای امنیتی نصب شده‌اند؟

آیا تنظیمات امنیتی مربوط به Service Accountهای SQL Server به‌درستی رعایت شده؟

🔐 این‌ها تنها بخشی از سوالاتی هستند که باید در روزهای پرریسک امروز بهشون فکر کنیم.
امیدوارم که داده‌هاتون در سلامت کامل باشن و هیچ تهدیدی متوجه‌شون نشه.

ارادتمند
حمیدرضا صادقیان

@Hamidreza_Sadeghian

سلام خدمت دوستان عزیز
من با توجه به جابجایی به شهر مشهد مقدس و به اتمام رسیدن بعضی از پروژه ها ، فعلا دو روز در هفته وقت برای مشاوره در حوزه SQL Server رو دارم.
در صورتی که تمایل به همکاری دارید ، در صورتی که در جایی به غیر از مشهد هستید به صورت آنلاین و در صورتی که در مشهد تشریف دارید میتوانیم به صورت حضوری همکاری را آغاز کنیم.

ارادتمند
حمیدرضا صادقیان

گاهی اوقات به دلایل مختلف مثل شرایط زندگی یا مشکلات مالی، یادگیری مهارت‌های جدید به‌خاطر محدودیت‌هایی که پیش میاد از اولویت‌های ما عقب می‌افته. برای اینکه به سهم خودم کمکی کرده باشم تا این مسئله کمرنگ‌تر بشه، در طرح حمایتی «همدلی در مسیر یادگیری» دوره «آموزش اصول پایگاه داده و SQL Server» رو رایگان کردیم.

این دوره برای کسانی که می‌خواهند به‌طور عملی و کاربردی با اصول پایگاه داده و SQL Server آشنا بشن، طراحی شده.

این فرصت تا تاریخ ۳۱ مرداد ماه ۱۴۰۴ برای شما فعال هست و شما می‌تونید با استفاده از کد تخفیف ۱۰۰٪ HAMDELI، به‌راحتی دوره رو شروع کنید.

اگر فکر می‌کنید این دوره می‌تونه برای دوستان یا همکارانتون مفید باشه، حتماً لینک دوره رو با اون‌ها هم به اشتراک بذارید.

کد تخفیف: HAMDELI
لینک دوره: https://mktb.me/lj3s/

لینک مشاهده تمام دوره‌های رایگان‌شده:
https://mktb.me/vznz/

#همدلی_در_مسیر_یادگیری
#عدالت_آموزشی
#مکتب_خونه

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

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

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

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

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

چند وقت پیش دیتابیس یه مرکز درمانی ترکیده بود! 😅
هیچ بکاپی نمی‌شد ازش گرفت، حتی وقتی 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‌ها رو از بین بردی! 🥳 ولی کی مکانیزم ماشه کدنویسی‌ت فعال بشه و کل شرکت رو بفرسته هوا، خدا میدونه! 🤷‍♂️

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