Basis data internal yang buruk - ganti atau buang perangkat keras itu?

Jadi - kami memiliki basis data perusahaan internal, jenis barang yang biasa: mengelola klien, panggilan telepon, transaksi penjualan, dan perjanjian / skema klien.

Ini adalah Access 2000 front-end, dan SQL Server 2000 Standard back-end. Server tunggal, dual Xeon 3.2GHz, RAM 2GB, Windows Server 2003, mendapat sekitar 40% beban CPU sepanjang hari, tersebar di 4 core yang terlihat oleh OS (HT).

Basis data back-end dirancang dengan buruk, dan telah tumbuh secara organik lebih dari 10 tahun, dikelola oleh individu yang kurang terampil. Ini dinormalisasi dengan buruk, dan beberapa masalah yang jelas termasuk tabel dengan puluhan ribu baris tanpa kunci primer atau indeks, yang juga banyak digunakan dalam gabungan multi-tabel untuk beberapa bagian sistem yang paling banyak digunakan (misalnya aplikasi panggilan manajer yang duduk di monitor kedua semua orang selama 8 jam sehari dan menjalankan permintaan besar yang tidak efisien setiap beberapa detik).

Front-end tidak jauh lebih baik, ini adalah kekacauan khas dari ratusan bentuk, query tersimpan bersarang, SQL tertanam yang ditulis dengan buruk dalam kode VBA, puluhan "quirks" dll, dan setiap kali perubahan dilakukan sesuatu yang tidak terkait tampaknya rusak. Kami telah menetapkan satu MDB yang berfungsi "cukup baik" dan sekarang memiliki kebijakan tidak ada perubahan karena kami tidak memiliki akses kelas berat di dalam perusahaan (dan tidak ada rencana untuk menyewa satu pun).

Perusahaan sekarang perlahan-lahan tumbuh, meningkatkan jumlah klien, panggilan, dll, serta sedikit peningkatan jumlah pengguna secara bersamaan, dan kinerjanya telah menjadi semakin buruk baru-baru ini (menunggu untuk bergerak di antara formulir, menunggu daftar untuk diisi dll) )

Perfmon mengatakan:

• Transfer disk per detik: antara 0 dan 30, rata-rata 4.
• Panjang antrian disk saat ini: berkisar sekitar 1

Profiler SQL Server melihat ratusan ribu kueri setiap menit. Penggunaan CPU pada klien hampir nol, menunjukkan itu menunggu permintaan sisi server untuk dieksekusi. Saya telah menempatkan beban kerja ini melalui DB Engine Tuning Advisor, menerapkan saran-sarannya pada cadangan uji, tetapi ini tidak benar-benar membuat banyak perbedaan.

Omong-omong, kami memiliki campuran 100MB dan gigabit ethernet, semuanya dalam satu subnet, 40 pengguna ish di dua lantai.

Untuk pertanyaan.

Seperti yang saya lihat, kita memiliki dua pilihan untuk menyelesaikan / memperbaiki situasi ini.

• Kami dapat memo dan menggantinya dengan sistem CRM yang sama sekali baru, baik dipesan lebih dahulu atau sebagian dipesan lebih dahulu
• Kita dapat memperpanjang umur sistem ini dengan melemparkan perangkat keras padanya.

Kita dapat membangun sistem Intel i7 dengan angka kinerja gila dengan urutan biaya lebih murah daripada mengganti perangkat lunak.

Ketika suatu sistem baru pada akhirnya dikembangkan, ia dapat di-host pada kotak ini, sehingga tidak ada perangkat keras yang terbuang. Sistem CRM baru terus ditunda, mati, dan mati - Saya tidak melihat itu terjadi selama setidaknya satu tahun.

Setiap pemikiran tentang situasi ini, terutama jika Anda sudah berada di sini sendiri, akan sangat dihargai.

Terima kasih

Saya akan tidak setuju dengan semua orang di sini. Chuck beberapa perangkat keras. Itu murah, cepat, mudah, dan akan memberi Anda waktu yang dibutuhkan untuk mengimplementasikan solusi CRM yang tepat. Alasan saya menganjurkan sesuatu yang merupakan kutukan bagi hampir semua orang tidak hanya di forum ini, tetapi juga stackoverflow, adalah bahwa saya telah menjadi manajer proyek / manajer dan telah berada di sisi "Bisnis" untuk sementara waktu (bisnis) ada dalam tanda kutip karena kebencian saya untuk kata). Berdasarkan uraian perangkat lunak Anda, dibutuhkan waktu hampir satu tahun untuk membangun kembali sesuatu yang lain. Hanya menemukan / mendokumentasikan aturan bisnis / kebiasaan, mungkin akan memakan waktu 2 bulan. Ini juga akan sangat mahal untuk dikembangkan. Apalagi jika dibandingkan dengan biaya server yang ditipu.

Saya sebenarnya akan meng-host sejumlah aplikasi web untuk perusahaan hanya untuk alasan itu. Departemen TI internal tidak akan memindahkannya ke perangkat keras yang lebih baik karena mereka ingin mengembangkannya kembali di platform baru. Biaya itu kira-kira tiga kali lipat dari biaya untuk memindahkannya ke perangkat keras baru. Tidak terlalu menyebutkan bahwa perusahaan mungkin tidak memperpanjang kontrak dalam setahun.

Anda mungkin juga tidak perlu melakukannya. Saran saya adalah cukup menambahkan beberapa indeks / kunci ke tabel.

tabel dengan puluhan ribu baris tanpa kunci primer atau indeks, yang juga banyak digunakan dalam gabungan multi-tabel

Sebelum menghabiskan banyak uang atau waktu, luangkan beberapa jam dan tambahkan indeks (atau kunci utama jika Anda bisa) ke setiap tabel yang terlibat dalam gabungan itu ... terutama untuk kolom yang digunakan dalam klausa mana. Anda dapat dengan mudah meningkatkan kinerja dengan faktor 10 hanya dalam beberapa jam.

Kurangnya disk I / O menyiratkan bahwa kueri sebagian besar diberi makan dari RAM. Jika Anda 'tiba-tiba' memiliki meja panas Anda tidak muat di RAM lagi dan server mulai bekerja disk, Anda mungkin berada dalam perjalanan yang buruk. 2GB atau RAM tidak terlalu banyak akhir-akhir ini, tetapi kembali ke era SQL2000 itu akan cukup besar. Saya menduga bahwa jumlah data yang biasanya dimanipulasi aplikasi lebih kecil dari RAM yang Anda miliki. Anda mungkin ingin melihat jumlah ruang "bekas" dalam file data. Ini akan memberi Anda gambaran tentang seberapa banyak RAM yang dikonsumsi oleh database, yang terburuk. SQL Server tidak menyimpan data yang tidak diperlukan dalam RAM, tetapi bisa sulit untuk mengetahui tabel apa yang digunakan dan kapan.

Hyperthreading tidak selalu membantu dengan SQL Server. Anda mungkin mendapatkan kinerja yang lebih baik mematikannya. Sulit untuk diuji karena mematikannya dan menghidupkannya membutuhkan reboot, dan itu adalah masalah besar pada server produksi.

"Ratusan ribu kueri per menit" diterjemahkan menjadi ribuan kueri per detik. Kedengarannya cukup sibuk, tetapi banyak dari lalu lintas itu mungkin hanya mengambil kursor oleh Access. Akses sangat buruk pada pengambilan set hasil secara efisien dari SQL. Anda mungkin mendapatkan kinerja yang lebih baik dengan mematikan pengaturan paralelisasi SQL Server.

Anda juga ingin mencari pemblokiran. Melempar perangkat keras pada masalah pemblokiran tidak selalu menghasilkan peningkatan dramatis yang diharapkan. Jika tidak ada banyak pemblokiran dan pertanyaan dipenuhi oleh RAM, daripada disk, pada dasarnya Anda mengandalkan penggeraman prosesor, dan kemampuan mereka untuk menarik data melintasi saluran memori. Dalam hal ini, perangkat keras yang lebih cepat harus memberikan peningkatan yang baik. Jika Anda terburu-buru (untuk mengatasi masalah ini) dan tumbuh perlahan, itu mungkin cukup baik.

Sebagai solusi, menambahkan perangkat keras tidak meningkatkan skala serta perbaikan basis data. Jika Anda mengalami lonjakan pertumbuhan, perangkat keras baru Anda mungkin akan kesulitan. Pemikiran lain adalah aplikasi yang berhasil menarik pengguna. Jika aplikasi menjadi lebih responsif, pengguna mungkin lebih cenderung menjalankan lebih banyak laporan dan semacamnya daripada jika mereka perlu minum kopi sambil menunggu laporan selesai.

Jika skema database benar-benar buruk, Anda mungkin bisa mendapatkan beberapa kemenangan kinerja hanya dengan melihat indeks pada tabel. Berkonsentrasi pada tabel yang Anda tahu sering ditanyakan. Anda dapat menggunakan Profiler untuk menonton kueri yang berjalan melawan server, katakan saja untuk mencari kueri yang membaca banyak data (seperti 100.000 halaman) dan kemudian mengerjakan kueri yang tidak banyak membaca. Anda menyebutkan bahwa beberapa tabel tidak memiliki kunci. Apakah ada kunci alami dalam data, tidak dipaksakan oleh kendala atau indeks unik?

Apakah tabel memiliki indeks berkerumun? Kurangnya pengindeksan berkelompok dapat menyebabkan segala macam efek sekunder.

Apakah ada banyak indeks nonclustered, dengan banyak kolom? Ini sering merupakan upaya untuk membangun banyak indeks yang mencakup, daripada menerapkan strategi pengindeksan yang lebih efektif. SQL Server dapat secara efektif membangun indeks yang meliputi on the fly selama permintaan, jika masuk akal untuk melakukannya dan ada yang mendukung indeks nonclustered dan clustered.

Terakhir, ada baiknya bertanya: Apakah pemeliharaan (pengindeksan kembali dan / atau memperbarui statistik) dilakukan di atas meja?

ini adalah pertanyaan bisnis, bukan pertanyaan teknis.

Sebagai pemilik bisnis: Seberapa strategis sistem bagi bisnis? semakin kurang strategis, semakin saya tidak peduli & memperbaikinya & uang yang dihabiskan, adalah uang yang bisa saya gunakan di tempat lain untuk menumbuhkan bisnis saya.

Orang-orang komputer membuatku takut ketika mereka semua masuk ke ruangan besar & berdebat tentang desain & menghabiskan banyak uang. Biarkan sistem berjalan! apakah ini berarti penyelarasan kinerja (tanpa merancang ulang) atau melemparkan lebih banyak perangkat keras padanya, itu hanya prioritas jika berhenti bekerja.

Sebagai konsultan TI: Sistem Anda adalah warisan dan menyembunyikan biaya operasional. Kami dapat merancang sistem yang tepat untuk Anda, yang akan meningkatkan skala dan menyediakan platform untuk pertumbuhan masa depan & keuntungan strategis. Tandatangani di sini & semua impian Anda akan menjadi kenyataan.

Sebagai karyawan IT: Saya bisa menjadi pahlawan super di sini & menyelamatkan perusahaan dengan menghindari bencana yang akan terjadi dengan mengoptimalkan neraka dari hal ini! manajer saya akan menghujani saya dengan hadiah & pujian karena saya telah menyelamatkan ribuan perusahaan.

Saya katakan lakukan keduanya.

Saat ini Anda pada 40% atau lebih CPU yang Anda katakan? Apakah Anda pengguna banyak mengeluh? Jika tidak, Anda masih memiliki ruang bernapas. Lebih banyak memori mungkin cukup untuk melakukannya untuk sementara waktu.

Pertanyaan untuk jalan, apakah Anda memiliki pengembang perangkat lunak internal? Jika jawabannya TIDAK maka jangan pernah mencoba untuk mengulanginya. Anda akan berakhir persis di tempat Anda berada sekarang.

Dengan asumsi Anda memiliki in-house developer, apakah in-house developer Anda memiliki kemampuan untuk melakukan proyek dengan benar? Saya sedang berbicara tentang timeline sepenuhnya, benar (relistik), pada dasarnya sama seperti jika itu adalah proyek pelanggan. Jika tidak, maka jangan repot-repot atau itu akan berakhir kembali di tempat Anda sekarang.

Sampai perusahaan menyadari bahwa mereka juga klien dari diri mereka sendiri, dan perlu memberikan sumber daya yang sama untuk proyek-proyek internal, Anda akan berakhir di tempat Anda berada sekarang. Berada di sana, melakukan itu, mendapat seluruh meja rias t-shirt.

Jadi, jika Anda tidak dapat melakukannya dengan benar, Anda dua pilihan di luar kotak kunci, yang staf Anda akan benci karena mereka sekarang Anda harus sesuai dengan cetakan sistem yang Anda beli. Atau itu akan dapat disesuaikan dan Anda masih harus menghabiskan waktu PROYEK untuk mengubahnya.

ATAU Refactor apa yang Anda miliki. Ingat orang akan mengharapkan semua fungsionalitas lengkap yang sama ketika yang baru masuk, jadi itu sebabnya cara lain Anda harus melakukan semuanya sekaligus. Jika Anda memfaktorkan ulang faktor itu, Anda memiliki kesempatan untuk mengetahui cara kerjanya dan kemudian mengubah secara ad-hoc Anda merencanakannya ke banyak sub proyek kecil.

Tanpa melihat sistem, saya mungkin akan melihat tentang normalisasi sebanyak yang saya bisa di back-end, memindahkan sebanyak mungkin SQL ke procs yang tersimpan. Kemudian buat front end baru dari C # Forms atau webapp. Jika Anda bisa mengeluarkan logika bisnis dan SQL dari ujung depan, akan lebih mudah untuk melakukannya lagi nanti. Dengan mempertahankan apa yang Anda lakukan pada proyek-proyek kecil, jika proyek itu disingkirkan kapan saja atau dihentikan, Anda akan membuat kemajuan yang akan digunakan.

Beberapa balasan bagus sudah ada di sini - tetapi mungkin saya hanya menunjukkan bahwa (dengan asumsi ada pengembang dalam rumah) sejumlah kecil pekerjaan akan memiliki dampak besar - tambahkan kunci utama (Anda bahkan tidak perlu mengubah semua pertanyaan Anda menjadi gunakan), tambahkan indeks ke bidang yang Anda gunakan, dan sesuaikan kueri Anda dan Anda bisa melihat peningkatan yang sangat besar. Beli sendiri beberapa RAM untuknya sekarang untuk membeli waktu dan ruang kepala yang Anda butuhkan untuk memperbaikinya, dan kemudian mulai bekerja.

Pada subjek "memperbaiki atau membuangnya", jika fitur sistem pada dasarnya bekerja untuk Anda dan melakukan apa yang Anda butuhkan, jangan menulis ulang kemudi. Jika pengguna Anda harus melakukan senam untuk menggunakan benda itu karena tidak sesuai dengan kebutuhan Anda, maka tidak ada gunanya mengusahakannya.

Nah ... ini beberapa waktu yang lalu, tapi saya pikir saya akan mencatat hasilnya di sini.

Pada akhirnya, saya melangkah melalui garis VBA demi baris untuk menangani masalah lain. Saat itulah saya menyadari bahwa beberapa panggilan untuk mengambil rowset diblokir selama 20-30 + detik.

Ketika saya menggali ke dalamnya, saya menemukan bahwa rowset didasarkan pada permintaan MS Access.

Itu memilih data dari kueri Access lain.

Itu memilih data dari kueri Access yang lain.

Semuanya tampak seperti telah diseret dan dijatuhkan menggunakan desainer kueri.

Saya pergi melalui setengah lusin poin pengguna rasa sakit dan menemukan bahwa tanpa gagal mereka semua persis sama dengan ini.

Jadi saya menghapus tumpukan pertanyaan dirantai sepenuhnya, dan mengganti masing-masing dengan satu permintaan pass-through yang dapat ditulis dalam T-SQL dan dieksekusi langsung di server.

Peningkatannya sangat besar dalam setiap kasus tanpa gagal dan tidak ada lagi menunggu pertanyaan lagi untuk siapa pun.

Dan kemudian saya meninggalkan perusahaan. Tidak tahu apakah masih ada di sana ... tapi saya tidak ketinggalan.

Saya memposting jawaban terpisah alih-alih hanya menambahkan jawaban Dayton karena ada biaya yang tidak diperhitungkan oleh beberapa orang pertama yang mengirim jawaban: Biaya melatih kembali pengguna dan biaya mengubah prosedur bisnis Anda agar sesuai dengan program perangkat lunak baru. Kalau tidak, apa yang dia katakan.

Salah satu alasan utama perusahaan mengembangkan perangkat lunak mereka adalah karena mereka memiliki prosedur bisnis yang tidak cocok dengan sesuatu yang ada di pasaran. Yang hebat - prosedur bisnis individu perusahaan adalah bagian penting dari nilai yang dibawa perusahaan ke meja, dan ADALAH keunggulan kompetitif yang dimiliki perusahaan selama sisa pasarnya. Untuk mengganti perangkat lunak dengan sesuatu yang umum akan mengharuskan Anda melatih orang-orang Anda dan mengorbankan keunggulan kompetitif, atau Anda harus menyesuaikan solusi agar sesuai dengan proses bisnis Anda. Keduanya mahal dan memakan waktu. Sebagai konsultan bisnis dan juga sysadmin, saya telah melihat biaya ini membunuh perusahaan kecil sendiri.

Dari pernyataan Anda, sepertinya Anda terikat banyak prosesor / perangkat lunak. Saya akan melakukan dua hal - tambahkan indeks (dalam batas), terutama ke kolom yang saat ini tidak menggunakannya. Dan saya akan membuang set prosesor tercepat yang Anda bisa, karena sepertinya itu adalah di mana Anda mengikat jika Anda tidak memiliki banyak drive yang dibaca kecuali di puncak.

(Juga, saya akan memutakhirkan edisi server sejauh mungkin - saat Anda menerapkannya, Access 2000 dan SQL Server 2000 akan berusia sepuluh tahun. Itu LAMA dalam tahun-tahun komputer!)

Ini membutuhkan penataan ulang total (re-architectureuring). Bangun kembali sistem dari bawah ke atas. Ini akan menghemat banyak dalam jangka panjang (biaya overhead dalam pemeliharaan). Sementara itu, buang perangkat kerasnya. Saya pikir pertanyaan ini lebih merupakan "kasus bisnis" daripada penyelidikan teknis. Dari segi teknis, jawabannya adalah "membuang lebih banyak kekuatan untuk itu". Dari segi bisnis, Bangun sistem baru!

Jawaban teknis:

Anda memiliki sejumlah saran yang menyatakan kunci utama dan pengindeksan harus ditinjau secara menyeluruh. Access juga sangat suka menggunakan SQL Server TimeStamp alias kolom RowVersion di setiap tabel karena ini mengurangi banyak waktu yang dihabiskan Access memutuskan apakah catatan telah diubah ketika datang untuk memperbarui catatan.

Jawaban bisnis:

Solusi CRM baru adalah banyak pekerjaan dalam melatih orang-orang dan Anda tidak akan pernah berakhir dengan sistem yang persis sesuai dengan kebutuhan bisnis Anda.

Saya akan menemukan orang akses yang baik yang juga sangat berpengetahuan tentang SQL Server dan membuat mereka menghabiskan 3 atau 6 bulan dalam normalisasi tabel dan memperbaiki poin rasa sakit pengguna. Pastikan orang itu bekerja di lantai saem sebagai pengguna Anda, meskipun dalam ruang yang tenang, dan dapat diakses. Meski tidak terlalu mudah diakses. Pengembang tidak suka interupsi. S

Berdasarkan informasi yang diberikan, saya akan mengganti sistem. Lebih disukai dengan CRM lain yang memungkinkan integrasi fleksibel dengan sistem lain (yang akan membahayakan IS ERP Anda ).

Bagian tersulit adalah meyakinkan manajemen dan pengguna untuk membutuhkan peningkatan.

Pengelolaan

Ekspresikan kekhawatiran Anda atas masalah teknis, kinerja rendah, ketakutan akan kegagalan Bizantium, dll. Lalu berikan 2 CRM alternatif. Bicara tentang integrasi bisnis, strategi ERP keseluruhan untuk bisnis, dan yang paling penting bagaimana ini akan membuat karyawan lebih produktif dan menguntungkan. Gunakan studi kasus. Buat ini tidak lebih dari 15 menit (kecuali mereka ingin info lebih lanjut). Maka Anda perlu meyakinkan pengguna.

Pengguna

Rencana pelatihan (yang dapat disediakan oleh vendor [dan manajemen perlu didukung]), komunikasi berkelanjutan ke 20% pengguna Anda (pengguna daya, yang menyebabkan masalah), dan komitmen yang kuat untuk menjaga sistem 100% operasional untuk bulan pertama (bulan pertama akan membuat atau menghancurkan IS baru).

Ada banyak produk CRM di luar sana, pilih satu yang paling sesuai dengan kebutuhan bisnis Anda.

Melemparkan perangkat keras padanya hanya mendorong desain dan manajemen yang lebih buruk, sampai sistem ini begitu menyedihkan sehingga tidak akan berjalan dengan baik bahkan pada perangkat keras terbaru dan terhebat. Saatnya untuk melihat implementasi yang lebih baik. Pertama, analisis apa yang diperlukan. Hanya ketika Anda benar-benar memahami persyaratannya, Anda dapat mulai mencari cara terbaik untuk mengimplementasikannya. Setelah Anda yakin memahami persyaratan, mulailah melihat apakah lebih baik / lebih hemat biaya untuk memodifikasi apa yang Anda miliki atau memulai dari awal, mungkin dengan sesuatu yang sama sekali berbeda.

Dalam jangka panjang Anda mungkin akan lebih baik mengulangi basis data. Melemparkan lebih banyak perangkat keras akan menyelesaikan masalah Anda sebentar, tetapi jika Anda terus menggunakannya, Anda akhirnya harus membuang lebih banyak perangkat keras setelah beberapa saat.

Biasanya ketika ada masalah kinerja Anda melihat hal-hal seperti i / o bottleneck pada hard disk / RAID, sharding database, dll ... tetapi untuk hal-hal seperti sharding Anda perlu database yang dirancang dengan baik untuk memanfaatkannya. Dari bunyi itu aplikasi Anda tidak akan pernah bisa skala.

Dalam jangka panjang mengulangi database dan perangkat lunak ujung depan untuk lebih mencerminkan kebutuhan bisnis Anda saat ini akan melayani Anda lebih baik dalam jangka panjang. Pengguna Anda akan berterima kasih, perangkat keras Anda akan bertahan lebih lama, dan itu akan menghemat lebih banyak uang dalam jangka panjang daripada membuang perangkat keras raksasa dalam masalah ini.

Mengingat deskripsi Anda, pembuatan sistem yang sepenuhnya baru dipesan lebih dahulu tidak ada gunanya - Anda akan berakhir tepat di mana Anda mulai, atau mungkin bahkan lebih buruk daripada Anda sekarang. Jadi, kecuali Anda dapat meyakinkan seseorang untuk membeli solusi pihak ketiga, taruhan terbaik Anda adalah melakukan refactor sebaik mungkin, dan melemparkan perangkat keras padanya.

Saya akan mengatakan bahwa Anda harus melakukan dua hal: 1) Analisis kinerja pada server SQL. Anda tampaknya telah mengidentifikasi sisi server sebagai sumber kelambatan, jadi sekarang Anda perlu tahu kueri mana yang tertinggal dan mengapa. Dalam semua kemungkinan, Anda dapat menemukan beberapa permintaan hot spot untuk mengoptimalkan yang akan memberi Anda manfaat besar. Heck, jika Anda punya klien yang memperbarui setiap beberapa detik, lihat apakah Anda dapat menolak laju pembaruan mereka (Apakah daftar di layar BENAR-BENAR perlu memperbarui setiap 5 detik? Apakah 30 akan OK? Jika tidak, bagaimana dengan 15? ). Hal-hal bodoh seperti meningkatkan timer penyegaran dapat menghemat banyak biaya overhead, jika Anda bisa melakukannya.

2) Lempar lebih banyak perangkat keras padanya. TERUTAMA melemparkan sejumlah besar ram ke dalamnya. Anda ingin begitu banyak memori sehingga database sepenuhnya cocok dalam RAM. Mengawasi OS dan versi perangkat lunak Anda ( tampaknya ada cukup banyak aturan dengan versi Windows dan perangkat keras apa yang sebenarnya mereka dukung). Jika Anda bisa meyakinkan diri sendiri bahwa lebih banyak core akan membantu, maka lemparkan CPU dan core sebanyak mungkin.

Anda telah menyebutkan RAM dan prosesor, tetapi bukan disk. Saya akui sudah hampir satu dekade sejak saya berurusan dengan MS's SQL Server, tapi itu terikat ke disk seperti halnya basis data lain, jika tidak dapat memuat semuanya dalam memori.

Saya mungkin pertama kali akan mencoba mengisi mesin dengan RAM sebanyak mungkin - maka saya akan memastikan log ditulis ke disk yang tidak digunakan untuk tabel atau indeks. Saya kemudian akan mencoba untuk memastikan bahwa tidak ada tabel yang memiliki indeks pada spindle yang sama.

Setelah itu, saya khawatir tentang penyetelan tingkat basis data, tetapi dengan itu, Anda harus menetapkan tes dan sasaran pengoptimalan sehingga Anda tidak merusak barang atau memperburuk kueri. Meskipun Anda mengatakan bahwa kunci utama tidak menunjukkan banyak keuntungan dalam database pengujian Anda, Anda harus melihat pada metodologi pengujian Anda - kunci primer dapat memungkinkan beberapa database (tidak yakin apakah MS SQL adalah salah satu dari mereka) untuk menggunakan penguncian tingkat rekor , daripada kunci level tabel, yang dapat mengurangi pertikaian yang mungkin tidak ditampilkan dalam pengujian dengan hanya beberapa pengguna.

Pertama, saya setuju dengan Kyle Hodgson dan menambahkan PK. Itu murah (hanya waktu) dan Anda mungkin melihat dorongan pada pertanyaan Anda. Bagaimana dengan indeks pada kolom gabungan di 10 kueri paling jelek Anda? Di mana pemindaian tabel?

Kedua, bagaimana dengan memangkas data dalam database? Apakah lebih banyak baris dikembalikan dalam kueri daripada yang benar-benar dibutuhkan? Saya juga setuju dengan saran Kyle tentang RAM (dua GB lebih banyak).

Masukkan semua ini ke dalam tulisan Anda (Joseph Kern) pada apa yang Anda usulkan untuk sementara sambil memetakan masa depan. Tanyakan manajemen dan pengguna apa yang terjadi pada organisasi jika aplikasi CRM saat ini tersedia dan tidak tersedia. Mungkin itu akan membantu mereka memikirkan masa depan.

Dapatkan perangkat keras!

Tidak hanya timah yang sangat murah saat ini jika Anda menggunakan chip seri Xeon 55xx, ia akan berteriak untuk apa pun yang dapat Anda lemparkan padanya.

Ini hanya masalah risiko / hadiah - Anda dapat menghabiskan uang dan banyak waktu untuk menjadikan DB lebih baik atau membeli lebih cepat dan lebih murah di sana.

Pertimbangkan membalik saklar memori 3GB dan menambahkan memori 2GB lainnya.