Zayıf iç veritabanı - değiştirilsin mi ya da donanımını değiştirirsin?

Yani - bir şirket içi veri tabanımız var, olağan şeyler: müşterileri yönetir, telefon görüşmeleri, satış anlaşmaları ve müşteri anlaşmaları / planları

Bir Access 2000 ön ucu ve bir SQL Server 2000 Standard arka ucu. Tek sunucu, çift Xeon 3.2 GHz, 2 GB RAM, Windows Server 2003, işletim sistemi tarafından görülebilen 4 çekirdeğe yayılmış, tüm gün yaklaşık% 40 CPU yükü alır.

Arka uç veritabanı, zayıf tasarlanmış ve kalifiye olmayan kişilerce korunan, 10 yıldan uzun bir süredir organik olarak büyümüştür. Kötü bir şekilde normalleşmiştir ve bariz sorunların bazıları, sistemin en çok kullanılan bölümlerinden bazıları için çok masalı birleştirmelerde yoğun olarak kullanılan, birincil anahtar veya indeks içermeyen, on binlerce satır içeren tabloları içerir (örneğin, Günde 8 saat boyunca herkesin ikinci monitöründe oturan ve birkaç saniyede bir büyük verimsiz sorgu yapan çağrı yöneticisi uygulaması).

Ön uç çok daha iyi değil, yüzlerce formun, iç içe geçmiş kaydedilmiş sorguların, VBA kodunda kötü yazılmış gömülü SQL, düzinelerce "tuhaflıklar" vb. Ve bir değişiklik yapıldığında ilgisiz bir şeyler kırıldığı görülüyor. “Yeterince iyi” çalışan bir MDB'ye karar verdik ve şu anda şirket içi erişim ağırlıkları olmadığından (ya da birini işe alma planlarımız olmadığından) üzerinde hiçbir değişiklik politikası yok.

Şirket şimdi yavaş yavaş büyüyor, artan müşteri sayısı, çağrı vb. Eşzamanlı kullanıcı sayısındaki mütevazı artış ve performans son zamanlarda gözle görülür şekilde daha da kötüye gidiyor (formlar arasında hareket etmeyi bekliyor, listelerin doldurulmasını bekliyor vb. )

Perfmon diyor ki:

• Saniyedeki disk transferleri: 0 ile 30 arasında, ortalama 4.
• Geçerli disk sırası uzunluğu: 1 civarında

SQL Server'ın profilcisi her dakika yüz binlerce sorgu görür. İstemcilerdeki CPU kullanımı hemen hemen sıfırdır ve bu, sunucu tarafında sorguların yürütülmesini beklediğini gösterir. Bu iş yükünü DB Engine Tuning Advisor'a koydum, önerilerini bir test yedeğine uyguladım, ancak bu gerçekten pek farketmedi.

Bu arada, hepsi bir alt ağda, iki katında 40 ish kullanıcısı olan 100 MB ve gigabit ethernet karışımına sahibiz.

Soruya.

Gördüğüm gibi, bu durumu çözmek / iyileştirmek için iki seçeneğimiz var.

• Ismarlayabilir veya ısmarlama veya tamamen ısmarlama işlemi ile tamamen yeni bir CRM sistemiyle değiştirebiliriz
• Üzerindeki donanımı sıkıştırarak bu sistemin ömrünü uzatabiliriz.

Yazılımı değiştirmekten daha az maliyetle çılgın performans numaraları olan bir Intel i7 sistemi kurabiliriz.

Sonunda yeni bir sistem geliştirildiğinde, bu kutuda barındırılabilir, dolayısıyla boşa harcanan donanım yoktur. Yeni bir CRM sistemi kalkmaya, kalkmaya ve kapanmaya devam ediyor - Bunun en az bir yıl boyunca gerçekleştiğini görmüyorum.

Bu duruma ilişkin herhangi bir düşünce, özellikle de burada kendiniz olduysanız, çok memnun kalacaksınız.

Teşekkürler

Buradaki herkesle aynı fikirde olmayacağım. Üzerine biraz donanım sıkın. Ucuz, hızlı, kolay ve size uygun bir CRM çözümü uygulamak için gereken zamanı satın alacak. Bunun nedeni, sadece bu panodaki değil, aynı zamanda stackoverflow'taki herkes için anatema olan bir şeyi savunmamın nedeni, bir proje yöneticisi / yöneticisi olduğum ve bir süredir "İş" tarafında olduğum (iş). kelimesine duyduğum nefretten dolayı alıntı yapıyor Yazılım açıklamanıza dayanarak, başka bir şeyin yeniden inşa edilmesi bir yıla yakın bir zaman alacaktır. İş kurallarını / tuhaflıklarını keşfetmek / belgelemek sadece 2 ay sürecektir. Ayrıca geliştirilmesi inanılmaz derecede pahalı olacaktır. Özellikle kandırılmış bir sunucunun maliyeti ile karşılaştırıldığında.

Aslında bu sebepten dolayı bir şirket için bir dizi web uygulaması sunmak üzereyim. Dahili IT departmanı daha iyi bir donanıma taşınmayacak çünkü onları yeni bir platformda yeniden geliştirmek istiyorlar. Bu maliyet, yeni bir donanıma taşınmasının maliyetinin yaklaşık üç katıdır. Çok fazla söz değil, şirketin bir yıl içinde sözleşmesi yenilenmemiş olabilir.

Ya da yapmanız gerekmeyebilir. Önerim, tabloya bazı indeksler / anahtarlar eklemektir.

Çok masalı bağlantılarda da yoğun olarak kullanılan, birincil anahtar veya indeks içermeyen, on binlerce satırdan oluşan tablolar

Çok fazla para veya zaman harcamadan önce, birkaç saat ayırın ve bu birleşimlerde yer alan tablolara, özellikle de bir maddede kullanılan sütunlar için indeksler (veya yapabilirseniz birincil anahtarlar) ekleyin. Performansı birkaç saat içinde 10 kat artırarak kolayca artırabilirsiniz.

Disk G / Ç eksikliği, sorguların çoğunlukla RAM'den beslendiğini gösterir. Eğer 'aniden' çalışma masalarınız artık RAM'e sığmıyorsa ve sunucu diskleri çalıştırmaya başlarsa, kötü bir sürüş için olabilirsiniz. 2GB veya RAM bugünlerde pek fazla değil, ancak SQL2000 döneminde çok büyük olurdu. Uygulamanın normal olarak yönettiği veri miktarının sahip olduğunuz RAM'den daha küçük olduğunu tahmin ediyorum. Veri dosyalarındaki "kullanılmış" alanın miktarına bakmak isteyebilirsiniz. Bu, veritabanının ne kadar RAM tüketebileceği konusunda bir fikir verecektir, en kötü durumda. SQL Server, RAM'de ihtiyaç duymadığı verileri tutmaz, ancak hangi tabloların ne zaman kullanıldığını bilmek zor olabilir.

Hyperthreading, SQL Server ile her zaman yardımcı olmaz. Kapatarak daha iyi performans elde edebilirsiniz. Sınamak zor, çünkü açıp kapatmak, yeniden başlatma gerektiriyor ve bu bir üretim sunucusunda büyük bir zorluk.

"Dakikada yüz binlerce sorgu", saniyede binlerce soruya karşılık gelir. Kulağa oldukça meşgul geliyor, ancak bu trafiğin çoğu Access tarafından imleç getirebilir. Access, SQL'den sonuç kümelerini verimli bir şekilde almakta özellikle kötü. SQL Server paralelleştirme ayarını kapatarak daha iyi performans elde edebilirsiniz.

Ayrıca engellemeyi aramak da istersiniz. Donanımı engelleme sorununa atmak her zaman ümit edilen dramatik gelişmeyi sağlamaz. Çok fazla engelleme yoksa ve sorgulamalar disk yerine RAM tarafından karşılanırsa, temel olarak işlemcinin tutucusuna ve bunların bellek kanalları arasında veri çekme yeteneğine güveniyorsunuzdur. Bu durumda, daha hızlı donanım iyi bir gelişme sağlamalıdır. Acele ediyorsanız (bu konuyu aşmak için) ve yavaş büyüyorsanız, bu yeterince iyi olabilir.

Çözüm olarak, donanım eklemek, veritabanı geliştirmelerinin yanı sıra ölçeklendirilmez. Büyümede bir dalgalanma olursa, yeni donanımınızı zorlukla bulabilirsiniz. Diğer bir düşünce, başarılı uygulamaların kullanıcıları çekmesidir. Uygulama daha yanıt verirse, kullanıcıların raporun bitmesini beklerken kahveye gitmeleri gerektiğinden daha fazla rapor çalıştırma olasılığı daha yüksek olabilir.

Eğer veritabanı şeması gerçekten kötüyse, tablolardaki indekslemeye bakarak performans elde etmeyi başarabilirsiniz. Sıklıkla sorgulandığını bildiğiniz masalara yoğunlaşın. Sunucuya karşı çalışan sorguları izlemek için Profiler'ı kullanabilir, yalnızca çok fazla veri okuyan sorguları aramasını söyleyin (100.000 sayfa gibi) ve daha sonra çok fazla okumayan sorgulara çalışın. Bazı tabloların anahtarlarının olmadığını söylemiştin. Verilerde kısıtlamalar veya benzersiz dizinler tarafından zorlanmayan doğal anahtarlar var mı?

Tablolarda kümelenmiş dizinler var mı? Kümelenmiş indekslemenin olmaması her türlü ikincil etkiye neden olabilir.

Çok sayıda sütun içeren, kümelenmemiş çok sayıda dizin var mı? Bu genellikle daha etkili bir indeksleme stratejisi uygulamak yerine, pek çok kapsayan endeks oluşturma çabasıdır. SQL Server, bir sorgu sırasında etkin ve hızlı bir şekilde kümelenmiş dizinleri destekliyorsa, bir sorgu sırasında anında kapsayan dizinleri oluşturabilir.

Son olarak, sormaya değer: Tablolarda bakım (reindexing ve / veya güncelleme istatistikleri) yapılıyor mu?

bu bir ticari soru değil, teknik bir soru.

Bir işletme sahibi olarak: Sistem işletme için ne kadar stratejik? ne kadar az stratejik olursa o kadar az önemsiyorum, düzeltiyorum ve harcanan para da işimi büyütmek için başka yerlerde kullanabileceğim para.

Bilgisayar halkı, hepsi büyük bir odaya girip, tasarım hakkında tartışıp bir servete mal olduğu için beni korkutuyor. Sistemi devam ettirin! bunun performans ayarı (yeniden mimarlık yapmadan) veya ona daha fazla donanım atmak anlamına gelip gelmediği, sadece çalışmayı durdurması bir önceliktir.

Bir BT danışmanı olarak: Sisteminiz eski ve gizli işletme maliyetleri var. Sizin için doğru olan, gelecekteki büyüme ve stratejik avantaj için ölçeklendirme ve platform sağlayacak bir sistem tasarlayabiliriz. Burayı imzalayın ve tüm hayalleriniz gerçek olacak.

Bir BT çalışanı olarak: Buradaki süper kahraman olabilirim ve bu işi en iyi duruma getirerek yakınlardaki bir felaketi önleyerek şirketi kurtarabilirim! menajerim bana hediyeler verecek ve şirketi binlerce kurtaracağıma övgüler sunacak.

Ben ikisini de söylüyorum.

Şu anda% 40 ya da öylesine bir işlemciniz demiştiniz? Kullanıcının şikayetçisi (çok) henüz? Eğer hala nefes alma odanız yoksa. Daha fazla hafıza bir süre için yeterli olabilir.

Gidilecek yol için soru, evinizde yazılım geliştiriciniz var mı? Cevaplar HAYIR ise, tekrarlamaya çalışmayın bile. Tam olarak şu anda bulunduğunuz yere gideceksiniz.

Ev geliştiricileriniz olduğunu varsayarsak, ev geliştiricileriniz bir projeyi uygun şekilde yapma yeteneğine sahip mi? Ben tam olarak, düzgün bir şekilde zamanla ortaya çıktığını söyleyeceğim (temel olarak bir müşterinin projesiymiş gibi). Değilse, o zaman zahmet etmeyin yoksa şimdi olduğunuz yere geri dönecektir.

Şirketler aynı zamanda kendi müşterileri olduklarını ve aynı kaynakları iç projelere vermeleri gerektiğine dek, tam olarak şu anda bulunduğunuz yere kadar gideceksiniz. Orada bulundum, yaptım, bütün bir t-shirt şifoniyerim var.

Eğer doğru şekilde yapamıyorsanız, iki seçeneğin kutu anahtar teslimi dışındasınız, bu sayede personeliniz nefret edecek, çünkü şimdi satın aldığınız sistemin kalıbına uymanız gerekiyor. Veya özelleştirilebilir olacak ve yine de PROJEK ile zaman ayırarak özelleştirmeniz gerekecek.

VEYA Refactor ne var. İnsanların, yenileri geldiğinde tamamen aynı işlevselliği bekleyeceklerini unutmayın, bu yüzden başka bir yolla her şeyi bir seferde yapmak zorundasınız. Yeniden faktoring yaparsanız, nasıl çalıştığını anlama şansınız olur ve daha sonra geçici değişiklikler birçok küçük alt projeye planlamanızı sağlar.

Sistemi görmeden, muhtemelen arka uçta olabildiğince normalleştirme, SQL'in Depolanan işlemlerine geçme ihtimalini görürüm. Ardından, C # Formları veya bir webapp dışında yeni bir ön uç oluşturun. İş mantığınızı ve SQL'inizi ön uçtan çıkarabilirseniz, daha sonra yeniden yapmanız daha kolay olacaktır. Küçük projeler için ne yaptığınızı koruyarak, herhangi bir zamanda bir kenara itilirse veya durdurulursa, kullanılacak olan ilerlemeyi gerçekleştirmiş olursunuz.

Buradaki bazı iyi cevaplar - ancak şunu söyleyebilirim ki (ev geliştiricilerinde varsayarak) göreceli olarak az miktarda bir çalışmanın büyük bir etkisi olacağı belirtilmelidir - birincil anahtarlar (tüm sorgularınızı değiştirmek zorunda kalmamalısınız bile) onları kullanın), kullandığınız alanlara indeksler ekleyin ve sorgularınızı biraz ayarlayın ve kesinlikle büyük bir artış görebilirsiniz. Düzeltmek için gereken zamanı ve boşluğu satın almak için kendinize biraz RAM alın ve ardından işe başlayın.

Sistemin özellikleri temelde sizin için çalışıyorsa ve ihtiyacınız olanı yaparsanız, tekerleği yeniden yazmayın. Eğer kullanıcılarınız bu şeyi kullanmak için jimnastik yapmak zorunda kalıyorlardı, çünkü ihtiyaçlarınızı karşılamıyorsa, bunun için çaba harcamaya gerek yoktur.

Şey ... bu bir süre önceydi, ama sonucu buraya kaydedeceğim sandım.

Sonunda, başka bir problemle başa çıkmak için VBA hattını satır adım ilerledim. Daha sonra, bazı satırlara getirme çağrılarının 20-30 + saniye boyunca engellediğini fark ettim.

Onları kazdıkça, satır kümesinin bir MS Access sorgusuna dayandığını buldum.

Başka bir Access sorgusundan veri seçiyordu.

Başka bir Access sorgusundan veri seçiyordu.

Hepsi, sorgu tasarımcısı kullanılarak birlikte sürüklenip bırakılmış gibi görünüyorlardı.

Üst düzine kullanıcı ağrı noktalarının üzerinden geçtim ve başarısız olmadan hepsinin tamamen aynı olduğunu gördüm.

Böylece zincirleme sorgu yığınlarını tamamen kaldırdım ve her birini T-SQL'de yazılabilecek ve doğrudan sunucuda çalıştırılabilecek tek bir doğrudan sorgula değiştirdim.

Gelişme, her durumda başarısız olmadan kesinlikle çok büyüktü ve artık hiç kimse için sorgu beklemiyordu.

Sonra şirketten ayrıldım. Hala orada olup olmadığına dair hiçbir fikrim yok ... ama özlemiyorum.

Sadece Dayton'ın cevabına eklemek yerine ayrı bir cevap gönderiyorum çünkü bir cevap gönderen ilk birkaç kişi tarafından hesaba katılmayan bir maliyet var: Kullanıcıları yeniden eğitmenin maliyeti ve iş prosedürlerinizi uygun şekilde değiştirmenin maliyeti yeni bir yazılım programı. Aksi takdirde, ne dedi.

Şirketlerin kendi yazılımlarını geliştirmelerinin ana nedenlerinden biri, piyasada bulunan bir şeyle eşleşmeyen iş prosedürlerine sahip olmalarıdır. Hangisi harika - bir şirketin bireysel iş prosedürleri, bir şirketin masaya getirdiği değerin önemli bir parçasıdır ve bir şirketin pazarının geri kalan kısmında elde ettiği rekabet avantajıdır. Yazılımı genel bir şeyle değiştirmek, çalışanlarınızı eğitmenizi ve rekabet avantajından ödün vermenizi veya çözümü iş süreçlerinize uyacak şekilde özelleştirmeniz gerekir. Her ikisi de pahalıdır ve zaman alıcıdır. Bir sysadmin'in yanı sıra bir iş danışmanı olarak, bu maliyetlerin küçük şirketleri kendileri öldürdüğünü gördüm.

İfadelerinize göre, hemen hemen işlemci / yazılım bağlısınız. İki şey yapardım - özellikle şu anda kullanmayan sütunlara dizinler (sınırlar dahilinde) ekleyin. Ve en hızlı işlemci setini yakaladım, çünkü o kadar çok sürücünün okuduğunu bilmiyorsanız bağladığın yer gibi görünüyor.

(Ayrıca, sunucu sürümünü olabildiğince yükseltirdim - bunu gerçekleştirdiğiniz zaman, Access 2000 ve SQL Server 2000 on yaşında olacak. Bu bilgisayar yıllarında ESKİ!

Bunun için tam bir yeniden yapılanma gerekir (yeniden yapılanma). Sistemi sıfırdan yeniden kurun. Bu size uzun vadede çok fazla tasarruf sağlayacaktır (bakımda genel masraflar). Bu süre zarfında, chuck donanımı. Bu sorunun teknik bir soruşturmadan çok bir "iş vakası" olduğunu düşünüyorum. Teknik olarak, cevap açık bir şekilde "ona daha fazla güç ver". Kurumsal olarak, yeni bir sistem oluşturun!

Teknik cevap:

Birincil anahtarları belirten bir dizi öneriniz var ve indekslemenin iyice gözden geçirilmesi gerekiyor. Access ayrıca, her tabloda bir SQL Server TimeStamp aka RowVersion sütunu kullanmaktan gerçekten hoşlanıyor çünkü bu, Access'in kayıtları güncellerken bir kaydın değiştirilip değiştirilmediğine karar vermek için harcadığı süreyi azaltır.

Ticari cevap:

Yeni bir CRM çözümü eğitimcilerde çok fazla iş yapıyor ve asla iş gereksinimlerinize tam olarak uyan bir sistemle sonuçlanmayacak.

SQL Server'da da çok iyi bilen iyi bir Access kişisini bulur ve tabloları normalleştirmek ve kullanıcı acı noktalarını gidermek için 3 ya da 6 ay geçirmelerini sağlardım. Sakin bir alanda olmasına rağmen erişebileceği saem katlarda, kullanıcılarınız olarak çalıştığından emin olun. Çok erişilebilir olmasa da. Geliştiriciler kesintileri sevmez. S

Verilen bilgilere dayanarak sistemi değiştiririm. Tercihen, diğer sistemlerle esnek bir entegrasyon sağlayan bir CRM ile ( ERP IS'inizi tehlikeye atacak ).

En zor kısım, yönetimi ve kullanıcıları bir yükseltme işlemine ihtiyaç duymaya ikna etmek olacak.

yönetim

Teknik meseleler, düşük performans, Bizans başarısızlıkları korkusu vs. hakkındaki endişelerinizi dile getirin. Ardından 2 alternatif CRM sunun. İş entegrasyonundan, iş için genel ERP stratejisinden ve en önemlisi çalışanların daha verimli ve karlı olmalarını sağlayın. Örnek olay incelemelerini kullanın. Bunu 15 dakikadan fazla yapmayın (daha fazla bilgi istemiyorlarsa). Sonra kullanıcıları ikna etmeniz gerekir.

Kullanıcılar

Eğitim planları (bir satıcının tedarik edebileceği [ve yönetimin onaylaması gerekebilir]), kullanıcılarınızın ilk% 20'siyle (uzman kullanıcılar, sorun çıkaranlar) iletişimi sürdürmek ve sistemi% 100 çalışır durumda tutmak için sağlam bir taahhüt ilk ay için (ilk ay herhangi bir yeni IS'yi yapacaktır veya kıracak).

Dışarıda bir çok CRM ürünü var, iş gereksinimlerinize en uygun ürünü seçin.

Donanımı ona atmak, sadece daha zayıf tasarım ve yönetimi teşvik eder, sistem o kadar acıklı oluncaya kadar en son ve en iyi donanımda bile iyi çalışmaz. Daha iyi bir uygulamaya bakmanın zamanı geldi. İlk önce neyin gerekli olduğunu analiz edin. Yalnızca gereklilikleri tamamen anladığınızda, bunları yerine getirmenin en iyi yolunu aramaya başlayabilirsiniz. Gereksinimleri anladığınızdan emin olduğunuzda, sahip olduklarınızı değiştirmenin veya sıfırdan başlamanızın, muhtemelen tamamen farklı bir şeyle daha iyi / daha uygun maliyetli olup olmadığını aramaya başlayın.

Uzun vadede muhtemelen veritabanını yinelemenin en iyisi olur. Daha fazla donanım atmak, sorununuzu bir süre için çözecektir, ancak kullanmaya devam ederseniz, bir süre sonra daha fazla donanım atmak zorunda kalacaksınız.

Genelde performans sorunları olduğunda, sabit disklerdeki / RAID'deki darboğazlar, veritabanını paylaşan, vb. Gibi şeylere bakarsınız ... ama keskinleştirmek için, veritabanından tam olarak yararlanabilmek için tasarlanmış olması gerekir. Bunun seslerinden uygulamanız asla ölçeklenemez.

Uzun vadede, mevcut iş gereksinimlerinizi daha iyi yansıtabilmek için veritabanını ve ön uç yazılımı tekrarlamak, uzun vadede size daha iyi hizmet verecektir. Kullanıcılarınız size teşekkür edecek, donanımınız daha uzun sürecek ve uzun vadede konuyla ilgili devasa donanım atmaktan çok daha fazla para kazandıracak.

Açıklamanız göz önüne alındığında, tamamen yeni bir ısmarlama sistemin oluşturulması anlamsızdır - başladığınız yere, belki de şimdi olduğunuzdan daha da kötüye gideceksiniz. Bu nedenle, birini üçüncü taraf çözümü almaya ikna edemiyorsanız, en iyi seçeneğiniz en iyi şekilde yeniden yönlendirmek ve donanım atmaktır.

İki şeyi yapmanız gerektiğini söyleyebilirim: 1) SQL sunucusunda performans analizi. Sunucu tarafını gecikmelerin kaynağı olarak tanımlamış görünüyorsunuz, bu nedenle şimdi hangi sorguların geciktiğini ve nedenini bilmeniz gerekiyor. Her durumda, optimize etmek için size büyük faydalar sağlayacak bazı sıcak nokta sorguları bulabilirsiniz. Heck, birkaç saniyede bir güncelleme yapan müşterileriniz varsa, güncelleme oranlarını düşürüp düşüremeyeceğinizi görün. (Ekrandaki listenin GERÇEKTEN her 5 saniyede bir güncellenmesi gerekiyor mu? 30 tamam mı? ). Yenileme zamanlayıcılarını arttırmak gibi aptal şeyler, bununla kaçınmanız durumunda sizi fazladan kurtarabilir.

2) Daha fazla donanım at. ÖZEL olarak, ona büyük miktarda koç atıyorlar. Veritabanının tamamen RAM'e sığacağı kadar bellek istiyorsun. OS ve yazılım sürümleri bir göz atın (orada görünüşte oldukça Windows sürümleri ile kuralların toplamıdır ve ne aslında destek donanım). Kendinizi daha fazla çekirdeğin yardım edeceğine ikna edebiliyorsanız, o zaman elde edebildiğiniz kadar CPU ve çekirdeği atın.

RAM ve işlemcilerden bahsettiniz, ancak disklerden değil. MS’in SQL Server’ını ele aldığımdan bu yana neredeyse on yıl geçtiğini itiraf ediyorum;

Muhtemelen önce makineyi alabileceği kadar RAM ile doldurmaya çalışacağım - o zaman günlüklerin tablolar veya indeksler için kullanılmayan disklere yazıldığından emin olurdum. Daha sonra hiçbir tablonun indekslerinin aynı iş milinde olmadığından emin olmaya çalışırdım.

Ondan sonra, veritabanı düzeyinde ayarlama konusunda endişeliydim, ancak bununla birlikte, testlerinizi ve optimizasyon hedefinizi tanımlamanız gerekecek, böylece işleri bozmamanız veya sorguları daha da kötüleştirmeniz gerekecek. Birincil anahtarların test veritabanınızda çok fazla avantaj göstermediğini söyleseniz de, test metodolojinize bakmalısınız - birincil anahtarlar bazı veritabanlarının (MS SQL'in bunlardan biri olup olmadığından emin olamaz) kayıt düzeyinde kilitleme kullanmasına izin verebilir sadece birkaç kullanıcı ile yapılan testlerde gösterilemeyen çekişmeyi azaltabilecek masa seviyesindeki kilitler yerine.

İlk önce, Kyle Hodgson ile aynı fikirdeyim ve PK ekleyin. Ucuzdur (yalnızca zaman) ve sorgularınızda bir artış görebilirsiniz. En çirkin 10 sorgunuzdaki birleştirme sütunlarındaki dizinler ne durumda? Masa taraması nerede?

İkincisi, veritabanındaki verilerin kırpılması ne durumda? Sorgularda gerçekten gerekenden daha fazla satır döndürülüyor mu? Ayrıca Kyle'ın RAM önerisiyle (iki GB daha fazla) aynı fikirdeyim.

Bunların hepsini, geleceği belirlerken ara için teklif ettiğiniz şeyi yazdığınız (Joseph Kern) içine yerleştirin. Mevcut CRM uygulaması huzursuzsa ve uygun değilse, yönetime ve kullanıcılara kuruluşa ne olacağını sorun. Belki de bu, gelecek hakkında düşünmelerini sağlamaya yardımcı olacaktır.

Donanımı al!

Xeon 55xx serisi bir yonga için giderseniz sadece kalay çok ucuz değil, attığınız her şey için çığlık atar.

Bu sadece bir risk / ödül meselesi - DB'yi daha iyi hale getirmek için para ve çok zaman harcayabilir ya da yolunuzu daha hızlı ve ucuza satın alabilirsiniz.

3GB hafıza anahtarını çevirmeyi ve başka bir 2GB hafıza eklemeyi düşünün .