Out of Memory issue in Weblogic

Its one of the scary part i came across when the clients came across with out of memory error. The application was pushing around 40,000 messages to the queue and all the messages have been holded in the memory and finalyy ended up with Out of Memory exception.

There are WebLogic settings that take care of this issue. You can set the server to only load up the first N number of messages or X number of bytes to avoid OOM issues. These can be set up by going to the JMSServer config -> Thresholds and Quotas and configure bytes paging or message paging (or both).

Recommendation:
Set Bytes Threshold High to 1048576, set Bytes Threshold Low to 524288, and set Bytes Paging Enabled to true. Set Messages Threshold High to 1000, set Messsages Threshold Low to 500 and set Messages Paging Enabled
to true. This will ensure there is never more than 1 GB and no more than 1000 JMS messages in RAM.

Few forums that would help :
http://forums.bea.com/thread.jspa?threadID=570000795

Few reasons why OutOfMemory error could occur and their related solution.

1. When the producers are faster than consumers.

• Quotas can be used to help this situation. Your sender will then receive ResourceAllocationExceptions and the server will stay up.

2. Cache-related OutOfMemoryErrors.

• A very important point to consider when setting size is that the heap must be large enough to hold bean instances for all defined EJB caches.
• A possible solution for the OutOfMemoryError is to decrease so that the cache removes or passivates beans,before the JVM throws an OutOfMemoryError because the heap is full.
• Ref : https://support.bea.com/application_content/product_portlets/support_patterns/wls/InvestigatingCacheFullExceptionForEntityAndStatefulSessionBeansPattern.html
  

3. Handling the OutOfMemoryErrors.

• Message quotas prevent a WebLogic JMS server from filling up with messages and possibly running out of memory, causing unexpected results. Unless the "Blocking Sends" feature has been implemented, when you reach your quota, JMS prevents further sends with a ResourceAllocationException (rather than blocking). You can set quotas on individual destinations or on a server as a whole.
  
• The thresholds are not flow control - though they would be better suited to that application than the quotas. The thresholds are simply settings that when exceeded cause a message to be logged to the console to let you know that you are falling behind.
• WebLogic JMS also has a flow control feature that enables a JMS server or destination to slow down message producers when it is becoming overloaded. Specifically, when a JMS server/destination exceeds its specified bytes or messages thresholds, it instructs producers to limit their message flow.
• Ref : http://edocs.bea.com/wls/docs81/faq/jms.html#260519

Oracle Partitioning

The basic concept of partitioning is to divide one large table into multiple smaller units. Each of the smaller units (or partitions) can then be accessed and managed separately.
The Partitioning can be done in several ways according to the data that will be stored. They are

• Range partitioning (eg: create_date)
• Hashmap partitioning (eg: stock_id) :- equal physical split among partitions. Improves internal I/O performance.
• List partitioning (eg: south, north, etc)
• Composite partitioning (Combination of above)

Whe When partitioning the table, you need to take care of the indexes also. There are two basic types

• Local - All index entries in a single partition will correspond to a single table partition (equipartitioned). They are created with the LOCAL keyword and support partition independence. Equipartioning allows oracle to be more efficient whilst devising query plans.
• Global - Index in a single partition may correspond to multiple table partitions. They are created with the GLOBAL keyword and do not supports partition independence. Global indexes can only be range partitioned and may be partitioned in such a fashion that they look equipartitioned, but Oracle will not take advantage of this structure.

Few important terms that we need to know before partitioning the table :

• ROW MOVEMNT - automatically moves the data from one partition to another if particular data is modified.
• Eg: ALTER TABLE STT_LOG_NEW ENABLE ROW MOVEMENT;
  
• NOLOGGING - The NOLOGGING clause causes minimal redo information to be generated during the table creation. This has the following benefits:
• Space is saved in the redo log files.
• The time it takes to create the table is decreased.
• Performance improves for parallel creation of large tables.

• COMPRESS - Table compression saves disk space and reduces memory use in the buffer cache. Table compression can also speed up query execution during reads.
• To enable compression for all operations you must use the COMPRESS FOR ALL OPERATIONS clause.
• 2. To enable compression for direct-path inserts only, you use the COMPRESS FOR DIRECT_LOAD OPERATIONS clause. (default)
• SHRINK – used for memory management.

• PARTITION PRUNING – partition pruning is the skipping of unnecessary index anddata partitions or sub partitions in a query.

will be continued ...