Ini adalah pertanyaan HEBAT dan saya menemukan tanggapan yang menarik. Saya akan mengomentari ini sebagai Oracle DBA dan jawaban saya adalah KHUSUS untuk database Oracle. Ini adalah kesalahan besar yang dilakukan banyak orang ketika bekerja dengan Oracle. Saya tidak yakin apakah ini berlaku untuk aplikasi lain juga. Ini tidak dimaksudkan untuk di luar topik, tetapi dimaksudkan sebagai jawaban khusus.
Ketika Anda menyesuaikan kinerja dengan Oracle, Anda benar-benar ingin membersihkan kemacetan. Meskipun kebanyakan dari kita tidak mengatakannya, ini didasarkan pada Teori Kendala: https://en.wikipedia.org/wiki/Theory_of_constraints
Memori mungkin bukan hambatan Anda. Oracle memiliki mekanisme kompleks untuk mengelola memori dan hanya meningkatkan memori sebenarnya dapat memperlambat segalanya jika area lain berada di mana hambatannya. Biarkan saya memberi Anda satu contoh yang SANGAT umum.
Pertanyaan tampaknya lambat. Konsensusnya adalah jika kita meningkatkan RAM, kita harus meningkatkan waktu respons pertanyaan karena memori lebih cepat daripada disk. Baiklah ... Beginilah cara Oracle menangani manajemen memori untuk data. Oracle memiliki berbagai lokasi memori yang dialokasikan untuk tugas tertentu. Jadi Anda bisa menambah kenangan ini. Area yang digunakan untuk data disebut 'buffer cache'. Ini adalah serangkaian daftar tertaut (jumlah mereka cenderung meningkat pada setiap versi). Setiap kali sebuah blok ditemukan pada disk selama kueri, sebuah algoritma hash dijalankan di atasnya untuk menentukan daftar mana yang akan dimasukkan. Di mana memasukkannya ke dalam daftar didasarkan pada algoritma hitungan sentuh (dijelaskan di situs dukungan Oracle, jadi Anda harus membayar untuk mendapatkannya ... itu tidak terlalu penting).
NAMUN, ketika Anda menjalankan kueri, Oracle mengeluarkan kait pada rantai penyangga yang Anda cari saat itu. LATCH ini (catatan: ini bukan kunci. Google "latch" jika Anda tidak tahu bedanya) memblokir semua operasi lain di rantai itu selama Anda membaca. Jadi itu memblokir membaca DAN menulis (ini sama sekali berbeda dari Oracle mengklaim kunci tidak memblokir dibaca).
Ini diperlukan karena saat Anda membaca blok dalam rantai, Oracle memindahkannya berdasarkan seberapa sering 'diminta'. Blok yang lebih sering diminta dipindahkan ke atas dan blok yang lebih jarang diminta dibiarkan di bagian bawah dan usang. Anda tidak dapat memiliki 2 sesi membaca daftar tertaut dan memindahkan blok di sekitar atau Anda akan menekan pointer yang mengarah ke lokasi yang tidak ada.
Ketika Anda menambah ukuran memori, Anda menambah ukuran setiap daftar yang ditautkan. Ini menambah waktu yang diperlukan untuk membaca daftar. Satu permintaan miskin atau permintaan kompleks dapat melakukan puluhan ribu atau bahkan jutaan membaca daftar tautan. Setiap pembacaan cepat, tetapi jumlahnya mengarah ke kait yang diambil dan ini akan memblokir sesi lainnya. Oracle menyebut ini sebagai 'IO logis' (atau buffer get atau beberapa hal lain. Istilah ini khusus untuk Oracle dan dapat berarti sesuatu yang lain di bagian lain TI).
Jadi, jika daftar lebih panjang dan Anda memiliki SQL yang benar-benar buruk, maka pernyataan SQL akan menahan kait mereka lebih lama. Meningkatkan memori sesekali dapat MENGURANGI kinerja. Sebagian besar waktu, ini tidak akan terjadi. Orang akan menghabiskan banyak uang dan tidak melihat manfaatnya. Yang sedang berkata, ada saat-saat ketika Anda membutuhkan lebih banyak memori dalam cache buffer, tetapi Anda harus mengidentifikasi dengan benar bottleneck untuk mengetahui apakah ini tepat. Saya tidak dapat membahas cara menganalisis ini di pos ini. Lihat forum DBA. Beberapa orang mendiskusikannya di sana. Agak rumit.
Adakah yang punya contoh spesifik dengan perangkat lunak lain di mana ini bisa terjadi? Ada buku bisnis hebat yang disebut 'The Goal' yang membahas meringankan kendala di sebuah pabrik. Proses ini sangat mirip dengan apa yang dilakukan DBA Oracle ketika menilai masalah kinerja. Ini sering membaca standar dalam program MBA. Sangat berharga untuk membaca untuk profesi IT.
https://en.wikipedia.org/wiki/Eliyahu_M._Goldratt