Słaba wewnętrzna baza danych - wymienić ją lub zamontować na niej sprzęt?

Tak więc - mamy wewnętrzną bazę danych firmy, zwykłe rzeczy: zarządza klientami, rozmowami telefonicznymi, umowami sprzedaży i umowami / programami dla klientów.

Jest to interfejs programu Access 2000 i zaplecze programu SQL Server 2000 Standard. Pojedynczy serwer, podwójny Xeon 3.2GHz, 2GB RAM, Windows Server 2003, dostaje około 40% obciążenia procesora przez cały dzień, rozłożony na 4 rdzenie widoczne dla systemu operacyjnego (HT).

Baza danych zaplecza jest źle zaprojektowana i rozwijała się organicznie przez ponad 10 lat, prowadzona przez osoby o niskich kwalifikacjach. Jest źle znormalizowany, a niektóre z oczywistych problemów obejmują tabele z dziesiątkami tysięcy wierszy bez klucza podstawowego lub indeksu, które są również intensywnie używane w połączeniach wielostolikowych dla niektórych najczęściej używanych części systemu (np. aplikacja menedżera połączeń, która siedzi na drugim monitorze każdego człowieka przez 8 godzin dziennie i uruchamia duże, nieefektywne zapytanie co kilka sekund).

Interfejs nie jest dużo lepszy, jest to typowy bałagan setek formularzy, zagnieżdżone zapisane zapytania, źle napisane osadzone SQL w kodzie VBA, dziesiątki „dziwactw” itp., A przy każdej zmianie wydaje się, że coś niezwiązanego znika. Zdecydowaliśmy się na jeden MDB, który działa „wystarczająco dobrze”, a teraz mamy politykę bez zmian, ponieważ nie mamy wewnętrznych ciężarów Access (i nie planujemy też ich zatrudnić).

Firma powoli się rozwija, rośnie liczba klientów, połączeń itp., A także niewielki wzrost liczby równoczesnych użytkowników, a wydajność wyraźnie się ostatnio pogorszyła (oczekiwanie na przejście między formularzami, oczekiwanie na wypełnienie list itp.) )

Perfmon mówi:

• Transfer dysków na sekundę: od 0 do 30, średnio 4.
• Aktualna długość kolejki dyskowej: unosi się wokół 1

Profiler programu SQL Server widzi setki tysięcy zapytań co minutę. Zużycie procesora przez klientów jest prawie zerowe, co oznacza, że ​​oczekuje na wykonanie zapytań po stronie serwera. Obciążyłem to zadanie Doradcą dostrajania silnika DB, zastosowałem jego sugestie do testowej kopii zapasowej, ale tak naprawdę nie miało to większego znaczenia.

Nawiasem mówiąc, mamy połączenie 100 MB i Gigabit Ethernet, wszystkie w jednej podsieci, 40 użytkowników na dwóch piętrach.

Do pytania.

Widzę, że mamy dwie możliwości rozwiązania / poprawy tej sytuacji.

• Możemy go złomować i zastąpić całkowicie nowym systemem CRM, na zamówienie lub częściowo na zamówienie
• Możemy przedłużyć żywotność tego systemu, mocując do niego sprzęt.

Możemy zbudować system Intel i7 z szalonymi liczbami wydajności za rząd wielkości mniejszy koszt niż wymiana oprogramowania.

Kiedy w końcu opracowywany jest nowy system, można go hostować na tym urządzeniu, więc nie ma zmarnowanego sprzętu. Nowy system CRM ciągle się odkłada, odsuwa i odsuwa - nie widzę tego przez co najmniej rok.

Wszelkie przemyślenia na temat tej sytuacji, szczególnie jeśli sam tu byłeś, byłyby bardzo mile widziane.

Dzięki

Nie zgadzam się ze wszystkimi tutaj. Chuck trochę sprzętu. Jest tani, szybki, łatwy i da ci czas potrzebny na wdrożenie odpowiedniego rozwiązania CRM. Powodem, dla którego opowiadam się za czymś, co jest przekleństwem dla prawie wszystkich osób nie tylko na tym forum, ale także w przepełnieniu stosu, jest to, że byłem kierownikiem / kierownikiem projektu i od pewnego czasu jestem po stronie „Biznesu” (biznes jest w cytatach z powodu mojej nienawiści do tego słowa). Na podstawie opisu oprogramowania odbudowanie czegoś innego zajmie prawie rok. Samo odkrywanie / dokumentowanie reguł / dziwactw biznesowych zajmie prawdopodobnie 2 miesiące. Opracowanie będzie również niewiarygodnie drogie. Zwłaszcza w porównaniu z kosztem wyłudzonego serwera.

Właśnie z tego powodu zamierzam udostępnić zestaw aplikacji internetowych dla firmy. Wewnętrzny dział IT nie przeniesie go na lepszy sprzęt, ponieważ chce go przebudować na nowej platformie. Koszt ten jest około trzykrotnie większy niż przeniesienie go na nowy sprzęt. Nie wspominając już o tym, że firma może nie odnowić umowy za rok.

Być może nie musisz tego robić. Moja sugestia to po prostu dodać do tabeli kilka indeksów / kluczy.

tabele z dziesiątkami tysięcy wierszy bez klucza podstawowego lub indeksu, które są również często używane w połączeniach z wieloma tabelami

Zanim wydasz dużo pieniędzy lub czasu, poświęć kilka godzin i dodaj indeksy (lub klucze podstawowe, jeśli możesz) do dowolnych tabel zaangażowanych w te sprzężenia ... szczególnie dla kolumn używanych w klauzuli where. Możesz łatwo poprawić wydajność dziesięciokrotnie w ciągu zaledwie kilku godzin.

Brak dyskowych operacji we / wy oznacza, że ​​zapytania są dostarczane głównie z pamięci RAM. Jeśli „nagle” Twoje gorące tabele nie mieszczą się już w pamięci RAM, a serwer zacznie pracować z dyskami, być może czeka Cię kiepska jazda. 2 GB lub RAM nie jest obecnie zbyt wiele, ale w erze SQL2000 byłoby to znaczne. Zgaduję, że ilość danych, którymi normalnie manipuluje aplikacja, jest mniejsza niż ilość pamięci RAM, którą masz. Warto sprawdzić ilość „zużytego” miejsca w plikach danych. To daje wyobrażenie o tym, ile pamięci RAM może zużyć baza danych, w najgorszym przypadku. SQL Server nie przechowuje danych, których nie potrzebuje w pamięci RAM, ale może być trudno ustalić, jakie tabele są używane i kiedy.

Hyperthreading nie zawsze pomaga w SQL Server. Możesz uzyskać lepszą wydajność, wyłączając go. Trudno go przetestować, ponieważ wyłączenie go i włączenie wymaga ponownego uruchomienia, a to jest duży problem na serwerze produkcyjnym.

„Setki tysięcy zapytań na minutę” przekłada się na tysiące zapytań na sekundę. Brzmi to dość zajęte, ale znaczna część tego ruchu może być tylko pobierana kursorem przez Access. Dostęp jest szczególnie zły w efektywnym pobieraniu zestawów wyników z SQL. Możesz uzyskać lepszą wydajność, wyłączając ustawienie równoległości programu SQL Server.

Chcesz także poszukać blokowania. Rzucanie sprzętem na problem z blokowaniem nie zawsze przynosi oczekiwaną dramatyczną poprawę. Jeśli nie ma zbyt wiele blokowania i zapytania są zaspokajane przez pamięć RAM, a nie dysk, w zasadzie polegasz na pomrukowaniu procesora i jego zdolności do ciągnięcia danych przez kanały pamięci. W takim przypadku szybszy sprzęt powinien zapewnić dobrą poprawę. Jeśli się spieszysz (aby obejść ten problem) i powoli się rozwijasz, może to być wystarczające.

Jako rozwiązanie, dodawanie sprzętu nie jest skalowane, podobnie jak ulepszenia bazy danych. Jeśli dojdzie do gwałtownego wzrostu, nowy sprzęt może mieć problemy. Inną myślą jest to, że skuteczne aplikacje przyciągają użytkowników. Jeśli aplikacja stanie się bardziej responsywna, użytkownicy mogą częściej uruchamiać na niej więcej raportów, niż gdyby musieli pójść na kawę, czekając na zakończenie raportu.

Jeśli schemat bazy danych jest naprawdę zły, możesz być w stanie uzyskać pewne wygrane wydajności, po prostu patrząc na indeksowanie w tabelach. Skoncentruj się na stołach, o których wiesz, że często się o nie pytasz. Możesz użyć Profilera do oglądania zapytań działających na serwerze, po prostu powiedz mu, aby szukał zapytań odczytujących wiele danych (np. 100 000 stron), a następnie pracował w kierunku zapytań, które nie czytają dużo. Wspomniałeś, że niektóre tabele nie mają kluczy. Czy w danych są naturalne klucze, które nie są wymuszane przez ograniczenia lub unikalne indeksy?

Czy tabele mają indeksy klastrowe? Brak indeksowania klastrowego może powodować różnego rodzaju efekty wtórne.

Czy istnieje wiele indeksów nieklastrowanych z wieloma kolumnami? Jest to często próba zbudowania wielu indeksów obejmujących zamiast wdrażania bardziej efektywnej strategii indeksowania. SQL Server może efektywnie budować indeksy obejmujące w locie podczas zapytania, jeśli ma to sens i istnieje obsługa indeksów nieklastrowanych i klastrowanych.

Na koniec warto zapytać: czy konserwacja (reindeksowanie i / lub aktualizacja statystyk) jest wykonywana na tabelach?

to pytanie biznesowe, a nie techniczne.

Jako właściciel firmy: jak strategiczny jest system dla firmy? im mniej strategiczne, tym mniej dbam o to i naprawiam to, a wszelkie wydane pieniądze to pieniądze, które mógłbym wykorzystać gdzie indziej na rozwój mojej firmy.

Informatycy straszą mnie, gdy wszyscy wchodzą do dużego pokoju i kłócą się o projekt i kosztują fortunę. Kontynuuj działanie systemu! bez względu na to, czy oznacza to dostrajanie wydajności (bez ponownej architektury) lub rzucanie w to więcej sprzętu, priorytetem jest przestanie działać.

Jako konsultant IT: Twój system jest starszą wersją i ma ukryte koszty operacyjne. Możemy zaprojektować system odpowiedni dla Ciebie, który skaluje się i zapewnia platformę dla przyszłego wzrostu i przewagi strategicznej. Zarejestruj się tutaj, a wszystkie twoje marzenia się spełnią.

Jako pracownik działu IT: mogę być tutaj superbohaterem i uratować firmę, zapobiegając nieuchronnej katastrofie, optymalizując piekło! mój kierownik obsypie mnie prezentami i pochwałami, ponieważ zaoszczędzę tysiące firm.

Mówię rób oba.

W tej chwili masz około 40% procesora, który powiedziałeś? Czy już narzekasz (często) na użytkownika? Jeśli nie, nadal masz oddech. Więcej pamięci może wystarczyć na chwilę.

Pytanie o drogę, czy masz własnych programistów? Jeśli odpowiedź brzmi NIE, nie próbuj nawet jej powtarzać. Skończysz dokładnie tam, gdzie teraz jesteś.

Zakładając, że masz programistów wewnętrznych, czy programiści mają możliwość prawidłowego wykonania projektu? Mówię o pełnej, właściwie (relistycznej) osi czasu, zasadniczo takiej samej, jakby to był projekt klienta. Jeśli nie, to nie zawracaj sobie głowy, bo skończy się tam, gdzie jesteś teraz.

Dopóki firmy się nie zorientują, że same są klientami i będą musiały zapewnić te same środki wewnętrznym projektom, skończysz dokładnie tam, gdzie teraz jesteś. Byłem tam, zrobiłem to, mam całą komodę z koszulkami.

Więc jeśli nie możesz tego zrobić poprawnie, masz dwa wyjścia z pudełka, których pracownicy będą nienawidzić, ponieważ teraz musisz dopasować się do formy zakupionego systemu. Lub będzie można go dostosować i nadal będziesz musiał poświęcić PROJEKT czas na dostosowanie go.

LUB Refaktoryzuj to, co masz. Pamiętaj, że ludzie będą oczekiwać takiej samej pełnej funkcjonalności, kiedy pojawi się nowa, dlatego właśnie w inny sposób musisz zrobić wszystko naraz. Jeśli ponownie to rozważysz, masz szansę dowiedzieć się, jak to działa, a następnie zamiast zmian ad hoc planujesz to w wielu małych podprojektach.

Nie widząc systemu, prawdopodobnie zorientowałbym się w kwestii normalizacji tak dużo, jak to możliwe w back-endie, przeniesienia jak największej ilości SQL do przechowywanych proc. Następnie zbuduj nowy interfejs z formularzy C # lub aplikacji internetowej. Jeśli możesz uzyskać logikę biznesową i SQL z interfejsu, łatwiej będzie później to zrobić ponownie. Zachowując to, co robisz dla małych projektów, jeśli zostanie ono odepchnięte na bok w dowolnym momencie lub zatrzymane, osiągniesz postęp, który zostanie wykorzystany.

Kilka dobrych odpowiedzi już tutaj - ale mogę tylko wskazać, że (zakładając, że są deweloperzy wewnętrzni) stosunkowo niewielka ilość pracy będzie miała duży wpływ - dodaj klucze podstawowe (nie powinieneś nawet zmieniać wszystkich swoich zapytań na użyj ich), dodaj indeksy do pól, których używasz, i dostosuj trochę swoje zapytania, a zobaczysz absolutnie ogromny wzrost. Kup sobie teraz trochę pamięci RAM, aby kupić czas i rezerwę, aby to naprawić, a następnie zabrać się do pracy.

Jeśli chodzi o „napraw to lub porzuć”, jeśli funkcje systemu w zasadzie działają dla Ciebie i robią to, czego potrzebujesz, nie przepisuj koła. Jeśli użytkownicy muszą ćwiczyć gimnastykę, aby użyć tej rzeczy, ponieważ nie pasuje ona do twoich potrzeb, nie ma sensu wkładać w to wysiłku.

Cóż ... to już dawno temu, ale pomyślałem, że zapisam tutaj wynik.

W końcu przeszedłem przez linię VBA, aby rozwiązać inny problem. Wtedy zdałem sobie sprawę, że niektóre połączenia w celu pobrania zestawów wierszy blokowały przez 20-30 + sekund.

Kiedy kopałem w nich, okazało się, że zestaw wierszy był oparty na zapytaniu MS Access.

To było wybieranie danych z innego zapytania Access.

To było wybieranie danych z jeszcze jednego zapytania Access.

Wszystkie wyglądały, jakby zostały przeciągnięte i upuszczone razem za pomocą projektanta zapytań.

Przejrzałem górne pół tuzina punktów bólu użytkownika i odkryłem, że bez wątpienia wszystkie były dokładnie takie same.

Więc całkowicie usunąłem stosy zapytań łańcuchowych i zastąpiłem każde z nich pojedynczym zapytaniem tranzytowym, które można zapisać w T-SQL i wykonać bezpośrednio na serwerze.

Poprawa była absolutnie ogromna w każdym przypadku bezbłędnie i nie trzeba było więcej czekać na zapytania dla nikogo.

A potem opuściłem firmę. Nie mam pojęcia, czy nadal tam jest ... ale nie tęsknię.

Zamieszczam osobną odpowiedź zamiast dołączać się do odpowiedzi Daytona, ponieważ jest kilka kosztów, które nie są brane pod uwagę przez pierwszych kilka osób, które opublikują odpowiedź: Koszt przekwalifikowania użytkowników i koszt zmiany procedur biznesowych w celu dopasowania nowy program. W przeciwnym razie to, co powiedział.

Jednym z głównych powodów, dla których firmy opracowują własne oprogramowanie, jest to, że mają procedury biznesowe, które nie pasują do czegoś, co jest na rynku. Co jest świetne - indywidualne procedury biznesowe firmy stanowią znaczną część wartości, którą firma przynosi na stół, i są przewagą konkurencyjną, jaką firma ma nad resztą swojego rynku. Zastąpienie oprogramowania czymś ogólnym wymagałoby przekwalifikowania pracowników i poświęcenia przewagi konkurencyjnej, w przeciwnym razie konieczne byłoby dostosowanie rozwiązania do własnych procesów biznesowych. Oba są drogie i czasochłonne. Jako konsultant biznesowy, a także sysadmin, widziałem, że koszty te same zabijają małe firmy.

Z twoich wypowiedzi wynika, że ​​jesteś w dużej mierze związany procesorem / oprogramowaniem. Zrobiłbym dwie rzeczy - dodać indeksy (w ramach limitów), szczególnie do kolumn, które ich obecnie nie używają. I rzuciłbym najszybszy zestaw procesorów, jaki możesz na nim, ponieważ wygląda na to, że właśnie tam jesteś związany, jeśli nie masz tak wielu odczytów dysków poza szczytem.

(Poza tym zaktualizowałbym wydanie serwera w miarę możliwości - zanim to zrobisz, Access 2000 i SQL Server 2000 będą miały dziesięć lat. To jest STARE za lat komputerowych!)

Wymaga to całkowitej przebudowy (przebudowy). Odbuduj system od podstaw. Pozwoli to znacznie zaoszczędzić na dłuższą metę (koszty ogólne utrzymania). Tymczasem wrzuć do tego sprzęt. Myślę, że to pytanie jest bardziej „uzasadnieniem biznesowym” niż zapytaniem technicznym. Z technicznego punktu widzenia odpowiedź brzmi: „wrzuć na to więcej mocy”. Z biznesowego punktu widzenia zbuduj nowy system!

Odpowiedź techniczna:

Masz wiele sugestii stwierdzających, że klucze podstawowe i indeksowanie powinny być dokładnie sprawdzone. Access bardzo lubi też używanie SQL Server TimeStamp, czyli kolumny RowVersion w każdej tabeli, ponieważ skraca to wiele czasu, który Access spędza na decydowaniu, czy rekord został zmieniony, jeśli chodzi o aktualizację rekordów.

Odpowiedź biznesowa:

Nowe rozwiązanie CRM to dużo pracy w szkoleniu ludzi i nigdy nie skończysz z systemem, który dokładnie odpowiada Twoim wymaganiom biznesowym.

Znalazłem dobrą osobę z Access, która jest również bardzo dobrze zaznajomiona z SQL Server i zmusiłbym ją do spędzenia 3 lub 6 miesięcy na normalizowaniu tabel i ustalaniu punktów bólu użytkownika. Upewnij się, że osoba pracuje na podłogach saem jako twoi użytkownicy, chociaż w cichym miejscu i jest dostępna. Chociaż nie jest zbyt dostępny. Programiści nie lubią przerw. S.

Na podstawie podanych informacji zastąpiłbym system. Najlepiej z innym CRM, który umożliwia elastyczną integrację z innymi systemami (co zagroziłoby twojej ERP IS ).

Najtrudniejsze będzie przekonanie kierownictwa i użytkowników do konieczności aktualizacji.

Zarządzanie

Wyraź swoje obawy dotyczące problemów technicznych, niskiej wydajności, strachu przed awariami bizantyjskimi itp. Następnie zaprezentuj 2 alternatywne CRM. Porozmawiaj o integracji biznesowej, ogólnej strategii ERP dla biznesu, a co najważniejsze, w jaki sposób zwiększy to wydajność i rentowność pracowników. Skorzystaj ze studiów przypadków. Zrób to nie dłużej niż 15 minut (chyba że chcą więcej informacji). Następnie musisz przekonać użytkowników.

Użytkownicy

Plany szkoleniowe (które może dostarczyć sprzedawca [i zarząd musiałby zatwierdzić]), kontynuacja komunikacji z 20% twoich głównych użytkowników (zaawansowanych użytkowników, powodujących problemy) oraz solidne zaangażowanie w utrzymanie 100% sprawności systemu przez pierwszy miesiąc (pierwszy miesiąc spowoduje powstanie lub złamanie dowolnego nowego IS).

Istnieje wiele produktów CRM, wybierz taki, który najlepiej odpowiada Twoim potrzebom biznesowym.

Rzucanie w to sprzętem tylko zachęca do złego projektowania i zarządzania, dopóki system nie będzie tak żałosny, że nie będzie działał dobrze nawet na najnowszym i najlepszym sprzęcie. Czas spojrzeć na lepszą implementację. Najpierw przeanalizuj, co jest wymagane. Tylko wtedy, gdy w pełni rozumiesz wymagania, możesz zacząć szukać najlepszego sposobu ich wdrożenia. Gdy masz pewność, że rozumiesz wymagania, zacznij sprawdzać, czy lepiej / bardziej opłacalnie jest modyfikować to, co masz, lub zaczynać od zera, być może z czymś zupełnie innym.

Na dłuższą metę prawdopodobnie najlepiej byłoby przerobić bazę danych. Rzucanie w to większym sprzętem rozwiąże problem na jakiś czas, ale jeśli będziesz go nadal używać, po pewnym czasie będziesz musiał rzucić na niego więcej sprzętu.

Zazwyczaj, gdy występują problemy z wydajnością, patrzysz na takie wąskie gardła we / wy na dyskach twardych / RAID, dzielenie bazy danych itp., Ale dla takich operacji, jak dzielenie, potrzebujesz odpowiedniej bazy danych, aby z niej skorzystać. Z tego, że twoja aplikacja nigdy nie będzie mogła skalować.

Na dłuższą metę ponowne wykonanie bazy danych i oprogramowania front-end w celu lepszego odzwierciedlenia bieżących potrzeb biznesowych będzie lepiej służyć na dłuższą metę. Twoi użytkownicy będą Ci wdzięczni, twój sprzęt będzie trwał dłużej i na dłuższą metę pozwoli zaoszczędzić znacznie więcej pieniędzy niż rzucanie ogromnego sprzętu na ten problem.

Biorąc pod uwagę twój opis, stworzenie zupełnie nowego systemu na zamówienie jest bezcelowe - skończysz tam, gdzie zacząłeś, a może nawet gorzej niż teraz. Więc jeśli nie uda ci się przekonać kogoś do zakupu rozwiązania innej firmy, najlepiej postawić na refaktoryzację najlepiej jak potrafisz i rzucić w to sprzętem.

Powiedziałbym, że powinieneś zrobić dwie rzeczy: 1) Analiza wydajności na serwerze SQL. Wygląda na to, że zidentyfikowałeś stronę serwera jako źródło opóźnień, więc teraz musisz wiedzieć, które zapytania są opóźnione i dlaczego. Najprawdopodobniej znajdziesz kilka zapytań, które by zoptymalizować, i które przyniosą Ci duże korzyści. Heck, jeśli masz klientów aktualizujących się co kilka sekund, sprawdź, czy możesz zmniejszyć ich częstotliwość aktualizacji (czy lista na ekranie NAPRAWDĘ musi aktualizować się co 5 sekund? Czy 30 będzie w porządku? Jeśli nie, to co powiesz na 15? ). Głupie rzeczy, takie jak zwiększanie czasu odświeżania, mogą zaoszczędzić sporo kosztów ogólnych, jeśli uda ci się to zrobić.

2) Dodaj do tego więcej sprzętu. W SZCZEGÓLNOŚCI rzuć w nią ogromnymi ilościami taranów. Chcesz tyle pamięci, że baza danych mieści się całkowicie w pamięci RAM. Miej oko na swoje wersje systemu operacyjnego i oprogramowania ( najwyraźniej istnieje wiele reguł dotyczących wersji systemu Windows i obsługiwanego sprzętu). Jeśli możesz się przekonać, że więcej rdzeni pomogłoby, to rzuć tyle procesorów i rdzeni, ile możesz na to dostać.

Wspomniałeś o pamięci RAM i procesorach, ale nie o dyskach. Przyznaję, że minęło prawie dziesięć lat, odkąd zajmowałem się SQL Server MS, ale jest związany z dyskami tak samo jak każda inna baza danych, jeśli nie zmieści wszystkiego w pamięci.

Najprawdopodobniej najpierw spróbuję zapełnić maszynę tak dużą ilością pamięci RAM, jaką to zajmie - następnie upewnię się, że dzienniki są zapisywane na dyskach, które nie są używane w tabelach lub indeksach. Chciałbym wtedy upewnić się, że żadne tabele nie mają swoich indeksów na tym samym wrzecionie.

Potem martwię się o dostrajanie na poziomie bazy danych, ale przy tym będziesz musiał zdefiniować swoje testy i cel optymalizacji, aby nie zepsuć rzeczy ani nie pogorszyć zapytań. Chociaż powiedziałeś, że klucze podstawowe nie wykazują dużej przewagi w testowej bazie danych, powinieneś przyjrzeć się swojej metodologii testowania - klucze podstawowe mogą pozwolić niektórym bazom danych (nie jestem pewien, czy MS SQL jest jednym z nich) stosowanie blokowania na poziomie rekordów , zamiast blokad na poziomie tabeli, co może zmniejszyć rywalizację, która może nie zostać pokazana w testach z kilkoma użytkownikami.

Po pierwsze, zgadzam się z Kyle'm Hodgsonem i dodaję PK. Jest tani (tylko czas) i możesz zauważyć zwiększenie liczby zapytań. A co z indeksami kolumn łączących w 10 najbardziej brzydkich zapytaniach? Gdzie są skany tabeli?

Po drugie, co z przycinaniem danych w bazie danych? Czy w zapytaniach zwracanych jest więcej wierszy niż jest to naprawdę potrzebne? Zgadzam się również z sugestią Kyle'a dotyczącą pamięci RAM (jeszcze dwa GB).

Umieść to wszystko w swoim piśmie (Joseph Kern) na temat tego, co proponujesz w międzyczasie, planując przyszłość. Zapytaj kierownictwo i użytkowników, co stanie się z organizacją, jeśli obecna aplikacja CRM krateruje i nie jest dostępna. Być może to pomoże im myśleć o przyszłości.

Zdobądź sprzęt!

Cyna jest nie tylko bardzo tania w tej chwili, jeśli wybierzesz układ z serii Xeon 55xx, będzie krzyczeć o wszystko, co możesz na nią rzucić.

To tylko ryzyko / nagroda - możesz wydawać pieniądze i dużo czasu na ulepszanie DB lub kupować tam szybciej i taniej.

Rozważ przesunięcie przełącznika pamięci 3 GB i dodanie kolejnych 2 GB pamięci.