![نحوه اجرای کوئری‌ها را زنده ببینید [شاهکار SQL Server 2016]](https://nikamooz.com/wp-content/uploads/2015/08/live-query-statistics-sql-server-2016-nikamooz.jpg)
در این فیلم آموزشی مسعود طاهری مدرس و متخصص SQL Server شما را با یکی از شاهکارهای SQL Server 2016 آشنا میکند.
همیشه دوست داشتم زمانی که یک کوئری اجرا می‌گردد، نحوه واکشی اطلاعات و همچنین مدل اجرای کوئری را بصورت زنده مشاهده کنم، اکنون این امکان در SQL Server 2016 ارائه گردیده است.
در انتهای فیلم یک مسابقه ترتیب داده‌ایم و دو سوال را مطرح کرده‌ایم حتما در این مسابقه شرکت کنید.
پیشنهاد میکنم حتما این فیلم را مشاهده کنید، از شاهکار SQL Server 2016 لذت ببرید و در مسابقه شرکت کنید.
بسیاری از برنامه نویسان و مدیران بانک اطلاعاتی حرفه‌ای حتی یکبار هم در عمرشان در یک مسابقه فنی و تخصصی شرکت نکرده‌اند!!
پس اگر در این مسابقه شرکت کنید، جزء افراد بسیار کمی خواهید بود که در یک مسابقه فنی و تخصصی شرکت کرده‌اید.
جوایز مسابقه
۱- دوره SQL Server ویژه برنامه نویسان – سطح ۱ [به ارزش ۱،۹۹۰،۰۰۰ ریال]
۲- دوره آنلاین افزایش سرعت تهیه و بازیابی نسخه پشتیبان [به ارزش ۸۹۰،۰۰۰ ریال]
۳- محصول جنون سرعت در SQL Server [به ارزش ۴۹۰،۰۰۰ ریال]
نکته ۱: حتی اگر مطمئن نیستید که پاسخ شما درست است یا نه اصلا مهم نیست
مهم این است که خودتان در این مسابقه فنی بسنجید، پس حتما جواب خودتان را در قسمت نظرات همین صفحه بنویسید.
نکته ۲: شما فقط سه روز فرصت دارید تا در این مسایقه شرکت کنید و از جوایز آن استفاده کنید.
در کمتر از ۴ ساعت بیش از ۲۰۰ بار این ویدئو دانلود شده است.
از تمامی دوستانی که پاسخ ارسال کردند متشکریم.
اسامی دوستانی که پاسخ های صحیح ارائه دادند:
۱- آقای حسین خوش رفتار منفرد
۲- آقای رامین
۳- آقای سید سیاوش گلچوبیان
۴- آقای سپهر صفایی
۵- آقای بشیر محمودی
۶- آقای هادی جباری دارستانی
۷- آقای حامد آتشبار
۸- آقای رحیمیان
۹-آقای آرمان فلاح
از ۹ نفر دوستان بالا به قید قرعه سه نفر برنده شدند که می‌توانید اسامی این سه عزیز را در فیلم زیر مشاهده کنید.
فیلم مراسم قرعه کشی در کلاس SQL Server ویژه برنامه نویسان و انتخاب برندگان
برندگان مسایقه با شماره ۰۲۱۴۴۲۷۷۶۹۹ تماس گرفته تا جوایز به ایشان تحویل گردد. امیدوارم در مسابقات بعدی شما برنده شوید.
نکته ۱: تا زمانی که مسابقه ادامه داشت هیچ پاسخی از دوستان منتشر نشد تا هیچگونه کپی برداری از پاسخ ها نداشته باشیم و در پایان مسابقه پاسخ‌ها را منتشر و برندگان را انتخاب کردیم.
نکته ۲: در یک فیلم جداگانه و کوتاه جواب برندگان را مقایسه خواهیم کرد.
منبع: آموزش برنامه نویسی نیک آموز
62 Comments
Mostapha
متاسفانه فیلم صدا نداره. یا لااقل روی سیستم من صدا نداره
فرید طاهری
سلام
فیلم از بابت صدا مشکلی ندارد. شاید چون MP4 هست باید Codec نصب کنید روی سیستم خودتان. البته شاید.
ولی الان باز دانلود کردم و صدا کاملا گویا هست.
موفق باشید
بهزاد عبادی
خسته نباشید جانانه به تمامی تیم بزرگ نیک اموز
حسین خوش رفتار منفرد
جواب سوال ۱ :
مسعود طاهری
حسین جان سلام
حسین خوش رفتار منفرد
ادامه جواب۲ : راهکاری جایگزین استفاده از nolock استفاده از Snapshot isolation level است. با این روش کاربران در حال خواندن از بانک مزاحم کاربران در حال نوشتن در بانک نمیشوند و تاثیر بسزایی در کاهش lock block ها خواهد داشت.
رامین
جواب سوال اول)
این موضوع بر میگرده به اندازه ایندکس. در ابتدا تعداد Page های جدول ۹ تا است و دیتاهای وارد شده هر کدوم بخشی از این ۹ صفحه رو
پر کرده اند و بنابراین اندازه fragment_count =page_count شده است. با Rebuild کردن ایندکس تمامی داده ها Defrag شده اما
همچنان پراکندگی وجود داره (fragment_count=4). Rebuild
کردن های بعدی هم بعلت کوچک بودن سایز ایندکس توسط SQL Server نادیده گرفته می شوند و بنابراین بی تاثیر خواهند بود. دلیل این امر هم این هست که ایندکس های با سایز
کوچک بر روی mixed extent ها ایجاد
می شوند و از اونجا که این نوع extent ها توسط اشیاء دیگر هم
مورد استفاده اشتراکی قرار می گیرند ممکن است rebuild یا reorganize باعث کاهش میزان پراکندگی
نشود.
جواب سوال دوم)
شما با نوشتن عبارت With(NoLock) در
واقع سطح Isolation Level رو به ReadUnCommited تغییر داده اید. با این کار گرچه میزان همزمانی
تراکنش ها بالا رفته اما به تراکنش Select این امکان رو دادید که بتونه داده های Commit نشده
سایر تراکنش ها رو هم بخونه که در این صورت احتمال بروز خطا در داده های واکشی شده
بالا رفته. این کار همون خوندن داده های کثیف یا Read dirty
data است.
برای جلوگیری از این شرایط کافیه که سطح Isolation Level رو بر روی یکی از گزینه های Snapshot یا Read
Commitedقرار بدید.
مسعود طاهری
جناب رامین عزیز
سید سیاوش گلچوبیان
سلام و تشکر از ویدیو خوب شما. در جواب سوال اول باید گفت اگر، از TF 1118 استفاده نکرده باشیم، به صورت پیش فرض هشت Page اول دیتا (۶۴ کیلوبایت اول) در Mixed Extent ها ذخیره میشوند (و دستور Rebuild بر روی Page های درون Mixed Extent نمیتوانند اقدام موثری انجام دهند زیرا Page های جداول دیگر نیز در آن وجود دارد و آنها را Move نمیکند) و زمانیکه حجم دیتای جدول بیش از ۶۴KB شد SQL Server دیگر از Uniform Extent ها جهت ذخیره سازی استفاده میکند (و این جایی است که دستور Rebuild اثر گذار میشود)، به همین دلیل معمولا جداول کوچک Fragmentation های بالایی دارند.
در پاسخ به سوال دوم نیز، با توجه به آنکه در جدول به طور مداوم در حال Insert هستیم و همچنین بر روی جدول Index نیز داریم، پس طبیعتا همزمان با درج یا حتی آپدیت رکورد های جدول فرایند به روز شدن ایندکس ها را نیز داریم و از آنجا که کلید ایندکس ما بدلیل استفاده از GUID به صورت فزاینده-ترتیبی (Sequential) نمیباشد، پس مدام با مشکل Page Split (نصف شدن Page ها) در ایندکس ها روبرو میشویم (چه ایندکس ما کلاستر باشد و چه نباشد این اتفاق رخ میدهد)، حال وقتی با With (Nolock) اقدام به کوئری زدن میکنیم، مشکل Page Split خود را در حین Range Scan/Allocation Scan نشان میدهد و باعث میشود که رکوردهای کمتر یا گاها رکوردهای تکراری (بیشتر) خوانده شوند. راه حل نیز میتواند عدم استفاده از Nolock یا استفاده از Isolation Level باشد
(متاسفانه نوشتن از صحبت کردن خیلی سخت تره و بیشتر حوصله طلب میکنه، به همین دلیل از کم بودن توضیح عذر خواهی میکنم)
مسعود طاهری
سیاوش جان پاسخ شما کاملا درست و علمی است
سپهر صفایی
پاسخ سوال دوم:
مسعود طاهری
جناب صفای پاسخ شما هم درست بود
علی حاجی آبادی
1- با توجه به نوع ایندکس (Primary key و Unique CLUSTERED INDEX) مشخصا داده های موجود در فیلدهای تاثیرگذار در ایندکس، منحصر بفرد هستند – یعنی هیچ دو رکوردی (در مثال در فیلد RecordID) داده یکسان ندارند، در نتیجه Fragmentation این نوع ایندکسها (PKey ها) از مقدار مشخصی کمتر نخواهد شد
۲- وقتی در یک دستور Select از کیورد (WITH (NOLOCK استفاده میشود، رکوردهایی که transaction آنها هنوز COMMIT نشده اند، خوانده میشوند – یعنی داده هایی که ممکن است هرگز در بانک ثبت نشوند خوانده میشوند – اتفاقی که در حلقه loop مثال زده شده رخ میدهد
مجتبی شهریور
سلام
من دانلود کردم عالی بود
امیدوارم برنده بشم
فرید طاهری
سلام. متشکرم از شما
برای برنده شدن در مسابقه بایستی پاسخ ارسال کنید.
بهرام رمضانی
پاسخ ۱ : از انجا که بعد از هر بار پاک کردن فرگمنشن در واقع دیتا های موجود در page های دیتابیس مرتب شده و فضای اضافی موجود در انها پاک می شود پس بعد از یک بار اعمال کردن این دستور دیگر فضای زایدی وجود ندارد و این عدد ثابت می ماند.
پاسخ ۲ : به دلیل استفاده از WITH(NOLOCK) در کوئری مذکور مشکل ایجاد می شود.زیرا متغیر سالاری توسط چندین کوئری که اجرا کرده ایم در حال تغییر هست و نیز از transaction استفاده نمی شود و متغیر سالاری بین این اجراهای ما در واقع به نوعی به اشتراک گذاشته می شود و ممکن است در لحظه اتمام یک اجرا ان متغیر توسط اجرایی دیگر تغییر کند.یعنی ممکن است در لحظه اتمام اجرا ۱۰۰ باشد ولی در یک لحظه توسط کوئری که هنوز تمام نشده است به ۹۰ تبدیل شود و جواب کوئری تمام شده ۹۰ شود و راه حل این است که باید هر کوئری در یک ترانزکشن جدا اجرا شود و بدن دستور nolock
بشیر محمودی
پاسخ سوال ۱: به علت اینکه تعداد پیج های جدول ۸ عدد است. و ظاهرا sql 8 صفحه اول ایندکس ها و جداول را از extent های غیر یکپارچه استفاده می کند. و ممکن است که همه پیج ها از یک extent نباشند می توان گفت که ممکن است که حداکثر ۸ فراگمنت برای هر پیج داشته باشیم.
پاسخ سوال ۲: به علت دستور WITH(NOLOCK) ممکن است یک ردیف را دوبار یا بیشتر بخوانیم یا اصلا نخوانیم.
مسعود طاهری
آقای محمودی عزیز پاسخ اول شما درست است. این موضوع همان مسئاله Mixed Extent است. در مورد پاسخ دوم هم باید بگم که شما به یکی از مباحث مهم هم اشاره کرده اید همان بحث Duplicate Record در With Nolock است.
محسن ولی زاده
پاسخ سوال ۱: سیستم فایل در سیستم عامل به این شکل عمل می کند که فایل ها را در فضاهای خالی (یا بلااستفاده) دیسک ذخیره می کند. به مرور زمان با حذف و اضافه شدن فایل ها، فضاهای خالی به صورت پراکنده در دیسک پدید می آید. برای فایلی که نمی تواند در یک فضا جا بگیرد، آن فایل به صورت صفحات کوچکتری درآمده و انتهای فایل با اشاره گر به آدرس صفحه بعدی مشخص می شود. بدیهی است که خواندن فایلی که به طور پراکنده بر روی دیسک ذخیره شده است مستلزم حرکت بیشتر هد و انتظار برای رسیدن به قطاع مورد نظر می گردد و هر چه تعداد صفحات بیشتر باشد زمان نهایی خواندن فایل طولانی تر می شود. به همین ترتیب وقتی فایل دیتابیس بزرگتر میشود، صفحات بیشتری تولید می کند و پراکندگی داده ها بیشتر می شود. وقتی که فایل ها (ایندکس ها) بازسازی می شود، صفحات مرتبط به هم نزدیک می شوند، طوری که بیشتر از آن امکان همجواری وجود ندارد. به همین دلیل اگر بازسازی را چندین بار تکرار کنیم نتیجه بهتری حاصل نخواهد شد.
پاسخ سوال ۲: به نظر میرسه برای جواب به این سوال باید به سراغ شیوه اجرای کوئری ها در اس کیو ال سرور رفت. از اونجاییکه هر رکورد بیشتر از یک کیلوبایت فضا میگیره و قراره ۵۰۰۰۰۰ بار این رکورد درج ببشه، حجم فایل دیتابیس به سرعت رشد میکنه و چون ایندکس بر روی کلید اصلی صورت میگیره و کوئری بر اساس فیلد دیگری جستجو میشه، ضمن اینکه کوئری ها به صورت موازی در حال اجرا شدن هستند و نتیجه حاصله زمان زیادی از سی پی یو را مصرف می کند، احتمالا اس کیو ال سرور از استراتژی های دیگری برای جستجو استفاده می کند. به نظر میرسه در این حالت، اس کیو ال سرور از بافر یا Cache جواب را استخراج کرده باشد. یا شاید اتفاق دیگری رخ می دهد که من نمیدانم! (مثلا هنگام ثبت نظر با مرورگر اینترنت اکسپلورر پیغام “خطا: لطفا دیدگاهتان را بنویسید.” ظاهر می شود!!)
محمد آریان پور
پاسخ سوال ۱: هشت پیج اول در mixed extends قرار می گیرند و rebuild کردن روی آنها تاثیر ندارد.
مهدی حاجی میرزایی
سوال ۱)
فکر می کنم
چون فیلد RecordData ایندکس ندارد. وقتی که ایندکس را Rebuild فیلد RecordData فرگمنت نمی شود
یا یکی از دلایلش این است که فرگمنت به طول اندازه فایل که دیتابیس انجام می دهد و چون داده ما تغییری نکرده یا سایز فایل دیتابیس تغیر نکرده این درصد ثابت می ماند
سوال ۲)
چون که از دستور WITH(NOLOCK) استفاده کردید به این معنا وقتی که
رکوردی درحال پردازش یا خواندن باشد این رکورد را نمی بیند که این عمل
باعث میشه Query از رکوردهایی که lock هستند عبور کنه پس شاید همه رکوردها رو نبینین
و برای راه کار می تو به جای nolock از دستور WITH(READPAST) استفاده کرد
آرمان فلاح
پاسخ سوال ۱ : به خاطر کوچک بودن حجم ایندکس ، در واقع REBUILD کردن روی ایندکس های که Page_count کوچکتر از ۱۰۰۰ است کار اضافی است و تاثیری روی عملکرد دیتابیس ندارد
مسعود طاهری
ابوذر عسگری
پاسخ سوال ۱:
حمیدقلیپور
مسعود طاهری
سلام حمید جان
علی رحیمیان
سلام.
جواب ۱: عملیات Rebuild ایندکس ها را مرتب می کند تا فضایی page ها مرتب شود و فضای خالی کمتری اشغال کنند.
پس با یک بار Rebuild کردن ایندکس ها Fragmentation کاهش پیدا می کند و page ها ایندکس مرتب می شوند. حال با تکرار این دستور اثری روی Fragmentation نخواهد گذاشت چون پیج ها مرتب هستند.
جواب ۲: دقت داشته باشد ما از دستور WITH(NOLOCK) استفاده کرده ایم.
در این مساله عملیات درج پیوسته در حال انجام است. به طور همزمان چند عملیات select با WITH(NOLOCK) در یک حلقه در حال اجراست.
من این مسئله رو با این تغییر نیز تست کردم:
INSERT INTO Employees (EmployeeID,Salary) VALUES ( CAST(RAND() * 1000000 AS INT), 5)
بازهم جواب ۹۰ ویا ۱۱۰ می شود. یعنی مقادر ۱۰ یکی از رکورد های قدیمی ۱ کم یا یکی بیشتر خوانده می شود.
اگر قرار بود که یکی از رکورد ها جدید رو اشتباها می شد مقدار باید ۹۵ یا ۱۰۵ باشد.
در حالتی که مقدار ۹۰ می شود: احتمالا یکی از لیست های پیوندی پیج ها قدیمی که در حال بروز رسانی است گم شود.
ودر حالتی که مقدار ۱۱۰ می شود: به نظر میرسد که در زمان درج یک رکود حالتی وجود دارد که آدرس پیج رکورد جدید با یکی از پیج های رکوردی که قبلا ذخیره شده است برابری میکند و احتمالا سیستم اشتباها مقدار رکورد قدیمی رو دوباره میخواند.
مسعود طاهری
جناب رحیمیان عزیز
عباس لایقی
سلام و تشکر از سایت بسیار خوب شما
This is by-design.
For small tables, usually performance impact
on fragmentation is undectable. The first 8 page allocation would be
from mixed extents and mixed extents could be anywhere in database
files. Rebuilding indexes would not change this nature.
If you
have a small table, those mixed pages weight a lot during fragmentation
calculation; therefore, rebuilding index may not reduce fragmentation.
(As matter of fact, I could easily construct a case that fragmentation
increases after rebuild.) Those fragmentation would not be a pain for
your query performance; so basically you can ingore them.
When
page counts of an index reaches to certain big size (for example, 1000
pages), then fragmentation may start to impact performance. Rebuilding
index should reduce fragmentation.
Another thing to consider is
that how high the fragmentation is. If it is < 10%, it is hard for
rebuilding to reduce more (we never could 100% guarantee that you can
reach 0% fragmentation; with mixed page allocation, it is a hard goal to
achieve).
If you don’t care about space utilization, you can
use undocumented trace flag 1118 to disable mixed page allocation, but I
am not recommend it (this trace flag usually is used in tempdb for
reducing SGAM contention).
هادی جباری دارستانی
پاسخ سوال اول :
با توجه به اینکه شما فیلد RecordData رو nvarchar(8000) در نظر گرفتید
و با استفاده از دستور Replicate یک کلمه ی ۴ حرفی رو تکرار کردی حجم هر
رکورد میشه حدود ۷۲۰۰ بایت
و از اون طرف هر Page در SQL 8 کیلوبایت
هستش و هر رکورد بالا در یک Page قرار میگیرد این در صورتی است که هر رکورد
۹۰ درصد فضای یک پیج رو اشغال میکند به همین دلیل در زمان Rebuild کردن ایندکس
هیچ وقت نمیتواند فضای خالی را با رکورد دیگری پر کند و همیشه ایندکس پراکنده می
ماند.
پاسخ سوال دوم :
با توجه به اینکه یکی از کارهای اصلی ایندکس مرتب سازی
رکوردها میباشد در زمان درج رکورد جدید مرتب سازی رکورد ها در ایندکس همچنان پابرجاست
یعنی وقتی رکورد جدیدی درج میکنیم SQL این رکورد را در جای مناسب خود بین رکورد
های موجود در ایندکس قرار میدهد و در این زمان باعث میشود Page هایی که این
رکورد ها در آن قرار دارند لاک شوند
در مثال برای فیلد PK جدول نوع GUID در نظر گرفته
شده است و بنابر توضیحات بالا مرتب سازی ایندکس روی این فیلد انجام میگیرد
زمانی که ۵۰۰ هزار رکورد شروع به درج شدن میکنند با توجه به
اینکه GUID جدید ایجاد میشود ممکن است بین رکورد هایی که EmployeeID آنها برابر با
-۱ باشد درج شوند و باعث جابجایی رکوردها و Lock شدن Page ها شوند که
مورد باعث اختلال میشود
برای جلوگیری از این مشکل دو روش پیشنهاد میشود
۱-
تغییر در طراحی جدول و استفاده از PK با نوع INT و Auto
Identity
در این
روش هیچگاه مرتب سازی رکورد ها لازم نیست و در نتیجه لاک بودن و جابجایی رکوردها
را نداریم چون تمامی رکوردها بعد از ۱۰ رکوردی که EmployeeID آنها -۱ میباشد
درج میشوند
۲-
گذاشتن یک ایندکس روی جدول Employee بر روی فیلد
های EmployeeID , Salary و غیر فعال کردن Page Lock روی این ایندکس
مسعود طاهری
جناب جباری عزیز
tiyara9090@hotmail.com
سلام
مرسی از آموزش خوبتون استاد طاهری واقعا عالی بود
آموزش sql server 2016 کی شروع می کنید
مسعود طاهری
سلام
e.ak
پاسخ سوال ۱ به دلیل اینکه تغییرات dml در بانک اطلاعاتی رخ نداده مقدار fragmantaion تغییر نکرده و پس از هر بار اجرا همانمقدار قبلی را نشان نمیدهد
ساناز احمدی
سلام
عالی بود ولی کاش هرچهزود تر آموزش sql server2016 را شروع می کردید
زهرا کوچکیان
سلام باید حوابها از کجا وارد کنیم
مسعود طاهری
سلام
زهرا کوچکیان
جواب سوال اول
دلیل این اتفاق را من در کوچک بودن جدول میدانم همانطور که در نتیجه Fragmentation مشاهده میشود تعداد صفحات ۹ است .و معمولا تأثیر عملکرد در Fragmentation شدن undectable است . همچنین باتوجه به نوع شاخص در نظر گرفته شده نیز میزان Fragmentation را در دفعات بعد یکسان مشاهده میکنیم نیز میتوانست یکی از دلایل باشد البته بعد از اینکه تست انجام دادم چنان تفاوت چشم گیری ندیدم و شاخصهای دیگر نیز بعد از چند بار به تکرار میرسیدند. البته به وسیله دستور
WITH (ONLINE = ON)
بعد از REBUILD نیز کمی تفاوت وجود دارد اما باز هم به تکرار نتیجه میرسیم.
جواب سوال دوم
به نظر من علت این است که رکوردها در حال تکثیر زیادی هستند در زمان خیلی کم وبا استفاده از یک INDEX special_ix
روی employeed idفکر میکنم مشکل برطرف شود البته شاید استفاده از group by نیز موثر باشد
saeed zarei -سعید زارعی
سلام
پاسخ سوال ۲ : این مورد مربوط به Phantom Reads در مبحث مشکلات همزمانی میباشد و راه کار آن استفاده از بهینه ساز Serializable یا HoldLock در پرس و جو و یا قراردادن کدها در تراکنش به صورت زیر است :
set tran isolation levelSerializable
begin tran
مهران رحمتی
پاسخ سئوال اول = به خاطر DataType فیلد ان می باشد که اگر از نوع متناسبتر و کوچکتر استفاده شود مشکل یکپارچه سازی اندیکس حل میشود
saeed zarei -سعید زارعی
سلام
جواب سوال اول : از آنجایی که حجم هر پیج ۸KB است و حجم هر رکورد طبق سوال حدود ۷۲۰۸ بایت ، بنابراین در هر Page فقط یک رکورد ذخیره میشود و رکورد بعد در صفحه جدید ذخیره میشود .
با این تفاسیر حدود ۸۰۰ بایت از هر صفحه خالی میباشد که بنده این را پاسخ سوال یک میدانم . و راه حل استفاده از FileGroup میباشد . چون داده های مربوط به ستون RecordData حجم بالایی را دارند و میتوان آنها را جزو LOB در نظر گرفت .
جواب سوال دوم رو حدود ۶ یا ۷ ساعت قبل ارسال کردم . داشتم به سوال اول فکر میکردم . برای همین جواب ها رو باهم ارسال نکردم .
با تشکر از زحمات شما
هادی ناصحی
ابتدا سلام می کنم به اعضای محترم سایت نیک آموز
به شکل زیر دقت کنید:
مسعود طاهری
محمد
سلام
فرید طاهری
سلام
جواب دوستان را راس ساعت ۲۰ امشب منتشر خواهیم کرد.
مجتبی شهریور
سلام
ضمن تشکر مجدد استاد طاهری عزیز
دوستانی که تمایل دارن بیشتر در زمینه این شاهکار اطاعات کسب کنن یا حداقل یک پیش زمینه داشته باشن این مقاله خوبا ستاد طاهری را اول حتما مطالعه بفرمایند
مقاله :
حامد آتشبار
با سلام.
مسعود طاهری
حامد جان
حامد آتش بار
سلام. من جواب رو فرستادم پس چرا تو سایت قرار نگرفت.
هادی ناصحی
جناب طاهری لطف می کنید خودتون هم جواب رو بفرمایید تا مغایرتها رو بدونیم.
معصومه کارور
سلام. اگه ممکنه پاسخهای صحیح و اسم برنده ها رو اعلام بفرمایید
مسعود طاهری
سلام
حسین خوش رفتار منفرد
🙁
فریبرز دلیری
سلام
حسین آقا ی تماسی بگیر بابا
حکیمه حاتمی
باسلام و خسته نباشید ممنون از راهنمایتون.
جواد
سلام خسته نباشید
مسعود طاهری
سلام
جواد
بکاپ دارم ولی الان در دسترسم نیست
مسعود طاهری
سلام
مجید افتخاری
ممنون از پاسختون.
محسن اکبری
استاد عزیز ، فایل در زمان ٍExtract ، ارور میدهد .
آرزو محمدزاده
با سلام و عرض ادب
فایل بررسی و مشکلی نداشت لطفا نسخه نرم افزار فشرده ساز خود را به آخرین نسخه ارتقا دهید و سپس دوباره تست نمایید.