SQL Server

описание

حمید رضا صادقیان 🔴طراح‌ومشاوربانک های اطلاعاتیSQLSERVER ⚫️مدرس دوره های آموزشیDatabase ارتباط با من: @Hamidreza_Sadeghian گروه تبادل نظر: https://t.me/+uIc1qhv58gU0NWQ0

← к каналу @sql_server

3 913

подписчиков

Охват к подписчикам

50,8%

ERR

Реакции к просмотрам

1,03%

470 на 22 постов

Пересылки к просмотрам

0,72%

328

Постов в день

0,0

всего 22

Где отзываются чаще

доля реакций к просмотрам

29 нояб. 2024 г.без подписи2,24%
14 дек.سلام دوستان. 🔧 بهینه‌سازی حذف 17 میلیون رکورد در SQL Server 🚀 قرار بود از یک جدول، حدود 17 میلیون رکورد حذف بشه. منطق اولیه به این صورت بود که: 🔹 داخل یک حلقه، با یک SELECT 🔹 هر بار 20,000 رکورد در یک Local Variable ریخته می‌شد 🔹 و سپس عملیات حذف انجام می‌گرفت ⏳ این روش به‌شدت کند بود و فرآیند حذف چندین ساعت زمان می‌برد. 💡 راهکاری که پیاده‌سازی کردم: ✅ منطق را به‌طور کامل بازطراحی کردم: 1️⃣ دستور SELECT را از داخل حلقه خارج کردم 2️⃣ یک Temporary Table ساختم 3️⃣ تمام ID‌های موردنظر را یک‌جا داخل آن INSERT کردم 4️⃣ روی جدول Temp یک Index مناسب ایجاد کردم ⚡️ 5️⃣ در حلقه، هر بار فقط 20,000 رکورد: از جداول اصلی حذف می‌شد و همان 20,000 رکورد از جدول Temp هم پاک می‌شد 🔁 کل فرآیند در قالب یک Transaction کنترل‌شده انجام شد 📌 به‌طوری که بعد از هر 20,000 رکورد COMMIT می‌شد تا: رشد Transaction Log کنترل بشه. با توجه به Auto Backup‌های مداوم، فایل لاگ من رشد نمیکرد که باعث ترکیدن سیستم بشه. 🎯 نتیجه نهایی: 🔥 حذف کامل 17,000,000 رکورد فقط در 56 دقیقه 📉 کاهش چشمگیر زمان اجرا 📉 کنترل مصرف لاگ 📈 افزایش پایداری سیستم در زمان عملیات ⚠️ نکته مهم درباره علت کندی اولیه: روی جدول، Cascade Delete فعال بود و به دلیل محدودیت‌های سیستمی امکان تغییر آن وجود نداشت بنابراین بهینه‌سازی باید کاملاً در سطح منطق اجرا و معماری حذف داده انجام می‌شد، نه ساختار دیتابیس.1,82%
12 июн.روزی از یک مرکز درمانی با من تماس گرفتند 📞 گفتند سیستم به شدت کند شده و عملاً کار پذیرش با مشکل مواجه شده است ⚠️ پشت هر کندی سیستم در مراکز درمانی، فقط چند ثانیه تأخیر نیست… بیمار منتظر است 🧍‍♂️ پذیرش کلافه شده 😓 صف طولانی‌تر می‌شود ⏳ پزشک منتظر ثبت اطلاعات است 🩺 و فشار کاری لحظه به لحظه بیشتر می‌شود به صورت آنلاین وارد سرور شدم و بررسی را شروع کردم 💻 اولین نکته این بود که SQL Server به نسخه جدید ارتقا پیدا کرده بود و Compatibility Level هم تغییر کرده بود. آن را به حالت قبلی برگرداندم 🔧 بعد سراغ منابع سرور رفتم CPU به شدت درگیر بود 🔥 تنظیمات MAXDOP اصلاح شد و کمی وضعیت بهتر شد، اما مشکل اصلی هنوز باقی بود در مرحله بعد Query Store را بررسی کردم و Queryهای پرمصرف را بر اساس CPU استخراج کردم 📊 نتیجه واضح بود یک Query پرتکرار که ایندکس مناسب نداشت، بخش بزرگی از CPU را مصرف می‌کرد ایندکس ایجاد شد ⚙️ چند دقیقه بعد، مصرف CPU به شکل محسوسی کاهش پیدا کرد 📉 و سیستم به حالت عادی برگشت ✅ کل این بحران-از صف‌های طولانی تا نارضایتی کاربران-در نهایت به نبود یک ایندکس مناسب ختم شد و اینجاست که همیشه این جمله برایم پررنگ‌تر می‌شود: مانیتورینگ پایگاه داده و حضور یک DBA فقط برای زمانی نیست که همه چیز خوب است… ارزش واقعی آن زمانی مشخص می‌شود که سیستم در آستانه فروپاشی است 🚨 گاهی تفاوت بین یک روز عادی و یک بحران بزرگ، فقط یک ایندکس است 🎯1,80%
7 авг.سلام دوستان عزیزم. 👨‍💻 یکی از سوال‌هایی که همیشه ازم می‌پرسن اینه که: «توی مصاحبه فنی از افراد چی می‌پرسی؟» 🤔 پیرو چند پست قبلی که درباره مصاحبه نوشتم، بد نیست اینم بگم که من معمولا افراد رو از نظر سطح دانش به چهار دسته تقسیم می‌کنم: 🔹 کارآموز 🔹 مبتدی 🔹 متوسط 🔹 حرفه‌ای و جالبه که نوع سوالاتم برای هر کدوم کاملا فرق می‌کنه. مثلا اگر کسی بگه: «من Senior هستم» 😎 راستش اولین چیزی که برام مهمه این نیست که چند تا Query از حفظ بلده یا چقدر سریع کد می‌نویسه. اتفاقا خیلی از مصاحبه‌ها از همون دقیقه اول میگن: "این مسئله رو حل کن، کدش رو بنویس." این روش بد نیست... ولی من بیشتر دوست دارم قبل از اینکه حتی به کد برسیم، بفهمم اون آدم دیتابیس رو واقعا درک کرده یا فقط باهاش کار کرده. مثلا ازش می‌پرسم: 🟢وقتی SQL Server Engine این Query رو اجرا میکنه چه رفتاری داره؟ 🟢 اثری که این کد روی Performance میذاره چیه؟ 🟢 اگر سیستم کند بشه، از کجا شروع می‌کنی مشکل رو پیدا کنی؟ 🟢 وقتی یک نیاز از سمت کاربر میاد، چطور اون رو تبدیل به طراحی دیتابیس و پیاده‌سازی می‌کنی؟ 🟢 اگر بین چند راه‌حل انتخاب داشته باشی، چرا یکی رو انتخاب می‌کنی؟ برای من طرز فکر آدم‌ها از خود جواب‌ها مهم‌تره. اما وقتی طرف در سطح مبتدی یا متوسط باشه، طبیعتا انتظارم فرق می‌کنه. اونجا بیشتر میرم سراغ مفاهیم پایه: ✅ این دستور دقیقا چه کاری انجام میده؟ ✅ کجا باید ازش استفاده کرد؟ ✅ تفاوتش با دستور مشابهش چیه؟ ✅ اگر بخوای این مسئله رو حل کنی، اولین قدمت چیه؟ و یکی از سوال‌های مورد علاقه‌م همیشه اینه: 💡 «جذاب‌ترین چالشی که تا امروز حل کردی چی بوده؟» نه برای اینکه جواب درست یا غلط داره... برای اینکه از روی نحوه تعریف کردنش میشه فهمید: چقدر عمیق فکر می‌کنه. چطور مسئله رو تحلیل می‌کنه. از چه ابزارهایی استفاده کرده. و مهم‌تر از همه... آیا از حل کردن مسئله لذت می‌بره یا فقط دنبال بستن تیکت بوده؟ 😄 به نظر من، گاهی با همین چند سوال میشه شناختی از یک مهندس به دست آورد که شاید با یک ساعت کدنویسی هم به دست نیاد. ❓حالا دوست دارم نظر شما رو هم بدونم. اگر شما مصاحبه‌کننده باشید، اولین سوالی که از یک Database Developer یا Data Engineer می‌پرسید چیه؟1,80%
23 дек.سلام دوستان 🔍 یک چالش جالب در SQL Server که می‌تونست یک مجموعه رو زمین‌گیر کنه! چند وقت پیش در یکی از مجموعه‌ها با یک مشکل عجیب مواجه بودن 👀 سیستم از یک تعداد کاربر مشخص به بعد خطا می‌داد و اجازه نمی‌داد اتصال جدیدی به دیتابیس برقرار بشه. 🔎 بعد از دیدن خطا، اولین چیزی که به ذهنم رسید این بود: احتمالاً تنظیمات user connections دستکاری شده. مشکل اینجا بود که حتی اتصال عادی هم به دیتابیس برقرار نمی‌شد! با کلی داستان و از طریق sqlcmd تونستم مستقیم به Engine وصل بشم 💪 📌 با بررسی تنظیمات: 'sp_configure 'user connections مشخص شد مقدار روی 100 ست شده 😐 🔧 راه‌حل ساده ولی حیاتی بود: مقدار user connections رو روی 0 گذاشتم عدد 0 یعنی: 👉 SQL Server خودش مدیریت می‌کنه (تا حدود 32767 اتصال همزمان) بعد از اعمال تغییر، مجبور شدیم یک بار سرویس SQL Server رو ریست کنیم 🔄 و… مشکل به‌طور کامل حل شد ✅ ✨ نکته جالب‌تر؟ کاربران می‌گفتن حتی سرعت سیستم هم بهتر شده! احتمالاً سیستم مدام سعی می‌کرد اتصال بگیره، خطا می‌خورد و منتظر می‌موند تا دوباره تلاش کنه ⏳ 🧠 جمع‌بندی مهم: هر عددی که در SQL Server می‌بینید، معمولاً پشتش یک منطق و سناریو وجود داره. این تنظیمات رو: ❌ با حدس ❌ با سلیقه ❌ یا «ببینیم با کدوم عدد حال می‌کنیم» نباید تغییر داد! ⚠️ یک عدد اشتباه، خیلی راحت می‌تونه کل یک شرکت رو دچار اختلال کنه. کمی دقت بیشتر در این جزئیات، هزینه‌های خیلی بزرگی رو کم می‌کنه. #SQLServer #DBA #Performance #Troubleshooting #Database #Production #Experience1,64%
27 июл.چند روز پیش روی یکی از دیتابیس‌ها با یک سناریوی جالب روبه‌رو شدم که شاید برای خیلی از DBAها آشنا باشد. کاربران از کندی شدید سیستم شکایت داشتند. ⏱️ زمان اجرای بعضی Updateها به ۷ تا ۸ ثانیه رسیده بود. اولین چیزی که در Wait Stats جلب توجه می‌کرد، مقدار بالای LCK_M_U بود. اگر فقط به همین Wait نگاه کنیم، احتمالاً اولین حدس این است که مشکل از Locking، Isolation Level یا یک Query بد است. اما وقتی Blocking Chain را بررسی کردم، داستان چیز دیگری بود... تقریباً تمام Sessionها پشت یک Session Block شده بودند. و آن Session فقط یک Wait قابل توجه داشت: 🔴 WRITELOG همان‌جا مشخص شد که احتمالاً مشکل اصلی Lock نیست. مشکل این بود که Commit تراکنش‌ها دیر انجام می‌شد. در SQL Server، در حالت عادی (Full Durability)، زمانی که دستور COMMIT اجرا می‌شود، باید رکوردهای Transaction Log مربوط به آن تراکنش روی فایل Log (LDF) پایدار (Harden) شوند. تا زمانی که Commit کامل نشود، Lockهای آن تراکنش نیز آزاد نمی‌شوند. بنابراین اگر به هر دلیلی Flush شدن Transaction Log کند باشد: یک اینکه Commit دیرتر کامل می‌شود. دوم اینکه Lockها مدت بیشتری نگه داشته می‌شوند. سوم اینکه Sessionهای دیگر پشت آن منتظر می‌مانند. و نتیجه چیزی است که ما به شکل LCK_M_U و Blocking مشاهده می‌کنیم. برای اطمینان از فرضیه، روی Database گزینه Delayed Durability را در حالت ALLOWED فعال کردم. نتیجه واقعاً جالب بود. 🚀 زمان Updateها از حدود ۷ تا ۸ ثانیه به کمتر از ۱۰۰ میلی‌ثانیه رسید. تقریباً تمام Blockingها از بین رفتند. این تجربه دوباره یک نکته مهم را برایم یادآوری کرد: 💡 همیشه بزرگ‌ترین Wait الزاماً ریشه مشکل نیست. گاهی چیزی که می‌بینیم فقط اثر دومینویی یک Bottleneck دیگر است. در این سناریو، LCK_M_U علت نبود؛ پیامد بود. ریشه اصلی، WRITELOG بود که باعث می‌شد Commitها دیرتر کامل شوند و در نتیجه Lockها نیز دیرتر آزاد شوند. البته یک نکته مهم را هم نباید فراموش کرد. توجه : Delayed Durability یک راهکار بدون هزینه نیست. وقتی آن را فعال می‌کنید، SQL Server ممکن است بعضی Commitها را قبل از Flush شدن Log به دیسک به Application برگرداند. اگر قبل از Flush، Crash یا قطع برق اتفاق بیفتد، آخرین Transactionهای Commit شده اما هنوز Flush نشده ممکن است از بین بروند. به همین دلیل، این قابلیت باید با توجه به نیازهای کسب‌وکار و میزان ریسک قابل قبول استفاده شود؛ نه صرفاً برای کاهش Waitها. ❓برای شما هم پیش آمده که یک Wait مثل LCK_M_U فقط یک علامت باشد و بعد از بررسی دقیق‌تر متوجه شوید ریشه اصلی مشکل جای دیگری بوده است؟1,50%
25 дек.سلام دوستان 📉 Shrink در SQL Server به روایت یک فضای کار اشتراکی! فرض کن یکی میره یه فضای کار اشتراکی 🏢 اوایل کارش کوچیکه، یه میز اشتراکی می‌گیره. کم‌کم کارش می‌گیره 📈، میگه «نه، من یه اتاق می‌خوام» 🚪 اتاق رو می‌گیره، کارش راه می‌افته، همه چی خوبه 😌 فرداش چی؟ میگه «نه بابا، الان اتاق زیادیه» اتاق رو پس میده، برمی‌گرده میز اشتراکی 😐 عصر دوباره کار زیاد میشه: «بچه‌ها اتاق بدین!» دوباره اتاق می‌گیره… پس میده… می‌گیره… پس میده… 🤦‍♂️ حالا صاحب فضای کار اشتراکی کلافه نشده؟ دیوارها جابه‌جا نمی‌شن؟ نظم فضا به هم نمی‌ریزه؟ 😵 📌 Shrink توی SQL Server دقیقاً همینه! دیتابیس رشد می‌کنه 📊 شما Shrink می‌کنی چون «فضا خالیه» دوباره دیتا میاد، دوباره رشد می‌کنه دوباره Shrink نتیجه؟ Fragmentation شدید 🧩 فشار بی‌خودی به IO 💥 بدتر شدن Performance 🐌 📢 Shrink یعنی پس گرفتن فضا، نه مدیریت فضا! Shrink برای شرایط خاصه: بعد از حذف دائمی حجم عظیمی از دیتا وقتی مطمئنی دیگه به اون فضا نیاز نداری نه برای اینکه: ❌ هر هفته دیسک خالی ببینی ❌ یا وجدان DBA‌ت آروم بشه 😄 و این مساله هم برای فایل LDF صدق می کنه هم MDF. بارها توی همه Job ها من Job برای Shrink دیدم و ایجاد Fragmentation بر روی LDF ها. 🎯 نتیجه: به جای این همه «اتاق پس بده، اتاق بگیر» یه فضای مناسب بگیر، درست استفاده کن، و بگذار دیتابیس با آرامش رشد کنه و برای کنترل LDF هم تهیه بکاپ منظم از Log ها به این مساله به شدت کمک می کنه.🧘‍♂️ hashtag#SQLServer hashtag#DBA hashtag#Shrink hashtag#Performance hashtag#DatabaseLife hashtag#طنز_فنی 😄1,39%
26 июн.خیلی ازمن این سوال پرسیده میشه که میخوایم SQL Server رو شروع کنیم باید چیکار کنیم. ببینید شما اول باید مشخص کنید در چه مسیری میخواین پیش برید این چند مسیر در ادامه یادگیری SQL Server وجود داره. 1- فعالیت به عنوان DBA یا Database Administrator 2- فعالیت به عنوان T-SQL Developer 3- فعالیت به عنوان تحلیلگر داده و طراح گزارشات خوب برای هر سه مسیر اولین و مهمترین چیز ، یادگیری T-SQL هست. هیچکدوم از این سه مسیر بدون یادگیری حرفه ای T-SQLمعنی ندارن. برای T-SQL بهترین و کاملترین منبع ، کتاب T-SQL Fundamental آقای Itzik Ben-GAN هست . من هم همین کتاب رو به صورت کامل در مکتبخونه تدریس کردم که لینکش رو قرار میدم. خوب حالا مسیر اول شما باید علاقمند باشین به دیباگ سرورها ، بتونید استرس خودتون رو کنترل کنید. علاقمند باشین به کارهای پیچیده و پرحجم. مطالعات عمیق روی حوزه های مختلف داشته باشین. برای مسیر دوم باید همین مسیر T-SQL رو پیشرفته تر مطالعه کنید و به حوزه Performance Tuning هم سری بزنید. ( یک دوره هم دراین زمینه در مکتبخونه ضبط کردم) برای حوزه سوم بعد از درک کامل T-SQL باید به سراغ مفاهیم BI برید و با داشبوردها کار کنید. با ETL ها کار کنید و با SSAS آشنا بشین. بعد هم در ادامه برید سراغ پایتون و یادگیری ماشین برای تحلیل های عمیقتر. برای حرفه ای شدن در هر حوزه حداقل یک سال زمان نیاز خواهید داشت برای هر حوزه هم بازارکار خیلی خوبی در کشور وجود داره و به شدت بازار کار تشنه هست. اینم لینک هر دو دوره . https://maktabkhooneh.org/course/%D8%A2%D9%85%D9%88%D8%B2%D8%B4-sql-server-performance-tuning-mk6185/?v=1 https://maktabkhooneh.org/course/%D8%A2%D9%85%D9%88%D8%B2%D8%B4-sql-%D9%BE%D8%A7%DB%8C%DA%AF%D8%A7%D9%87-%D8%AF%D8%A7%D8%AF%D9%87-sql-server-mk1378/?v=11,32%
3 дек.گاهی وقتا برای فهمیدن پشت‌صحنه‌ی واقعی SQL Server باید یه ذره چراغ‌قوه‌ی مخفی روشن کنیم 😎🔦 یکی از چیزهایی که همیشه کمکم کرده بفهمم دقیقاً اون زیر چه خبره، همین دستور معروفه: dbcc traceon(3004,3604,-1) این دستور باعث میشه جزییات کامل عملیات Backup و Restore رو ببینی؛ جزییاتی که SQL Server معمولاً ساکت و بی‌صدا انجامشون میده ولی ما می‌خوایم بدونیم دقیقاً در حال رخ دادن چیه ⚙️👀 نکته‌ی جالبش اینه که تو این جزییات دقیقاً مشخص می‌کنه: ✔️بکاپ یا ریستور با چه پارامترهایی داره انجام میشه، ✔️کدوم مرحله بیشترین زمان رو می‌بلعه، ✔️و چطور می‌تونی کل فرآیند رو بهینه‌تر کنی ⏱️🚀 وقتی فعالش می‌کنی، انگار وارد اتاق کنترل موتور SQL Server شدی و داری قدم‌به‌قدم همه‌چیز رو لایو نگاه می‌کنی 🔍💡 و اما نکته‌ی مهم برای کسایی که تازه با این Trace Flagها آشنا می‌شن: ✔️Trace Flag 3004: مسئول نوشتن لاگ عملیات Backup/Restore هست. ✔️Trace Flag 3604: به SQL Server میگه همین لاگ‌ها رو مستقیم داخل نتیجه‌ی همون کوئری نشون بده. یعنی دقیقاً همان لحظه همونجا می‌بینی چه اتفاقی داره میفته 😍📜 برای من این چیزا فقط یه دستور نیستن؛ کلیدهایی هستن برای اینکه رفتار دیتابیس رو بفهمم، تحلیل کنم و دقیق‌تر از همیشه بهینه‌سازی انجام بدم. #SQLServer #DBA #TraceFlag #BackupRestore #PerformanceTuning #DatabaseInternals #Monitoring #MicrosoftSQLServer #DataEngineering1,17%
28 дек.سلام دوستان 💼🌳 چالش همیشگی ما با درخت‌های سلسله‌مراتبی در SQL! همیشه وقتی با ساختار درختی کار می‌کنیم، معمولاً از ریشه شروع می‌کنیم و تا برگ‌ها می‌رویم. اما یه سؤال جالب پیش میاد: ❓ فرض کنید شما یه نقطه وسط درخت دارید و می‌خواید بفهمید این رکورد به کدوم ریشه یا مدیر اصلی وصل می‌شه؟ برای مثال: مشخصات یک کارمند را دارید و می‌خواید ببینید در چارت سازمانی، مسیرش تا مدیر ارشد کجاست. اینجاست که باید برعکس فکر کنید: از پایین به بالا حرکت کنید، نه از بالا به پایین. و نکته جالب: در کدنویسی و SQL، مدل بازگشتی فرقی نمی‌کنه، فقط جهت پیمایش عوض می‌شه 😎 🔹 ساختار جدول عمومی (می‌تونید تست کنید) CREATE TABLE Table1 ( Id UNIQUEIDENTIFIER PRIMARY KEY, Name NVARCHAR(100), ParentId UNIQUEIDENTIFIER NULL ); Id → شناسه رکورد ParentId → شناسه والد (NULL یعنی ریشه) Name → نام رکورد 🔹 کوئری CTE برای پیدا کردن مسیر تا ریشه DECLARE @InputId UNIQUEIDENTIFIER = 'YOUR_RECORD_ID_HERE'; WITH ReverseCTE AS ( -- شروع از رکورد مورد نظر SELECT Id, ParentId, Name, 0 AS Level FROM Table1 WHERE Id = @InputId UNION ALL -- پیمایش به سمت والد SELECT p.Id, p.ParentId, p.Name, c.Level + 1 FROM Table1 p INNER JOIN ReverseCTE c ON c.ParentId = p.Id WHERE c.ParentId IS NOT NULL ) SELECT * FROM ReverseCTE ORDER BY Level DESC; -- ریشه بالای خروجی اگر فقط ریشه براتون مهمه: SELECT TOP 1 Id, Name FROM ReverseCTE ORDER BY Level DESC; 🔹 نکات حرفه‌ای 💡 برای هر عمق درختی جواب می‌ده مناسب گزارش‌ها، داشبوردها و تحلیل سلسله‌مراتبی می‌تونید مسیر رو به صورت رشته /Root/Parent/Child/... هم بسازید تا راحت نمایش بدید 🧠 تجربه شخصی: وقتی شما از پایین شروع می‌کنید و مسیر تا ریشه رو پیدا می‌کنید، دید کامل‌تری نسبت به سلسله‌مراتب پیدا می‌کنید. مثل اینه که بفهمید یک کارمند دقیقاً تحت چه مدیریتی و چه شاخه‌ای از سازمان قرار گرفته.1,10%
1 янв.تا حالا Running Total تو SQL Server نوشتی و با خیال راحت رد شدی؟ 😌 📌 معمولاً برای Running Total یه چیزی شبیه این می‌نویسیم: SUM(TotalDue) OVER ( PARTITION BY CustomerID ORDER BY OrderDate ) همه‌چیز هم ظاهراً درسته… اما دقیقاً همین‌جا مشکل شروع میشه 😐 🔍 مشکل کجاست؟ وقتی داخل OVER فقط ORDER BY می‌نویسیم و چیز دیگه‌ای مشخص نمی‌کنیم، خود SQL Server به‌صورت پیش‌فرض از این استفاده می‌کنه 👇 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW و این یعنی چی؟ 🤔 یعنی اگر تو ستون ORDER BY (مثلاً OrderDate) مقدار تکراری وجود داشته باشه: اونقوت SQL Server تمام ردیف‌هایی که تاریخ یکسان دارن رو «یک ردیف منطقی» در نظر می‌گیره و Running Total برای همه اون‌ها با هم محاسبه میشه نتیجه؟ ➕ جمع یه‌هو می‌پره 😵‍💫 چیزی که حس می‌کنیم غلطه، ولی در واقع «غیرمنتظره» است ❗️ نکته مهم: 1- SQL Server اشتباه نکرده 2- ما ناخواسته رفتار RANGE رو فعال کردیم 🚀 راه‌حل درست و حرفه‌ای: اگه Running Total واقعی می‌خوای، یعنی ردیف‌به‌ردیف و بدون پرش، باید صریح بنویسی: SUM(TotalDue) OVER ( PARTITION BY CustomerID ORDER BY OrderDate ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) یا حتی کوتاه‌تر: ROWS UNBOUNDED PRECEDING ✔️ محاسبه دقیق ✔️ بدون رفتار عجیب ✔️ بازدهی خیلی بهتر (In-Memory به‌جای TempDB) 🧠 جمع‌بندی همیشه Defaultها دوست ما نیستن استفاده از RANGE فقط وقتی خوبه که عمداً بخوای Tieها یکی حساب بشن برای ۹۹٪ سناریوهای Running Total → ROWS رو همیشه صریح بنویس یه خط کداضافه ، ولی کلی تفاوت تو نتیجه و Performance 🔥 #SQLServer #TSQL #DBA #Performance #WindowFunctions #RunningTotal #DatabaseTips1,06%
11 дек.امروز برای بررسی یک دیتابیس از یک نرم‌افزار در کشور دوست و همسایه 🌍 (همون سرزمین فرصت‌ها و محل تحقق آمال و آرزوهای همه ما 😅✈️) وصل شدم. حالا اینکه مدیریت درست‌وحسابی دیتابیس نداشتن، بماند… 🤦‍♂️ اما اصل ماجرا 👇 رفتم سراغ Jobهای بکاپ. دیدم دوست عزیزمون رفته پنل زمان‌بندی رو باز کرده، چون برای هر روز هفته یه چک‌باکس گذاشته بودن، ایشون هم فکر کرده باید برای هر روز یه Job جدید بسازه! 😂😂 یعنی ۷ تا جاب بکاپ، یکی برای شنبه، یکی دوشنبه… انگار بکاپ گرفتن نذریه و باید روز به روز پخش بشه 😄🍛 بابا یه دونه ماوس برداری یه دابل‌کلیک بزنی ببینی شاید بشه چندتا روز رو با هم انتخاب کرد… ولی خب… ظاهراً ماوسش همون روز مرخصی بوده 🐭💤 راستش چیزهای عجیب زیاد دیدم، اما این یکی واقعاً هنر خاصی می‌خواست 🎨😆 شما تا حالا به همچین شاهکارهای مهندسی برخوردین؟ تجربه‌های باحال و عجیب‌غریب‌تون رو بگین بخندیم 😂👇1,03%