How much RAM should SQL Server have I have a database which takes up 500gb, I have noticed that my ple is low even though I have 100gb of RAM. I have searched in google to find reasons of that and I found some interesting queries. I have a query which runs on very big table even though it uses clustered index it causes ple to drop. I checked  what is in buffer pool before and after query and moment after query is done and it looks like DB has to free some space for index used in my query and after query old indexes are loaded to the buffer pool. My question is how much RAM memory should DB have, how could I calculate it, should it be amount which will let me keep all used indexes in memory at once? Or maybe I should reduce data kept in tables so indexes will be smaller?
Every time you scan a big index (or a big table, if you prefer) that data has to be brought from disk to memory. When this happens, if the buffer pool is holding data from other objects and does not have enough free space to accomodate the pages you are reading from disk, something has to be discarded. 

Low PLE means that this process happens too often, thrashing your buffer pool and overwhelming your I/O subsystem.

Some ways to improve it:


Add more RAM. Easy and not very expensive nowadays. Doesn't really solve the problem, but can be an acceptable short-term solution. How much RAM? Enough to hold the active portion of your databases. Only you can tell how much that is. Not all versions/editions of SQL Server and Windows can use the same amount of RAM, so make sure you're not limited by that.
Purge some data. Are you sure you need all the data you have in
there?
Create smaller indexes. That means including in your indexes the
minimum set of columns that cover your queries. Big scans work
faster on smaller indexes and require less RAM. The tradeoff is more
space used on disk and more operations to perform when updating the
table.
Create filtered indexes. If you are often filtering on a common
non-selective condition (eg: active=true or something similar) a
filtered index might help reducing the size of the indexes. This has
some impact on the application as well (some SET options
restrictions to make it work).
Use compression. Data is compressed both on disk and in memory, so
ROW/PAGE compression can be a way to reduce memory comsumption.
You will need Enterprise Edition and you have to give up some CPU,
but it's often worth it for huge objects.
Use the correct data types: using (n)char over (n)varchar or int when tinyint is enough will waste not only disk space, but also buffer pool space. This includes character and numeric data types: make sure you're using the right type/size/precision/scale for your data columns.