ما توی SQL Server یه قابلیتی داریم به اسم Audit Log.
حالا یعنی چی؟
فرض کن داری با ماشینت توی خیابون حرکت می‌کنی:
از یه طرف دوربین‌ها همه‌جا هستن، از یه طرف پلیس نامحسوس رد میشه، اون وسط هم پلیس ایستاده داره سرعت رو می‌گیره. یعنی هر حرکتت رصد میشه و کافیه یه خطا کنی، سریع مچت رو می‌گیرن 🚨
دقیقاً همین کار رو Audit Log توی دیتابیس انجام می‌ده.
یا اگه بخوام یه مثال دیگه بزنم: شنیدین میگن خدا برای هر آدمی یه فرشته گذاشته که حتی وقتی دستتو می‌کنی توی دماغت هم یادداشت می‌کنه؟ 😅
چرا؟ برای اینکه اون دنیا جای حاشا نباشه و فیلمشو بذارن جلوت.
Audit Log هم حکم همون فرشته رو داره. هرکاری کنی ثبت میشه، تا فردا روز نشه گفت: «من نبودم، دستم خورد!» 😉
حالا یعنی چی؟
فرض کن داری با ماشینت توی خیابون حرکت می‌کنی:
از یه طرف دوربین‌ها همه‌جا هستن، از یه طرف پلیس نامحسوس رد میشه، اون وسط هم پلیس ایستاده داره سرعت رو می‌گیره. یعنی هر حرکتت رصد میشه و کافیه یه خطا کنی، سریع مچت رو می‌گیرن 🚨
دقیقاً همین کار رو Audit Log توی دیتابیس انجام می‌ده.
یا اگه بخوام یه مثال دیگه بزنم: شنیدین میگن خدا برای هر آدمی یه فرشته گذاشته که حتی وقتی دستتو می‌کنی توی دماغت هم یادداشت می‌کنه؟ 😅
چرا؟ برای اینکه اون دنیا جای حاشا نباشه و فیلمشو بذارن جلوت.
Audit Log هم حکم همون فرشته رو داره. هرکاری کنی ثبت میشه، تا فردا روز نشه گفت: «من نبودم، دستم خورد!» 😉
👍22❤4🤨1
سلام دوستان
🚀 از ۱۰ میلیون Logical Read تا فقط ۲۵۰!
یکی از کوئری‌هایی که بررسی می‌کردم، به خاطر استفاده‌ی از OPENJSON ( که در اونجا بهش نیازی نبود ) بیش از ۱۰ میلیون logical read داشت و اجرای اون حدود ۱۰ ثانیه CPU time طول می‌کشید.
با بازنویسی ساده و حذف بخش‌های غیرضروری، همون کوئری در نهایت:
✅ به ۸ میلی‌ثانیه زمان اجرا رسید
به تصاویر که نگاه کنید میزان Logical Read مخصوصا روی Worktable که برای استفاده از Tempdb هست مشخصه.
📊 این تجربه دوباره نشون داد که همیشه لازم نیست به سراغ راه‌حل‌های پیچیده بریم. گاهی یک بازنویسی ساده می‌تونه بیش از هزار برابر بهبود در پرفورمنس ایجاد کنه.
❓ شما آخرین باری که یک کوئری رو به این شدت بهینه کردید، کی بوده؟
🚀 از ۱۰ میلیون Logical Read تا فقط ۲۵۰!
یکی از کوئری‌هایی که بررسی می‌کردم، به خاطر استفاده‌ی از OPENJSON ( که در اونجا بهش نیازی نبود ) بیش از ۱۰ میلیون logical read داشت و اجرای اون حدود ۱۰ ثانیه CPU time طول می‌کشید.
با بازنویسی ساده و حذف بخش‌های غیرضروری، همون کوئری در نهایت:
✅ به ۸ میلی‌ثانیه زمان اجرا رسید
به تصاویر که نگاه کنید میزان Logical Read مخصوصا روی Worktable که برای استفاده از Tempdb هست مشخصه.
📊 این تجربه دوباره نشون داد که همیشه لازم نیست به سراغ راه‌حل‌های پیچیده بریم. گاهی یک بازنویسی ساده می‌تونه بیش از هزار برابر بهبود در پرفورمنس ایجاد کنه.
❓ شما آخرین باری که یک کوئری رو به این شدت بهینه کردید، کی بوده؟
👍13❤3
🤔 تا حالا خواستی دقیق بدونی جداول سیستمی SQL Server چطوری کار می‌کنن و چه روابطی با هم دارن؟
یه روش خیلی باحال برای یادگیری هست:
1️⃣ یه SQL Server روی سیستمت نصب کن.
2️⃣ یه ابزار مانیتورینگ مثل Profiler یا ترجیحاً XEvents اجرا کن.
3️⃣ شروع کن با SSMS کار کردن. مثلاً:
لیست دیتابیس‌ها رو باز کن.
روی گزینه‌های مختلف کلیک کن.
🔎 اینجا هر Query که توسط SSMS اجرا میشه (برای همون کاری که تو انجام دادی) توی ابزار لیست میشه و می‌تونی ببینی.
به این شکل خیلی راحت می‌فهمی پشت پرده دقیقاً چه اتفاقی میفته، چه جداول سیستمی درگیر میشن و کل ماجرا چطور مدیریت میشه.
⚡️ نتیجه؟ درک عمیق‌تر و واقعی‌تر از SQL Server 🚀
یه روش خیلی باحال برای یادگیری هست:
1️⃣ یه SQL Server روی سیستمت نصب کن.
2️⃣ یه ابزار مانیتورینگ مثل Profiler یا ترجیحاً XEvents اجرا کن.
3️⃣ شروع کن با SSMS کار کردن. مثلاً:
لیست دیتابیس‌ها رو باز کن.
روی گزینه‌های مختلف کلیک کن.
🔎 اینجا هر Query که توسط SSMS اجرا میشه (برای همون کاری که تو انجام دادی) توی ابزار لیست میشه و می‌تونی ببینی.
به این شکل خیلی راحت می‌فهمی پشت پرده دقیقاً چه اتفاقی میفته، چه جداول سیستمی درگیر میشن و کل ماجرا چطور مدیریت میشه.
⚡️ نتیجه؟ درک عمیق‌تر و واقعی‌تر از SQL Server 🚀
❤12👍6🔥1
سلام دوستان
🛒 یادتونه سال‌ها قبل از اینکه هایپراستار بیاد، برای هر چیزی مجبور بودیم بریم یه فروشگاه مخصوص همون؟
هیچ مرجعی نبود که یک‌جا همه نیازها رو پوشش بده.
وقتی هایپراستار اومد، ملت استقبال کردن چون همه‌چی یه جا جمع بود:
✅ برندهای خوب
✅ اجناس درست‌حسابی
✅ خرید راحت‌تر
نتیجه؟ دسترسی ساده‌تر به کالاها و در عوض فروش مغازه‌های اطراف به شدت افت کرد.
حالا دقیقاً همین اتفاق توی دنیای SQL Server و Data Warehouse (DW) میفته.
📊 توی DW:
داده‌ها از منابع مختلف (مثل همون فروشگاه‌ها یا کارخانه‌ها) جمع میشن.
برای رکوردها Master Data پیاده‌سازی میشه (یه کدینگ واحد برای کالاها).
داده‌ها تمیز و پاکسازی میشن (کالاهای خراب و برندهای ضعیف حذف میشن).
و در نهایت کاربر با یه منبع داده‌ی مرتب و درست سروکله می‌زنه و می‌تونه به صورت تجمیعی به همه نیازهای گزارش‌گیری و تصمیم‌گیری دسترسی داشته باشه—بدون اینکه مجبور باشه بره سراغ تک‌تک سیستم‌ها.
⚠️ پس اگه جایی اومدن براتون DW و BI راه انداختن ولی این اتفاقا نیفتاد… احتمالاً یه جای کار می‌لنگه 😉
🛒 یادتونه سال‌ها قبل از اینکه هایپراستار بیاد، برای هر چیزی مجبور بودیم بریم یه فروشگاه مخصوص همون؟
هیچ مرجعی نبود که یک‌جا همه نیازها رو پوشش بده.
وقتی هایپراستار اومد، ملت استقبال کردن چون همه‌چی یه جا جمع بود:
✅ برندهای خوب
✅ اجناس درست‌حسابی
✅ خرید راحت‌تر
نتیجه؟ دسترسی ساده‌تر به کالاها و در عوض فروش مغازه‌های اطراف به شدت افت کرد.
حالا دقیقاً همین اتفاق توی دنیای SQL Server و Data Warehouse (DW) میفته.
📊 توی DW:
داده‌ها از منابع مختلف (مثل همون فروشگاه‌ها یا کارخانه‌ها) جمع میشن.
برای رکوردها Master Data پیاده‌سازی میشه (یه کدینگ واحد برای کالاها).
داده‌ها تمیز و پاکسازی میشن (کالاهای خراب و برندهای ضعیف حذف میشن).
و در نهایت کاربر با یه منبع داده‌ی مرتب و درست سروکله می‌زنه و می‌تونه به صورت تجمیعی به همه نیازهای گزارش‌گیری و تصمیم‌گیری دسترسی داشته باشه—بدون اینکه مجبور باشه بره سراغ تک‌تک سیستم‌ها.
⚠️ پس اگه جایی اومدن براتون DW و BI راه انداختن ولی این اتفاقا نیفتاد… احتمالاً یه جای کار می‌لنگه 😉
❤6👍1
سلام
🚀 یکی از پروژه‌های بهینه‌سازی دیتابیس که این روزا روش کار می‌کنم، یه ماجرای جالب داشت:
رفیقای قدیم یه علاقه خاصی به ایندکس داشتن 😅
تو جداول پرکاربرد، رو هر چی فیلد بود یه ایندکس ساخته بودن!
بعدش مثلاً علی رفته بود یه ایندکس روی تاریخ گذاشته، محمد اومده دیده "ای بابا! این علی بدون وضو ایندکس روی تاریخ گذاشته. خلاصه با نیت خالص و با وضو دوباره روی تاریخ ایندکس ایجاد کرده شاید امید به خدا درست کار کنه. " 😅✌️
ولی خب اون قبلی رو حذف نکرده بود، فقط اضافه کرده بود!
نام‌گذاری‌ها هم در حد لیگ قهرمانان اروپا 🤦♂️ از 1 شروع کرده بودن و خیاری ادامه داده بودن.
📞 آخرش هم مشتری زنگ می‌زنه:
"داداش می‌خوایم یه رکورد ثبت کنیم، جد و آبادمون داره جلوی چشممون رد میشه! چند دقیقه باید صبر کنیم تا بشه!"
یاد اون دیالوگ اکبر عبدی توی اخراجی‌ها افتادم که می‌گفت:
«بابام می‌گفت هرچی نماز بیشتر بخونی بهتره»
اینا هم فکر کردن هرچی ایندکس بیشتر بذارن، دیتابیس خوشحال‌تر میشه! 😂
گفتن دیگه از ایندکس چیزی برای دیتابیس کم و کسری نذاریم. 😂
🔑 نتیجه اخلاقی:
خداوکیلی این مدلی دیتابیس طراحی نکنید. ایندکس‌گذاری علمه، نه تعداد! 😉
🚀 یکی از پروژه‌های بهینه‌سازی دیتابیس که این روزا روش کار می‌کنم، یه ماجرای جالب داشت:
رفیقای قدیم یه علاقه خاصی به ایندکس داشتن 😅
تو جداول پرکاربرد، رو هر چی فیلد بود یه ایندکس ساخته بودن!
بعدش مثلاً علی رفته بود یه ایندکس روی تاریخ گذاشته، محمد اومده دیده "ای بابا! این علی بدون وضو ایندکس روی تاریخ گذاشته. خلاصه با نیت خالص و با وضو دوباره روی تاریخ ایندکس ایجاد کرده شاید امید به خدا درست کار کنه. " 😅✌️
ولی خب اون قبلی رو حذف نکرده بود، فقط اضافه کرده بود!
نام‌گذاری‌ها هم در حد لیگ قهرمانان اروپا 🤦♂️ از 1 شروع کرده بودن و خیاری ادامه داده بودن.
📞 آخرش هم مشتری زنگ می‌زنه:
"داداش می‌خوایم یه رکورد ثبت کنیم، جد و آبادمون داره جلوی چشممون رد میشه! چند دقیقه باید صبر کنیم تا بشه!"
یاد اون دیالوگ اکبر عبدی توی اخراجی‌ها افتادم که می‌گفت:
«بابام می‌گفت هرچی نماز بیشتر بخونی بهتره»
اینا هم فکر کردن هرچی ایندکس بیشتر بذارن، دیتابیس خوشحال‌تر میشه! 😂
گفتن دیگه از ایندکس چیزی برای دیتابیس کم و کسری نذاریم. 😂
🔑 نتیجه اخلاقی:
خداوکیلی این مدلی دیتابیس طراحی نکنید. ایندکس‌گذاری علمه، نه تعداد! 😉
👍21❤6😁6💯1🤣1
سلام
💔 داستان Shrink در SQL Server 😅
ببینید رفقا، این عملیات Shrink کردن فایل‌های Data عین روابط عاشقانه‌ی پر فراز و نشیبِیه! 😎
یه روز SQL Server میگه:
"دیگه بهت نیاز ندارم 😤"
و فایل Data رو کوچیک می‌کنه (کات می‌کنن خلاصه 💔)
بعد صبح روز بعد دوباره میاد:
"ببین من یه چیزی گفتم... 😅 بیا دوباره با هم باشیم!"
و دوباره فضا می‌گیره 😬
شب دوباره job shrink اجرا میشه 😑
صبح دوباره SQL Server میاد میگه «برگرد پیشم!»
و این چرخه تا ابد ادامه داره... 😭
📣 بابا ولش کنین دیگه! Shrink نکنید، بذارید رابطه‌ش آروم بگیره 😂
#SQLServer #DBA #ShrinkDrama #DatabaseHumor #ITLife #DBALife
💔 داستان Shrink در SQL Server 😅
ببینید رفقا، این عملیات Shrink کردن فایل‌های Data عین روابط عاشقانه‌ی پر فراز و نشیبِیه! 😎
یه روز SQL Server میگه:
"دیگه بهت نیاز ندارم 😤"
و فایل Data رو کوچیک می‌کنه (کات می‌کنن خلاصه 💔)
بعد صبح روز بعد دوباره میاد:
"ببین من یه چیزی گفتم... 😅 بیا دوباره با هم باشیم!"
و دوباره فضا می‌گیره 😬
شب دوباره job shrink اجرا میشه 😑
صبح دوباره SQL Server میاد میگه «برگرد پیشم!»
و این چرخه تا ابد ادامه داره... 😭
📣 بابا ولش کنین دیگه! Shrink نکنید، بذارید رابطه‌ش آروم بگیره 😂
#SQLServer #DBA #ShrinkDrama #DatabaseHumor #ITLife #DBALife
😁11🤣8❤6👍6
📱 جذب فلاترکار پروژه‌ای برای فاز اول اپلیکیشن زیرنویس هوشمند «ساب نوا»
پروژه‌ی ساب نوا (SubNova) یک اپلیکیشن هوشمند برای ترجمه , مدیریت، ویرایش و هماهنگ‌سازی زیرنویس‌هاست که با استفاده از هوش مصنوعی، قابلیت‌های ویژه‌ای مثل ترجمه‌ی خودکار، تشخیص گفتار و زمان‌بندی دقیق ارائه می‌دهد.
در حال حاضر به دنبال یک توسعه‌دهنده Flutter هستیم تا در بخش اپلیکیشن موبایل Android با ما به‌صورت پروژه‌ای (Freelance) همکاری کند.
مهارت‌های مورد نیاز:
• تسلط کامل به Flutter
• آشنایی با API integration (RESTful APIs)
• توانایی کار با ویدیو پلیر و زیرنویس (subtitle handling) در فلاتر
• آشنایی با State Management (Provider / Bloc / GetX)
• تجربه‌ی انتشار اپلیکیشن در Google play و Bazarامتیاز محسوب می‌شود
نوع همکاری: پروژه‌ای (ریموت)
زمان‌بندی: منعطف
دستمزد: توافقی بر اساس توانایی
طرح‌های رابط کاربری اپلیکیشن در Figma طراحی شده و آماده‌ی پیاده‌سازی است.
اگر به پروژه‌های نوآورانه با محوریت هوش مصنوعی علاقه‌مندید و مایلید طرح‌ها را ببینید و بخشی از تیم توسعه‌ی ساب نوا باشید، کافی‌ست به ما پیام بدهید تا دسترسی مشاهده‌ی طرح‌ها و جزئیات همکاری برایتان ارسال شود.
📧 ارسال رزومه و نمونه‌کار به تلگرام : @masoud_mj2
یا پیام در واتساپ: 09152028188
پروژه‌ی ساب نوا (SubNova) یک اپلیکیشن هوشمند برای ترجمه , مدیریت، ویرایش و هماهنگ‌سازی زیرنویس‌هاست که با استفاده از هوش مصنوعی، قابلیت‌های ویژه‌ای مثل ترجمه‌ی خودکار، تشخیص گفتار و زمان‌بندی دقیق ارائه می‌دهد.
در حال حاضر به دنبال یک توسعه‌دهنده Flutter هستیم تا در بخش اپلیکیشن موبایل Android با ما به‌صورت پروژه‌ای (Freelance) همکاری کند.
مهارت‌های مورد نیاز:
• تسلط کامل به Flutter
• آشنایی با API integration (RESTful APIs)
• توانایی کار با ویدیو پلیر و زیرنویس (subtitle handling) در فلاتر
• آشنایی با State Management (Provider / Bloc / GetX)
• تجربه‌ی انتشار اپلیکیشن در Google play و Bazarامتیاز محسوب می‌شود
نوع همکاری: پروژه‌ای (ریموت)
زمان‌بندی: منعطف
دستمزد: توافقی بر اساس توانایی
طرح‌های رابط کاربری اپلیکیشن در Figma طراحی شده و آماده‌ی پیاده‌سازی است.
اگر به پروژه‌های نوآورانه با محوریت هوش مصنوعی علاقه‌مندید و مایلید طرح‌ها را ببینید و بخشی از تیم توسعه‌ی ساب نوا باشید، کافی‌ست به ما پیام بدهید تا دسترسی مشاهده‌ی طرح‌ها و جزئیات همکاری برایتان ارسال شود.
📧 ارسال رزومه و نمونه‌کار به تلگرام : @masoud_mj2
یا پیام در واتساپ: 09152028188