Погана внутрішня база даних - замінити її або зафіксувати апаратне забезпечення на ній?

Отже - у нас є внутрішня база даних компанії, звичайні речі: керування клієнтами, телефонні дзвінки, угоди про продаж та клієнтські угоди / схеми.

Це фронт-клас Access 2000 і резервний модуль SQL Server 2000 Standard. Один сервер, подвійний Xeon 3,2 ГГц, 2 Гб оперативної пам’яті, Windows Server 2003, отримує близько 40% завантаження процесора протягом усього дня, поширюючись на 4 ядра, видимі для ОС (HT).

Базова база даних погано розроблена і органічно виростає протягом 10+ років, що підтримується менш кваліфікованими особами. Це погано нормалізується, і до деяких очевидних проблем відносяться таблиці з десятками тисяч рядків без первинного ключа або індексу, які також активно використовуються в об'єднанні з декількома таблицями для деяких найбільш часто використовуваних частин системи (наприклад, додаток менеджера викликів, який сидить на другому моніторі кожного 8 годин на день і виконує великий неефективний запит кожні кілька секунд).

Передня частина не набагато краща, це типовий безлад у сотнях форм, вкладених збережених запитів, погано написаному вбудованому SQL в код VBA, десятках "химерностей" і т. Д., І кожного разу, коли відбувається зміна, здається, що щось не пов'язане. Ми влаштувались на одному MDB, який працює «досить добре», і тепер ми проводимо політику без змін щодо цього, оскільки у нас немає доступу до важкої ваги (а також не плануємо наймати його).

Зараз компанія повільно зростає, збільшується кількість клієнтів, дзвінки тощо, а також незначне збільшення кількості одночасних користувачів, а продуктивність стає нещодавно помітно гіршою (чекаючи переходу між формами, очікування появи списків і т.д. )

Perfmon каже:

• Передача диска в секунду: від 0 до 30, в середньому 4.
• Поточна довжина черги диска: наближається до 1

Профілер SQL Server щохвилини бачить сотні тисяч запитів. Використання процесора у клієнтів майже дорівнює нулю, що свідчить про очікування виконання запитів на стороні сервера. Я перемістив це робоче навантаження через Радника з налаштування Двигуна DB, застосував свої пропозиції до тестової резервної копії, але це насправді не мало особливих змін.

До речі, у нас є суміш 100 Мб і гігабітних Ethernet, все в одній підмережі, 40 користувачів на двох поверхах.

До питання.

Як я бачу, у нас є два варіанти вирішити / покращити цю ситуацію.

• Ми можемо брати його в обмін і замінювати його абсолютно новою системою CRM, або замовляти, або частину замовника
• Ми можемо продовжити термін експлуатації цієї системи, встановивши на ній обладнання.

Ми можемо створити систему Intel i7 з шаленими показниками продуктивності на порядок менше витрат, ніж заміна програмного забезпечення.

Коли в кінцевому підсумку буде розроблена нова система, її можна розмістити на цьому вікні, тому немає витраченого обладнання. Нова система CRM постійно відкладається, вимикається та вимикається - я не бачу, щоб це відбувалося принаймні рік.

Будь-які думки щодо цієї ситуації, особливо якщо ви тут були самі, були б дуже вдячні.

Спасибі

Я збираюся не погодитися з усіма тут. Чак трохи обладнання. Це дешево, швидко, легко і придбає вам час, необхідний для впровадження правильного CRM-рішення. Причина, по якій я виступаю за те, що є анафемою для всіх, не тільки на цій дошці, але і стаціонарного потоку, - це те, що я був керівником проекту / менеджером і деякий час працював у бізнесі (бізнес) є в лапках через мою ненависть до цього слова). На основі Вашого опису програмного забезпечення знадобиться близько року, щоб відновити щось інше. Щойно виявлення / документування ділових правил / химерностей, можливо, займе 2 місяці. Це також буде неймовірно дорого розвивати. Особливо в порівнянні з вартістю хитромудрого сервера.

Я насправді збираюся розмістити набір веб-додатків для компанії саме з цієї причини. Внутрішній відділ ІТ не перемістить його до кращого обладнання, оскільки вони хочуть переробити їх на новій платформі. Ця вартість приблизно втричі більша, ніж коштувало б перенести її на нове обладнання. Не надто згадуючи, що компанія може не продовжувати контракт через рік.

Можливо, вам і не потрібно буде робити цього. Моя пропозиція - просто додати в таблицю деякі індекси / ключі.

таблиці з десятками тисяч рядків без первинного ключа або індексу, які також широко використовуються для приєднання кількох таблиць

Перш ніж витратити багато грошей або часу, знайдіть пару годин і додайте індекси (або первинні ключі, якщо зможете) до будь-яких таблиць, що беруть участь у цих приєднаннях ... особливо для стовпців, які використовуються в пункті де. Ви можете легко покращити продуктивність в 10 разів за кілька годин.

Відсутність дискового вводу / виводу означає, що запити подаються в основному з оперативної пам'яті. Якщо у вас "раптово" ваші гарячі столи більше не поміщаються в оперативній пам'яті, і сервер починає працювати з дисками, можливо, ви будете погано їздити. 2 Гб або ОЗУ не дуже багато в ці дні, але ще в епоху SQL2000 це було б значним. Я здогадуюсь, що кількість даних, якою програма зазвичай маніпулює, менша, ніж у вас є оперативна пам’ять. Можливо, ви хочете переглянути кількість "використаного" простору у файлах даних. Це дасть вам уявлення про те, скільки оперативної пам'яті може споживати база даних, в гіршому випадку. SQL Server не зберігає дані, які йому не потрібні в оперативній пам’яті, але важко дізнатися, які таблиці використовуються і коли.

Hyperthreading не завжди корисний для SQL Server. Ви можете покращити продуктивність, вимкнувши її. Це важко перевірити, оскільки для його відключення та увімкнення потрібна перезавантаження, і це великий клопот на виробничому сервері.

"Сотні тисяч запитів на хвилину" перекладаються на тисячі запитів на секунду. Це звучить досить зайнято, але більша частина цього трафіку може бути лише курсором з боку Access. Доступ особливо поганий при ефективному наборі наборів результатів з SQL. Ви можете отримати кращі показники, вимкнувши паралелізацію паралелізації SQL Server.

Ви також хочете шукати блокування. Закидання апаратних засобів при проблемі блокування не завжди призводить до значного вдосконалення. Якщо блокування не дуже багато, а запити задовольняють оперативна пам’ять, а не диск, ви в основному покладаєтесь на бурчання процесора та їх здатність перетягувати дані по каналах пам'яті. У цьому випадку швидше обладнання повинно забезпечити хороше вдосконалення. Якщо ви поспішаєте (щоб подолати цю проблему) і росте повільно, це може бути досить добре.

Як рішення, додавання апаратних засобів не має масштабів, а також покращення бази даних. Якщо у вас зростання темпів зростання, ви можете постаратися зіткнутися з новим обладнанням. Інша думка полягає в тому, що успішні програми притягують користувачів. Якщо додаток стане більш чуйним, користувачі можуть скористатися більшою кількістю звітів і таких, ніж вони, якщо їм потрібно піти на каву, очікуючи закінчення звіту.

Якщо схема бази даних дійсно погана, ви можете отримати певні виграші від продуктивності, просто переглянувши індексацію на таблицях. Концентруйтеся на таблицях, за якими ви знаєте, часто запитуєте. Ви можете використовувати Profiler для перегляду запитів, запущених проти сервера, просто скажіть йому, щоб шукати запити, які читають багато даних (наприклад, 100 000 сторінок), а потім працювати над запитами, які мало читають. Ви згадали, що в деяких таблицях немає ключів. Чи є в даних природні ключі, просто вони не виконуються обмеженнями або унікальними індексами?

Чи таблиці мають кластерні індекси? Відсутність кластерної індексації може спричинити всілякі вторинні ефекти.

Чи багато некластеризованих індексів з багатьма стовпцями? Це часто спроба побудувати багато покривних індексів, а не реалізувати більш ефективну стратегію індексації. SQL Server може ефективно будувати індекси, що охоплюють під час запиту, якщо це має сенс, і є підтримувані некластеризовані та кластеризовані індекси.

Нарешті, варто запитати: чи проводиться технічне обслуговування (повторне оновлення та / або оновлення статистики) на таблицях?

це ділове питання, а не технічне питання.

Як власник бізнесу: Наскільки стратегічна система для бізнесу? чим менш стратегічним, тим менше я дбаю і виправляю його та будь-які витрачені гроші - це гроші, які я міг би використовувати в іншому місці для розвитку свого бізнесу.

Комп'ютерні люди лякають мене, коли всі вони потрапляють у велику кімнату і сперечаються про дизайн і коштують мені цілого статку. Продовжуйте роботу системи! незалежно від того, чи означає це налаштування продуктивності (без реструктуризації) або кидання на неї більшої кількості обладнання, це лише пріоритет, якщо він перестане працювати.

Як ІТ-консультант: Ваша система застаріла і має приховані експлуатаційні витрати. Ми можемо розробити підходящу для вас систему, яка дозволить розширити масштаб і забезпечити платформу для майбутнього зростання та стратегічних переваг. Підпишіться тут, і всі ваші мрії збудуться.

Як ІТ-працівник: я можу бути супергероєм тут і врятувати компанію, запобігаючи неминучій катастрофі, оптимізуючи пекло цієї речі! мій менеджер буде обсипати мене подарунками та похвалами, оскільки я врятував тисячі компаній.

Я кажу: роби і те, і інше.

Ви вже сказали, що на 40% процесора ви сказали? Користувач ще скаржився (багато)? Якщо ні, у вас ще є кімната для дихання. Більше пам’яті може вистачити лише на деякий час.

Питання про шлях, чи є у вас розробники програмного забезпечення будинку? Якщо відповіді "НІ", навіть не намагайтеся повторити її. Ви опинитесь саме там, де зараз.

Якщо припустити, що у вас є будинкові розробники, чи мають ваші розробники будинків можливість правильно робити проект? Я кажу, що специфікація вийшла повністю, належним чином (релістично), тим самим, як якщо б це був проект замовника. Якщо ні, то не турбуйтеся, інакше воно опиниться там, де ви зараз.

Поки компанії не зрозуміють, що вони також є клієнтами, і їм не доведеться давати однакові ресурси для внутрішніх проектів, ви опинитесь там, де ви зараз знаходитесь. Був там, зробив це, отримав цілий комод футболок.

Тож якщо ви не можете зробити це належним чином, ви обираєте два варіанти - під ключ, який ви будете ненавидіти, тому що тепер вам доведеться відповідати формі системи, яку ви купуєте. Або це буде налаштовано, і вам доведеться витрачати час на ПРОЕКТ, налаштовуючи його.

АБО Рефактор, що у вас є. Пам’ятайте, що люди будуть сподіватися на все таку повну функціональність, коли прийде нова, тож чому будь-яким іншим способом потрібно робити все і відразу. Якщо ви перефактуруєте його, у вас є шанс розібратися, як він працює, а тоді, швидше за все, спеціальні зміни ви плануєте це в багатьох невеликих підпроектах.

Не бачачи системи, я, швидше за все, буду бачити, як нормалізувати, наскільки я можу в кінцевому підсумку, перемістити стільки SQL в збережені програми. Потім побудуйте новий передній кінець або з форм C #, або з веб-сторінки. Якщо ви зможете отримати свою бізнес-логіку та SQL з переднього кінця, пізніше це буде простіше зробити. Зберігаючи те, що ви робите для невеликих проектів, якщо його в будь-який час відштовхнуть убік або зупиняють, ви досягнете прогресу, який буде використаний.

Тут вже є кілька хороших відповідей - але чи можу я лише зазначити, що (якщо припустити, що у розробників будинків) порівняно невелика кількість роботи матиме великий вплив - додайте первинні ключі (вам навіть не доведеться змінювати всі запити на використовуйте їх), додайте індекси до полів, якими ви користуєтесь, і трохи налаштуйте свої запити, і ви зможете побачити абсолютно величезний приріст. Купіть собі трохи оперативної пам’яті для цього зараз, щоб придбати потрібний час і зал, щоб виправити це, а потім приступайте до роботи.

Що стосується "виправити чи відкопати", якщо функції системи в основному працюють для вас і роблять те, що потрібно, не переписуйте колесо. Якщо вашим користувачам доводиться робити гімнастику, щоб користуватися цією річчю, оскільки вона не відповідає вашим потребам, то немає сенсу докладати зусиль для цього.

Ну ... це вже деякий час тому, але я думав, що я зафіксую результат тут.

Врешті-решт, я переступив через рядок VBA, щоб вирішити ще одну проблему. Тоді я зрозумів, що деякі дзвінки щодо отримання наборів рядків блокуються протягом 20-30 + секунд.

Коли я перекопався до них, я виявив, що набір рядів заснований на запиті MS Access.

Це був вибір даних із іншого запиту доступу.

Це був вибір даних із іншого запиту доступу.

Все це виглядало так, ніби їх перетягли та опустили разом за допомогою конструктора запитів.

Я переглянув перші півдесятка больових точок користувача і виявив, що в обов'язковому порядку вони всі точно такі, як це.

Тому я повністю видалив степки ланцюгових запитів і замінив кожен з них одним запитом наскрізного проходження, який можна було б записати в T-SQL та виконати безпосередньо на сервері.

Поліпшення було абсолютно величезним у кожному випадку безвідмовно, і більше не було очікування запитів для когось.

А потім я покинув компанію. Не маю уявлення, чи все ще там є… але я цього не сумую.

Я розміщую окрему відповідь, а не просто додаю відповідь до Дейтона, тому що вартість перших кількох людей, які публікують відповідь, не враховується: вартість перепідготовки користувачів та вартість зміни ваших бізнес-процедур, щоб вони підходили до нова програмна програма. Інакше, що він сказав.

Однією з головних причин того, що компанії розробляють власне програмне забезпечення, є те, що вони мають бізнес-процедури, які не відповідають тому, що є на ринку. Що чудово - індивідуальні бізнес-процедури компанії - це значна частина цінності, яку компанія вносить на стіл, і ТАКЕ є конкурентна перевага, яку має компанія над рештою ринку. Для заміни програмного забезпечення чимось загальним потрібно буде перекваліфікувати своїх людей і пожертвувати конкурентною перевагою, або вам доведеться налаштувати рішення відповідно до своїх бізнес-процесів. Обидва вони дорогі та трудомісткі. Як бізнес-консультант, так і як системдмін, я бачив, як ці витрати самі по собі вбивають малі компанії.

З ваших заяв, схоже, ви майже пов'язані з процесором / програмним забезпеченням. Я б зробив дві речі - додав індекси (в межах), особливо до стовпців, які наразі їх не використовують. І я хотів би зробити найшвидший набір процесорів, на який ти можеш, тому що, схоже, саме там ти зобов'язуєшся, якщо у тебе немає такого читання дисків на найвищому рівні.

(Крім того, я би оновив серверну версію, наскільки це можливо - до моменту, коли ви встановите це, Access 2000 і SQL Server 2000 виповниться десять років. Це СТАРО в комп'ютерні роки!)

Для цього потрібна тотальна реструктуризація (реструктуризація). Перебудуйте систему з нуля. Це значно заощадить у довгостроковій перспективі (накладні витрати на обслуговування). Поки що, патронник обладнання. Я думаю, що це питання є скоріше "справою бізнесу", ніж технічним запитом. У технічному відношенні відповідь відверта: "патронник більше сили". Бізнес-розумний, Створіть нову систему!

Технічна відповідь:

У вас є кількість пропозицій із зазначенням первинних ключів, а індексацію слід ретельно переглянути. Для доступу також дуже подобається використання стовпця TimeStamp SQL Server, який називається RowVersion, у кожній таблиці, оскільки це скорочує багато часу, який Access витрачає на рішення про те, чи було змінено запис, коли справа стосується оновлення записів.

Відповідь бізнесу:

Нове CRM-рішення - це багато роботи в навчанні людей, і ви ніколи не опинитесь на системі, яка точно відповідає вашим бізнес-вимогам.

Я знайду хорошого доступу до людини, який також дуже добре обізнаний у SQL Server, і змусить їх витратити 3 або 6 місяців на нормалізацію таблиць та виправлення больових точок користувача. Переконайтеся, що людина працює на поверхах, як ваші користувачі, хоча у тихому просторі та є доступною. Хоча не надто доступний. Розробники не люблять перерв. S

Виходячи з наведеної інформації, я би замінив систему. Переважно з іншим CRM, який дозволяє гнучку інтеграцію з іншими системами (що може компрометувати ваш ERP IS ).

Найскладнішою частиною буде переконання керівництва та користувачів у необхідності оновлення.

Управління

Висловіть свою стурбованість технічними проблемами, низькою продуктивністю, побоюванням візантійських збоїв тощо. Тоді представіть 2 альтернативних CRM. Поговоріть про інтеграцію бізнесу, загальну стратегію ERP для бізнесу, а головне, як це зробить працівників більш продуктивними та прибутковими. Використовуйте тематичні дослідження. Робіть це не довше 15 хвилин (якщо вони не хочуть більше інформації). Тоді вам потрібно переконати користувачів.

Користувачі

Плани навчання (які постачальник може надавати [та керівництву потрібно буде схвалити]), постійне спілкування з топ-20% ваших користувачів (енергетичні користувачі, ті, що спричиняють проблеми), і тверде зобов'язання підтримувати систему на 100% в роботі за перший місяць (перший місяць зробить або порушить будь-яку нову ІС).

Є багато продуктів CRM, виберіть той, який найкраще відповідає вашим потребам бізнесу.

Накидання апаратних засобів на це лише заохочує більш поганий дизайн та управління, поки система не буде настільки жалюгідною, що не працюватиме навіть на найновішому та найкращому обладнанні. Пора переглянути кращу реалізацію. Спочатку проаналізуйте, що потрібно. Тільки коли ви повністю зрозумієте вимоги, ви можете почати шукати найкращий спосіб їх виконання. Після того, як ви впевнені, що розумієте вимоги, починайте переглядати, чи краще / економічно вигідніше змінювати те, що у вас є, або починати з нуля, можливо, з чогось зовсім іншого.

Зрештою, вам, мабуть, найкраще буде переробляти базу даних. Якщо кинути на нього більше обладнання, це вирішить проблему на деякий час, але якщо ви продовжуєте користуватися нею, вам доведеться через деякий час кинути на неї більше обладнання.

Зазвичай, коли виникають проблеми з продуктивністю, ви дивитесь на такі речі, як вузькі місця вводу / виводу на жорстких дисках / RAID, загострювання бази даних тощо ..., але для таких речей, як загострення, вам потрібна належна розробка бази даних, щоб скористатися нею. Із звуків цього додатку ніколи не вдасться масштабувати.

У довгостроковій перспективі повторне оновлення бази даних та програмного забезпечення на передньому кінці для кращого відображення ваших поточних потреб бізнесу послужать вам краще в довгостроковій перспективі. Ваші користувачі будуть вам вдячні, ваше обладнання триватиме довше, і це дозволить заощадити набагато більше грошей у довгостроковій перспективі, ніж викидання обладнання для вирішення проблем.

З огляду на ваш опис, створення абсолютно нової замовленої системи є безглуздим - ви закінчитесь там, де ви почали, або, можливо, ще гірше, ніж зараз. Тож, якщо ви не зможете переконати когось придбати сторонні рішення, найкраще ставити рефактор, як можна, і кидати на це обладнання.

Я б сказав, що вам слід зробити дві речі: 1) Аналіз продуктивності на SQL-сервері. Ви, схоже, визначили серверну сторону як джерело лагів, тому тепер вам потрібно знати, які запити відстають і чому. Ймовірно, ви можете знайти кілька запитів гарячих точок, щоб оптимізувати, що дасть вам великі переваги. Чорт, якщо у вас є клієнти, які оновлюються кожні кілька секунд, подивіться, чи можете ви знизити їх швидкість оновлення (Чи дійсно список на екрані потрібно оновлювати кожні 5 секунд? Чи буде 30 ОК? Якщо ні, як щодо 15? ). Дурні речі, такі як збільшення таймерів оновлення, можуть заощадити накладні витрати, якщо ви зможете втекти від цього.

2) Киньте на це більше обладнання. ОСОБЛИВО кидати на нього величезні кількості барана. Вам потрібно стільки пам’яті, що база даних повністю вписується в оперативну пам’ять. Слідкуйте за версіями вашої ОС та програмного забезпечення ( мабуть, існує досить багато правил щодо версій Windows та того, яке обладнання вони насправді підтримують). Якщо ви можете переконати себе, що більше ядер допоможе, тоді киньте стільки процесорів і ядер, скільки ви зможете отримати на ньому також.

Ви згадали оперативну пам’ять та процесори, але не диски. Я визнаю, що минуло майже десятиліття, як я мав справу з SQL сервером MS, але він пов'язаний з дисками так само, як і будь-яка інша база даних, якщо вона не може вмістити все в пам'яті.

Я, мабуть, спершу спробую заповнити машину якомога більше оперативної пам’яті - тоді я би переконався, що журнали записуються на диски, які не використовуються для таблиць чи індексів. Тоді я б спробував переконатися, що жодна таблиця не має своїх індексів на одному шпинделі.

Після цього я б переймався налаштуванням рівня баз даних, але з цим вам потрібно буде визначити свої тести та оптимізаційну мету, щоб ви не порушували речі та не робили запити гіршими. Хоча ви сказали, що первинні ключі не виявляли великої переваги у вашій базі тестів, ви повинні переглянути свою методологію тестування - первинні ключі можуть дозволити деяким базам даних (не впевнений, що MS SQL є одним із них) використовувати блокування запису рівня , а не блокування рівня таблиці, що може зменшити суперечки, які можуть бути не показані при тестуванні лише з кількома користувачами.

По-перше, я погоджуюся з Кайлом Ходжсоном і додаю ПК. Це дешево (лише час), і ви можете побачити збільшення ваших запитів. А як щодо індексів стовпців приєднання у ваших 10 найпотворніших запитів? Де скануються таблиці?

По-друге, що з обрізанням даних у базі даних? Чи повертається більше рядків у запитах, ніж насправді потрібно? Я також згоден із пропозицією Кайла про оперативну пам’ять (ще два ГБ).

Помістіть усе це у своєму записі (Джозеф Керн) на те, що ви пропонуєте тимчасово, будучи накреслення майбутнього. Запитайте у керівництва та користувачів, що станеться з організацією, якщо поточний додаток CRM кратерує та недоступний. Можливо, це допоможе змусити їх задуматися про майбутнє.

Отримайте обладнання!

На сьогоднішній день олово є дуже дешевим, якщо ви перейдете на чіп серії Xeon 55xx, він буде кричати за все, що ви можете на нього кинути.

Це просто ризик / винагорода - ви можете витратити гроші та багато часу на покращення бази даних або придбати свій шлях швидше та дешевше.

Подумайте про переключення перемикача пам'яті 3 ГБ і додавання ще 2 ГБ пам'яті.