سلام دوستان

🔑 توی 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 راه انداختن ولی این اتفاقا نیفتاد… احتمالاً یه جای کار می‌لنگه 😉

سلام



🚀 یکی از پروژه‌های بهینه‌سازی دیتابیس که این روزا روش کار می‌کنم، یه ماجرای جالب داشت:

رفیقای قدیم یه علاقه خاصی به ایندکس داشتن 😅

تو جداول پرکاربرد، رو هر چی فیلد بود یه ایندکس ساخته بودن!

بعدش مثلاً علی رفته بود یه ایندکس روی تاریخ گذاشته، محمد اومده دیده "ای بابا! این علی بدون وضو ایندکس روی تاریخ گذاشته. خلاصه با نیت خالص و با وضو دوباره روی تاریخ ایندکس ایجاد کرده شاید امید به خدا درست کار کنه. " 😅✌️

ولی خب اون قبلی رو حذف نکرده بود، فقط اضافه کرده بود!

نام‌گذاری‌ها هم در حد لیگ قهرمانان اروپا 🤦‍♂️ از 1 شروع کرده بودن و خیاری ادامه داده بودن.

📞 آخرش هم مشتری زنگ می‌زنه:

"داداش می‌خوایم یه رکورد ثبت کنیم، جد و آبادمون داره جلوی چشممون رد میشه! چند دقیقه باید صبر کنیم تا بشه!"

یاد اون دیالوگ اکبر عبدی توی اخراجی‌ها افتادم که می‌گفت:

«بابام می‌گفت هرچی نماز بیشتر بخونی بهتره»

اینا هم فکر کردن هرچی ایندکس بیشتر بذارن، دیتابیس خوشحال‌تر میشه! 😂

گفتن دیگه از ایندکس چیزی برای دیتابیس کم و کسری نذاریم. 😂



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

خداوکیلی این مدلی دیتابیس طراحی نکنید. ایندکس‌گذاری علمه، نه تعداد! 😉

سلام

💔 داستان Shrink در SQL Server 😅

ببینید رفقا، این عملیات Shrink کردن فایل‌های Data عین روابط عاشقانه‌ی پر فراز و نشیبِیه! 😎



یه روز SQL Server میگه:

"دیگه بهت نیاز ندارم 😤"



و فایل Data رو کوچیک می‌کنه (کات می‌کنن خلاصه 💔)



بعد صبح روز بعد دوباره میاد:

"ببین من یه چیزی گفتم... 😅 بیا دوباره با هم باشیم!"



و دوباره فضا می‌گیره 😬

شب دوباره job shrink اجرا میشه 😑



صبح دوباره SQL Server میاد میگه «برگرد پیشم!»

و این چرخه تا ابد ادامه داره... 😭



📣 بابا ولش کنین دیگه! Shrink نکنید، بذارید رابطه‌ش آروم بگیره 😂

#SQLServer #DBA #ShrinkDrama #DatabaseHumor #ITLife #DBALife

سلام عزیزان
امیدوارم عالی باشین
از این لینک میتونید SQL Server 2025 Developer Edition رو دانلود کنید و باهاش کار کنید و لذت ببرید

فقط سرجدتون از فردا همه پروژه هارو نبرید روی 2025. بذارید حداقل 1 سال از عرضه اون بگذره بعد سوئیچ کنید.😁

شاد باشین

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

https://www.microsoft.com/en-us/sql-server/sql-server-downloads

سلام دوستان


🔄 همان‌طور که قول داده بودم، امروز می‌خواهم درباره فرآیند انتقال اطلاعات (Data Migration) که پیش‌تر درباره‌اش نوشته بودم، توضیح بدم.

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


🖥 1. راه‌اندازی محیط محلی

اول از همه یک سیستم محلی روی لپ‌تاپم راه‌اندازی کردم تا بتوانم دیتابیس را کامل و دقیق بررسی کنم.

ساختار جداول، فیلدهای حساس، ارتباطات و ساختارهای درختی را تحلیل کردم تا بدانم هر تغییر چه تبعاتی دارد.


🗂 2. آماده‌سازی دیتابیس مقصد

دیتابیس‌های مقصد را روی سیستمم بالا آوردم و شروع کردم به نوشتن اسکریپت جداول اصلی.

اینجا نکته مهم این است که ترتیب ساخت جداول را دقیق رعایت کنید؛

چون برخی جداول، داده‌های پایه‌ای دارند و اگر ترتیب اشتباه باشد، با چالش‌های جدی مواجه می‌شوید.


🔁 3. ایجاد جدول Duplicate برای مدیریت داده‌های تکراری

برای هر جدول، یک جدول جدید به نام Duplicate ساختم.

هر رکوردی که احتمال تکرار ID داشت، وارد این جدول می‌شد تا بعداً درباره‌اش تصمیم بگیرم.

در پروژه فعلی، IDها از نوع GUID هستند، پس احتمال تکرار بسیار کم است — اما وجود این لایه کنترلی ضروری است.


🚚 4. تست انتقال کامل داده‌ها

ابتدا کدهای تولید داده و انتقال اطلاعات را نوشتم و کل دیتا را جابه‌جا کردم تا از صحت فرآیند مطمئن شوم.

بعد از تأیید، آن را تبدیل به پکیج کردم تا:

- قابل نگهداری‌تر باشد،

- برای سایر دیتابیس‌ها هم قابل استفاده باشد،

- و تغییرات در آینده راحت‌تر اعمال شود.


🛡 5. بکاپ‌گیری قبل از هر مرحله

از دیتابیس خام یک بکاپ کامل گرفتم.

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

این کار زمان می‌گیرد، اما تضمین می‌کند فرآیند Migration تمیز و مطمئن پیش برود.


✔️ 6. تست نهایی با نرم‌افزار

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


📌 در پست‌های بعدی، نکات عمیق‌تر و تجربیات بیشتری را درباره طراحی پکیج‌های Migration و چالش‌های واقعی پروژه‌ها به اشتراک می‌گذارم.


شاد باشین.
@Hamidreza_Sadeghian

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



🔍 SET FMTONLY دقیقاً چیه و چرا دیگه بهتره ازش استفاده نکنیم؟

یه نکته فنی که این چند روز دوباره باهاش برخورد کردم و گفتم اینجا هم بگم:



SET FMTONLY ON

خیلی‌ها هنوز توی پروژه‌ها استفاده می‌کنن، در حالی که واقعاً دیگه وقتشه بذاریمش کنار 😄



🧪 SET FMTONLY ON یعنی چی؟

وقتی این گزینه رو فعال می‌کنی:



SET FMTONLY ON;

SELECT * FROM Sales.Orders;



SQL Server اصلاً کوئری رو اجرا نمی‌کنه!

فقط ساختار خروجی رو میده:

- اسم ستون‌ها

- نوع داده‌ها

- نه دیتا می‌خونه

- نه لاجیک اجرا می‌کنه

- نه Temp Table می‌سازه

- نه حتی Cross DB Query اجرا میشه!

برای همون دوران ADO و ODBC قدیم ساخته شده بود.



❌ مشکلش چیه؟

FMTONLY از SQL 2012 به بعد رسماً منقرض شده (Deprecated) چون:

- با Temp Table و Table Variable قاطی می‌کنه

- خیلی وقت‌ها خطای Invalid object name میده

- خروجی DMVها نصفه‌نیمه برمی‌گردونه

- روی نسخه‌های مختلف SQL Server متفاوت رفتار می‌کنه



دقیقاً همون چیزیه که تو ابزارهای مانیتورینگ یا ORMها باعث Errorهای عجیب میشه.



✔️ جایگزین استاندارد و مدرن

به‌جاش از این DMV فوق‌العاده استفاده کنید:



SELECT *

FROM sys.dm_exec_describe_first_result_set

(

N'SELECT CustomerId, TotalPrice FROM Sales.Orders',

NULL,

NULL

);



این کارها رو انجام می‌ده:

✔️ کوئری رو اجرا نمی‌کنه

✔️ ساختار دقیق نتیجه رو برمی‌گردونه

✔️ با نسخه‌های مختلف SQL Server سازگاره

✔️ با Temp Table و Dynamic SQL هم درست کار می‌کنه



🔥 مثال عملیِ واقعی

فرض کن یک Stored Procedure داری:



CREATE PROCEDURE dbo.UspGetOrders

AS

BEGIN

SELECT TOP 100 OrderId, CustomerId, TotalAmount

FROM Sales.Orders

ORDER BY OrderDate DESC;

END



می‌خوای فقط ساختار خروجی رو ببینی، بدون این‌که SP رو واقعاً اجرا کنی:



SELECT *

FROM sys.dm_exec_describe_first_result_set

(

N'EXEC dbo.UspGetOrders',

NULL,

NULL

);



که میاد ساختار جداول و فیلدها رو بهتون ارائه میده.

شما تاحالا ازش استفاده کردین؟