Плохая внутренняя база данных - замените ее или зафиксируйте оборудование?

Итак - у нас есть внутренняя база данных компании, обычные вещи: управление клиентами, телефонные звонки, сделки купли-продажи и клиентские соглашения / схемы.

Это клиентская часть Access 2000 и серверная часть SQL Server 2000 Standard. Одиночный сервер, двойной Xeon 3,2 ГГц, 2 ГБ ОЗУ, Windows Server 2003, получает около 40% загрузки ЦП в течение всего дня, распределяясь по 4 ядрам, видимым для ОС (HT).

Внутренняя база данных плохо спроектирована и за 10 с лишним лет органически выросла, обслуживается менее квалифицированными специалистами. Он плохо нормализован, и некоторые из очевидных проблем включают таблицы с десятками тысяч строк без первичного ключа или индекса, которые также интенсивно используются в соединениях с несколькими таблицами для некоторых наиболее интенсивно используемых частей системы (например, приложение менеджера вызовов, которое сидит на втором мониторе каждого в течение 8 часов в день и выполняет большой неэффективный запрос каждые несколько секунд).

Внешний интерфейс не намного лучше, это типичная путаница из сотен форм, вложенных сохраненных запросов, плохо написанного встроенного SQL-кода в коде VBA, десятков «причуд» и т. Д., И всякий раз, когда вносятся изменения, что-то не связанное, кажется, ломается. Мы остановились на одном MDB, который работает «достаточно хорошо», и теперь у нас есть политика без изменений, поскольку у нас нет собственных тяжеловесов Access (и нет планов по их найму).

В настоящее время компания медленно растет, растет число клиентов, звонков и т. Д., А также незначительное увеличение числа одновременных пользователей, и производительность в последнее время заметно ухудшается (ожидание перехода между формами, ожидание заполнения списков и т. Д.). )

Perfmon говорит:

• Передачи дисков в секунду: от 0 до 30, в среднем 4.
• Текущая длина очереди диска: колеблется около 1

Профилировщик SQL Server видит сотни тысяч запросов каждую минуту. Загрузка ЦП на клиентах практически равна нулю, что указывает на ожидание выполнения запросов на стороне сервера. Я перенес эту рабочую нагрузку с помощью помощника по настройке ядра БД, применил ее рекомендации к тестовой резервной копии, но на самом деле это не имело большого значения.

Кстати, у нас есть соединение 100 МБ и гигабитного Ethernet, все в одной подсети, 40 пользователей в двух этажах.

На вопрос.

На мой взгляд, у нас есть два варианта решения / улучшения этой ситуации.

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

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

Когда новая система в конечном итоге разрабатывается, она может быть размещена на этом блоке, так что нет ненужного оборудования. Новая CRM система продолжает откладываться, выключаться и выключаться - я не вижу, чтобы это происходило, по крайней мере, в течение года.

Любые мысли по поводу этой ситуации, особенно если вы были здесь сами, будут очень признательны.

Благодарность

Я собираюсь не согласиться со всеми здесь. Брось немного оборудования на это. Это дешево, быстро, просто и поможет вам сэкономить время, необходимое для внедрения правильного решения CRM. Причина, по которой я защищаю что-то, что является анафемой для всех, не только на этой доске, но и в стеке, заключается в том, что я был менеджером проекта / менеджером и некоторое время занимался бизнесом (бизнес в кавычках из-за моей ненависти к слову). Исходя из вашего описания программного обеспечения, потребуется около года, чтобы восстановить что-то еще. Простое обнаружение / документирование бизнес-правил / причуд, вероятно, займет 2 месяца. Это также будет невероятно дорого в разработке. Особенно по сравнению со стоимостью сервера с обманом.

Я на самом деле собираюсь разместить набор веб-приложений для компании именно по этой причине. Внутренний ИТ-отдел не будет переводить его на более качественное оборудование, потому что он хочет перестроить их на новую платформу. Эта стоимость примерно в три раза больше, чем стоило бы перевести ее на новое оборудование. Не стоит также упоминать, что компания может не продлевать контракт через год.

Вам может и не понадобиться. Я предлагаю просто добавить несколько индексов / ключей в таблицу.

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

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

Отсутствие дискового ввода-вывода означает, что запросы поступают в основном из ОЗУ. Если у вас «внезапно» перестали работать оперативные таблицы в ОЗУ, и сервер начинает работать с дисками, возможно, вас ждет плохая поездка. 2 ГБ или ОЗУ не так уж много в наши дни, но в эпоху SQL2000 их было бы достаточно. Я предполагаю, что объем данных, которыми приложение обычно манипулирует, меньше, чем у вас есть оперативная память. Возможно, вы захотите посмотреть на количество «используемого» пространства в файлах данных. Это даст вам представление о том, сколько ОЗУ может потреблять база данных в худшем случае. SQL Server не хранит данные, которые ему не нужны, в оперативной памяти, но может быть трудно узнать, какие таблицы используются и когда.

Гиперпоточность не всегда полезна для SQL Server. Вы можете получить лучшую производительность, отключив его. Это трудно проверить, потому что выключение и включение требует перезагрузки, и это является большой проблемой на рабочем сервере.

«Сотни тысяч запросов в минуту» - это тысячи запросов в секунду. Это звучит довольно занято, но большая часть этого трафика может быть просто выборкой курсора Access. Доступ особенно плох при эффективном извлечении наборов результатов из SQL. Вы можете повысить производительность, отключив параметр распараллеливания SQL Server.

Вы также хотите искать блокировку. Метание оборудования в проблему блокировки не всегда приводит к ожидаемому значительному улучшению. Если блокирования невелики и запросы удовлетворяются ОЗУ, а не диском, вы в основном полагаетесь на недовольство процессора и его способность передавать данные по каналам памяти. В этом случае более быстрое оборудование должно обеспечить хорошее улучшение. Если вы спешите (чтобы обойти эту проблему) и медленно растете, этого может быть достаточно.

Как решение, добавление аппаратного обеспечения не масштабируется так же как улучшения базы данных. Если вы заметите скачок роста, вы можете столкнуться с трудностями в работе вашего нового оборудования. Другая мысль заключается в том, что успешные приложения привлекают пользователей. Если приложение становится более отзывчивым, пользователи могут с большей вероятностью запускать на нем больше отчетов и тому подобного, чем если бы им пришлось пойти на кофе, ожидая завершения отчета.

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

У таблиц есть кластерные индексы? Отсутствие кластерной индексации может вызвать всевозможные побочные эффекты.

Много ли некластеризованных индексов с множеством столбцов? Часто это попытка создать множество покрывающих индексов, а не реализацию более эффективной стратегии индексации. SQL Server может эффективно создавать закрывающие индексы на лету во время запроса, если это имеет смысл, если есть поддержка некластеризованных и кластеризованных индексов.

Наконец, стоит спросить: проводится ли обслуживание (переиндексация и / или обновление статистики) таблиц?

это деловой вопрос, а не технический вопрос.

Как владелец бизнеса: насколько стратегически важна система для бизнеса? чем менее стратегическим, тем меньше я забочусь о его исправлении и потраченных деньгах, это деньги, которые я мог бы использовать в другом месте для развития своего бизнеса.

Компьютерные люди пугают меня, так как все они попадают в большую комнату, спорят о дизайне и стоят мне целое состояние. Поддерживай систему! означает ли это настройку производительности (без ре-архитектуры) или использование большего количества оборудования, это только приоритет, если он перестает работать.

Как ИТ-консультант: Ваша система является устаревшей и имеет скрытые операционные расходы. Мы можем разработать систему, которая подходит именно вам, которая будет масштабироваться и предоставлять платформу для будущего роста и стратегических преимуществ. Зарегистрируйтесь здесь и все ваши мечты сбудутся.

Как ИТ-сотрудник: я могу быть здесь супергероем и спасти компанию, предотвратив надвигающуюся катастрофу, оптимизировав эту чертову штуку! Мой менеджер засыпает меня подарками и похвалой, потому что я спас компанию тысячам.

Я говорю, делай оба.

Прямо сейчас ваш на 40% или около того процессор вы сказали? Вы уже много жалуетесь? Если нет, у вас все еще есть передышка. Больше памяти может быть достаточно, чтобы сделать это на некоторое время.

Вопрос для пути, есть ли у вас в доме разработчиков программного обеспечения? Если ответов НЕТ, то даже не пытайтесь повторить его. Вы окажетесь именно там, где вы сейчас находитесь.

Предполагая, что у вас есть собственные разработчики, есть ли у ваших внутренних разработчиков возможность правильно выполнить проект? Я говорю о том, что спецификации полностью, должным образом (с полным рельефом), в основном, так же, как если бы это был проект клиента. Если нет, то не беспокойтесь, иначе все вернется туда, где вы сейчас находитесь.

До тех пор, пока компании не изменят свою версию и не станут клиентами сами по себе и не будут нуждаться в одинаковых ресурсах для внутренних проектов, вы окажетесь именно там, где находитесь сейчас. Был там, сделал это, получил целый комод футболок.

Так что, если вы не можете сделать это должным образом, у вас есть два варианта «из коробки под ключ», которые ваши сотрудники будут ненавидеть, потому что теперь они должны соответствовать форме системы, которую вы покупаете. Или он будет настраиваемым, и вам все равно придется потратить время ПРОЕКТА на его настройку.

ИЛИ Рефакторинг того, что у вас есть. Помните, что люди ожидают все той же полной функциональности, когда придет новый, поэтому любым другим способом вы должны делать все сразу. Если вы рефакторируете это, у вас есть шанс выяснить, как это работает, а затем, а не разовые изменения, вы планируете это во множество небольших подпроектов.

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

Здесь уже есть несколько хороших ответов, но, может быть, я просто укажу, что (при условии, что есть собственные разработчики), сравнительно небольшой объем работы окажет большое влияние - добавьте первичные ключи (вам даже не нужно менять все ваши запросы на используйте их), добавьте индексы к тем полям, которые вы используете, и немного настройте свои запросы, и вы увидите, что они значительно выросли. Купите себе немного оперативной памяти для этого сейчас, чтобы выиграть время и запас, который вам нужно исправить, а затем приступить к работе.

Что касается вопроса «исправьте это или откажитесь от него», если функции системы в основном работают для вас и делают то, что вам нужно, не переписывайте колесо. Если ваши пользователи вынуждены делать гимнастику, чтобы использовать вещь, потому что она не соответствует вашим потребностям, тогда нет смысла прилагать усилия к ней.

Ну ... это было давно, но я решил записать результат здесь.

В конце я шаг за шагом прошел по VBA, чтобы справиться с другой проблемой. Именно тогда я понял, что некоторые вызовы для получения наборов строк блокировались на 20-30 + секунд.

Когда я копался в них, я обнаружил, что набор строк основан на запросе MS Access.

Это был выбор данных из другого запроса доступа.

Это был выбор данных из еще одного запроса доступа.

Все это выглядело так, как будто их перетащили вместе с помощью конструктора запросов.

Я прошел через полдюжины болевых точек пользователя и обнаружил, что все они точно такие же.

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

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

И тогда я покинул компанию. Понятия не имею, все еще там ... но я не скучаю по нему.

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

Одна из основных причин, по которой компании разрабатывают собственное программное обеспечение, заключается в том, что у них есть бизнес-процедуры, которые не соответствуют тому, что есть на рынке. Что замечательно - отдельные бизнес-процедуры компании составляют значительную часть ценности, которую компания приносит на стол, и являются конкурентным преимуществом, которое компания имеет перед остальным рынком. Чтобы заменить программное обеспечение чем-то универсальным, вам потребуется переобучить своих сотрудников и пожертвовать конкурентным преимуществом, либо вам придется настроить решение в соответствии с вашими бизнес-процессами. Оба дорогие и трудоемкие. Как бизнес-консультант и системный администратор, я видел, как эти расходы сами по себе убивают небольшие компании.

Судя по вашим заявлениям, вы в значительной степени связаны с процессором / программным обеспечением. Я хотел бы сделать две вещи - добавить индексы (в определенных пределах), особенно в столбцы, которые в настоящее время их не используют. И я бы выбрал для этого самый быстрый набор процессоров, потому что он выглядит так, как будто вы привязываетесь, если у вас не так много операций чтения с диска, за исключением пика.

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

Это требует полной реструктуризации (ре-архитектуры). Восстановите систему с нуля. Это сэкономит вам много в долгосрочной перспективе (накладные расходы на техническое обслуживание). А пока посмотри на это. Я думаю, что этот вопрос - скорее «бизнес-кейс», чем технический запрос. С технической точки зрения, ответ на этот вопрос - «больше сил в этом». Бизнес-бизнес, построить новую систему!

Технический ответ:

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

Деловой ответ:

Новое CRM-решение - это большая работа для обучающихся, и у вас никогда не будет системы, которая точно соответствует вашим бизнес-требованиям.

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

На основании предоставленной информации я бы заменил систему. Предпочтительно с другой CRM, которая позволяет гибкую интеграцию с другими системами (что может поставить под угрозу вашу ERP IS ).

Самое сложное - убедить руководство и пользователей в необходимости обновления.

управление

Выразите озабоченность по поводу технических проблем, низкой производительности, боязни византийских сбоев и т. Д. Затем представьте 2 альтернативных CRM. Поговорите об интеграции бизнеса, общей стратегии ERP для бизнеса и, самое главное, как это сделает сотрудников более продуктивными и прибыльными. Используйте тематические исследования. Сделайте это не более 15 минут (если они не хотят больше информации). Затем вам нужно убедить пользователей.

пользователей

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

Существует множество продуктов CRM, выберите тот, который наилучшим образом соответствует потребностям вашего бизнеса.

Вбрасывание аппаратного обеспечения в него только поощряет более плохой дизайн и управление, пока система не станет настолько жалкой, что не будет работать хорошо даже на самом последнем и лучшем оборудовании. Пришло время взглянуть на лучшую реализацию. Сначала проанализируйте, что требуется. Только когда вы полностью понимаете требования, вы можете начать искать лучший способ их реализации. Как только вы убедитесь, что понимаете требования, начинайте задумываться о том, лучше ли / экономичнее ли изменить то, что у вас есть, или начать с нуля, возможно, с чего-то совершенно другого.

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

Обычно, когда есть проблемы с производительностью, вы смотрите на такие вещи, как узкие места ввода / вывода на жестких дисках / RAID, разбиение базы данных и т.д. Судя по всему, ваше приложение никогда не сможет масштабироваться.

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

Учитывая ваше описание, создание совершенно новой системы на заказ бессмысленно - вы окажетесь там, где начали, или, может быть, даже хуже, чем сейчас. Поэтому, если вы не можете убедить кого-либо купить стороннее решение, вам лучше всего сделать рефакторинг как можно лучше и бросить в него аппаратное обеспечение.

Я бы сказал, что вы должны сделать две вещи: 1) Анализ производительности на сервере SQL. Похоже, вы определили серверную часть как источник лагов, поэтому теперь вам нужно знать, какие запросы отстают и почему. По всей вероятности, вы можете найти некоторые горячие точки для оптимизации, которые дадут вам большие преимущества. Черт возьми, если у вас есть клиенты, которые обновляются каждые несколько секунд, посмотрите, можете ли вы уменьшить их частоту обновления (Нужно ли обновлять список на экране ДЕЙСТВИТЕЛЬНО каждые 5 секунд? 30 будет в порядке? Если нет, то как насчет 15? ). Тупые вещи, такие как увеличение таймеров обновления, могут сэкономить много накладных расходов, если вам это сойдет с рук.

2) Брось больше оборудования на это. ОСОБЕННО бросайте в него огромное количество барана. Вы хотите так много памяти, что база данных полностью помещается в оперативной памяти. Следите за версиями вашей ОС и программного обеспечения ( очевидно, существует довольно много правил для версий Windows и того, какое оборудование они на самом деле поддерживают). Если вы можете убедить себя в том, что поможет больше ядер, то выбросьте столько процессоров и ядер, сколько сможете.

Вы упомянули ОЗУ и процессоры, но не диски. Я признаю, что прошло почти десять лет с тех пор, как я имел дело с SQL Server MS, но он привязан к дискам так же, как и к любой другой базе данных, если он не может вместить все в памяти.

Я, вероятно, сначала попытался бы заполнить машину как можно большим объемом оперативной памяти, а затем удостовериться, что журналы записываются на диски, которые не используются для таблиц или индексов. Затем я попытался бы убедиться, что ни у одной таблицы нет индексов на одном и том же шпинделе.

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

Во-первых, я согласен с Кайлом Ходжсоном и добавляю PK. Это дешево (только время), и вы можете увидеть повышение ваших запросов. Как насчет индексов в столбцах соединения в ваших 10 самых уродливых запросах? Где сканы таблицы?

Во-вторых, как насчет обрезки данных в базе данных? В запросах возвращается больше строк, чем действительно нужно? Я также согласен с предложением Кайла ОЗУ (еще два ГБ).

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

Получить оборудование!

Олово не только очень дешево в данный момент, если вы выберете чип серии Xeon 55xx, он будет кричать обо всем, что вы можете на него бросить.

Это просто риск / вознаграждение - вы можете тратить деньги и много времени на улучшение БД или покупать свой путь быстрее и дешевле.

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