I would use sga_target and sga_max_size instead and bump up the memory. Is this DB the only thing running on the server? A lot of the others are dependent upon your system - see notes:

*.db_block_size=8192 - standard size, good for OLTP not for Data Warehouse (usually)
*.db_cache_size=1024M - replace with sga_target. Keep if you want a minimum size for the db_cache.
*.db_files=128 - file number dependent
*.fast_start_mttr_target=300 - depends on how quickly you want to recover from an instance crash. lower number = more disk I/O & longer to recover
*.hash_area_size=1048576 - remove in favour of pga_aggregate_target
*.java_pool_size=536870912 - remove unless specific reason for min value
*.job_queue_processes=10 - depends how many jobs you want running from a scheduler?
*.large_pool_size=16777216 - remove unless specific reason for min value
*.nls_length_semantics='CHAR'
*.open_cursors=1300 - application specific
*.optimizer_features_enable='10.2.0.4' - depends if you have tested your App with 11.2.0.3 or wnat any of the features from the 11g optimizer
*.pga_aggregate_target=1409286144 - increase if more sorting required or using shared server
*.processes=255 - application specific
*.remote_login_passwordfile='EXCLUSIVE'
*.sessions=286 - I don't think this can be higher than the number of processes? Should be the other way around because of Oracle background processes
*.shared_pool_size=5G - why do you have a 5G shared pool and only a 1G db cache?
*.sort_area_size=1048576 - remove and let pga deal with it. Might even be ignored. Look in docs.
*.Standby_File_Management='AUTO' - do you use data guard?
*.timed_statistics=TRUE
*.transactions=315
*.undo_management='AUTO'
*.undo_retention=10800

I've removed a few that I would not set and added the SGA ones in there, and increased the PGA. Like I said in the notes above next to each parameter, a lot of them are system dependent so you need to decide what to set them to. If you DB is only 10GB then having an SGA of 24GB is not necessary. And it depends if there are performance issues with a small cache and it would benefit from increasing the size.

Be careful when changing them and don't do it straight on a PROD DB without carefulling considering the implications and having a way to back out the changes. Take a copy of your SPFILE or INIT.ora file before you make any changes. Some of them will require a database restart.

You should have a look at creating an [url http://www.ora00600.com/articles/oracle-awr.html]AWR report for the DB during peak load hours and see what the top wait events are.

I also said to look if performance is a problem and it would depend on the size of the DB.

Using AMM is a definite change which should be made as all those manually configured pools are not ideal and give no flexibility to react to a change in workload.

If there is no information to base the decision on, start with the recommended approach and what experience has shown you is a good configuration on other systems and work from there. It's an iterative process, and I agree that if it ain't broke don't fix it but some of those parameters - the ones I said to change - should be changed. I added the caveat that there is no point increasing the memory if it's not needed.

I would say that rather than looking at the parameters or looking for parameters to tune the database, it's better if you check the AWR or Statspack report after hearing a cry from the users of yours and then try to find an issue and it's solution. As stated already in the thread, rather than going for the parameters for Buffer Cache, Shared Pool, it's better to switch over to AMM which is a better alternative in 11g compared to ASMM of 10g.

I could be wrong but I thought that huge pages was something for a Linux server? Just like large pages is for Windows. It's nothing to do with the SGA and PGA, just how the OS assigns memory segments of RAM. The OS doesn't know if you are using SGA, PGA or any other memory configuration it just allocates the memory that is requested from the Oracle instance. The idea behind it being that if you are allocating hundreds of GBs of memory then you want large chunks of RAM contiguously rather than thousands of small pieces.

Here is a little more about using [url http://www.ora00600.com/scripts/databaseconfig/large_pages.html]large pages on Windows