انجمن‌ها

سلام

تمام تغییراتی که در بندهای 1 تا 5 به آنها اشاره کردید کارهای صحیحی بوده‌اند. چون فرمودید «ما شرکت تولیدی هستیم و اکثر ماژول های نوسا رو داریم و تعداد یوزر هامون بالاست و دو شیفت شرکت کار میکند» قاعدتا داده‌های زیادی هم دارید و بهتر است از یک سرور مجازی (که رابطه آنها با USB بسیار کند است) استفاده نفرمایید + حتما از مدل Express برای SQL Server استفاده نفرمایید + به صورت دوره‌ای داده‌ها را حذف پراکندگی نمایید + از سخت‌افزار مناسبی استفاده نمایید.

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

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

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

امیدوارم توضیحات فوق مفید بوده باشند.

سلام،

با تشکر از آقای مؤمنی بابت توضیحات کامل و نکات ارائه شده، اگر لطف می‌کردید اسم مجموعه را هم اعلام می‌نمودید با توجه به تاریخچه خدمات با شناخت بهتری می‌توانستیم پاسخگو باشیم ولیکن به‌صورت کلی برخی موارد مانند عملیاتی کردن برگه‌های برگشت دوره جاری همراه با مرجع (که بسیاری از رخدادهای قبلی را تغییر می‌دهد) و یا نقل و انتقال و یا ورود داده از سایر سیستم‌ها به‌صورت غیر استاندارد به واسطه SQL می‌توانند مرجع مشکلات باشند.

 

در دو مورد که من با دوستان در سال 1400 بابت کندی برگه‌ها صحبت داشتم یک شرکت از ابزار غیر استاندارد برای ورود داده انبار به SQL استفاده می‌کرد که مشکلات عدیده در آن پایگاه قابل پیش‌بینی بود و شرکت دیگر از تعداد زیادی برگه برگشت دوره جاری استفاده می‌کرد و برای نمونه رخدادی را که در ماه 2 با قیمت x خارج شده بود را پس از 9 ماه و هزاران ورود خروج برگشت داده و سیستم را دچار نیاز به محاسبه تمامی رخدادهای میانی می‌کرد... در صورتی که کارمندان شرکت صرفاً یک رخداد با تعداد مشابه از آن کالا را برای برگشت استفاده می‌کردند که قیمت دستی نزنند و در واقع برگشت و مرجع عموماً یکسان نبودند و نیاز به این دقت در محاسبات در صورت استفاده از برگشت بدون مرجع و ورود بهای دستی الزامی نبود... 

همواره وجود سیستم سخت افزاری قوی (هارد سریع در اولویت اول، CPU و رم) در سرعت نرم افزار مفید است و سرور فیزیکی به مراتب برای مشتریان بزرگ بهتر از سرور مجازی بوده و در نیازمندی‌های نرم‌افزار همواره به عنوان پیش نیاز اعلام گردیده است. حذف پراکندگی نیز باید همواره در پایگاه‌های بزرگ حداقل هر چند روز یک‌بار انجام شود، ولیکن تمامی این توضیحات به این واقعیت که به دید کاربر عملیاتی کردن تعدادی برگه خاص (مانند برگه برگشت خروج با مرجع، نقل و انتقال و ...) در واقع شامل هزاران رخداد و برگه پشت صحنه بوده و تغییرات گسترده‌ای در سیستم ایجاد می‌کند که بنا به استانداردها و پیش نیاز انبار الزامی است تغییری ایجاد نمی‌کند...

اگر کاربر لیستی از هزاران سطر برگه را مشاهده می‌کرد و برای عملیاتی کردن چندین ثانیه یا دقیقه زمان لازم داشت، این زمان عادی بود، ولیکن به این دلیل که کاربر در انبار با ایجاد تغییر در چند برگه تغییرات گسترده‌ای در هزاران برگه دیگر می‌دهد و این تغییرات را مشاهده نمی‌کند فکر می‌کنیم که این زمان غیر عادی می‌باشد. برای محاسبه این برگه‌ها از آنجا که هر یک به رخداد قبلی وابسته است کار به‌صورت موازی قابل انجام نبوده و SQL جداول مربوطه را بسته تا جلوی تغییر و خطا را بگیرد و سپس تعداد زیادی مراحل را طی نموده که برخی از آنها شامل این موارد می‌باشد: بهترین راه انجام عملیات را تشخیص داده، کار را بر مبنای تعداد cpu ها و زمان پیش بینی شده شکسته، هر رخداد را از هارد خوانده، در رم cache کرده، محاسبه کرده (cpu)، و در هارد نوشته ... پایگاه برای این کار پیاده شده و هر چه سیستم قوی‌تر باشد این کار تندتر خواهد بود، ولیکن از آنجا که سروری با 2 دو برابر سرعت 10 برابر هزینه دارد، قوی کردن سرور تنها تا حدودی از دید اقتصادی منطقی بوده و برای همین در صورتی که سرور شما با نیازمندی‌های نوسا یکسان دیده شده تغییر خاصی پیشنهاد نمی‌گردد. البته که لطفاً از استفاده از سرور مجازی دوری بفرمایید. عموم شرکت‌های بزرگ استفاده کننده نوسا از رک فیزیکی منحصر برای نرم افزار استفاده می‌کنند، اگر هم به دلایل داخلی و یا اقتصادی ناچار به استفاده از سرور مجازی می‌باشید، حتماً از پیاده سازی نرم افزارهای سنگین دیگر به‌صورت مجازی در یک رک خودداری فرموده و از راهکار استاندارد و سخت افزاری USB over Network ارائه شده توسط نوسا مستقیماً پشت سرور (و نه usb over network نرم افزاری) استفاده فرمایید. 


با ارادت