Metrics Global Cache Blocks lost is at 11

Undesirable Global Cache Statistics
The following are undesirable statistics, or statistics for which the values should always be zero or near-zero.

global cache blocks lost--

This statistic reveals any block losses during transfers and high values may indicate network problems. When using an unreliable IPC protocol such as UDP, the value for 'global cache blocks lost' may be non-zero. If this is the case, then the ratio of 'global cache blocks lost' divided by 'global cache current blocks served' plus 'global cache cr blocks served' should be as small as possible. A non-zero value for 'global cache blocks lost' does not necessarily indicate a problem, because Oracle retries the block transfer operation until it is successful. Unlike TCP/IP, UDP/IP is considered unreliable because UDP/IP provides very few error recovery services.

global cache blocks corrupt--

This statistic indicates whether any blocks were corrupted during transfers. High values for this statistic indicate an IPC, network, or hardware problem. "

Getting "Reached maximum capacity of pool" messages in logs

Issue: Unable to login to Oracle VM Manager. Getting the following error:

Error in the Admin Server Log:

####<2015-02-28T08:52:55.833+0530> <Info> <Common> <servername> <AdminServer> <Odof Tcp Client Thread: /127.x.x.x:54321/2795858> <<anonymous>> <> <1b95d8d1-24dd-4acc-a6f3-4c025158e6a7-000000
03> <1425093775833> <BEA-000627> <Reached maximum capacity of pool "poolname", making "0" new resource instances instead of "1".>
####<2015-02-28T08:52:55.896+0530> <Error> <com.oracle.odof.core.storage.RelationalStore> <servername> <AdminServer> <Odof Tcp Client Thread: /127.x.x.x:54321/2795865> <<anonymous>> <> <1b95
d8d1-24dd-4acc-a6f3-4c025158e6a7-00000003> <1425093775896> <BEA-000000> <Waiting for connection (7 of 720 tries)>
####<2015-02-28T08:52:58.446+0530> <Info> <Common> <servername> <AdminServer> <Odof Tcp Client Thread: /127.x.x.x:54321/2795898> <<anonymous>> <> <1b95d8d1-24dd-4acc-a6f3-4c025158e6a7-000000
03> <1425093778446> <BEA-000627> <Reached maximum capacity of pool "poolname", making "0" new resource instances instead of "1".>
####<2015-02-28T08:52:58.469+0530> <Error> <com.oracle.ovm.mgr.api.exception.FormatException> <servername> <AdminServer> <[ACTIVE] ExecuteThread: '5' for queue: 'weblogic.kernel.Default (sel
f-tuning)'> <<anonymous>> <> <1b95d8d1-24dd-4acc-a6f3-4c025158e6a7-00293343> <1425093778469> <BEA-000000> <com.oracle.odof.exception.TimeoutException: Receive timed out - timeout value(30000)

Solution:

1. Log into the Weblogic console: https://:7002/console. The username should be 'weblogic' and the password should be the same one used to log into the manager.

2. Go to Services --> Data Sources --> ovm-odof-ds --> Monitoring. Click on "Customize this table." Add the following columns to the table: 'Leaked Connection Count', 'Active Connections Current Count', 'Active Connections High Count'.
3. Go to Services --> Data Sources --> ovm-odof-ds --> Connection Pool --> Advanced. Set the "Inactive Connection Timeout" field to 30, and save.

4. Go to Services --> Data Sources --> ovm-odof-ds --> Diagnostics. Check "Profile Connection Leak" and save.

5. Click on "Activate Changes" on the left so that all the config changes take effect.

6. Continue using the manager. Now, weblogic should close any inactive connections that are still open.

7. Go to Diagnostics --> Log Files. View the DataSource log. Information here could help us figure out if the manager is leaving connections open.

Also, as a precaution and to avoid this issue in future, you can increase the maximum capacity of connections for the pool. To do that, follow steps below:

a. Login to Weblogic console
b. Navigate to Domain Structure -> Services -> Data Sources -> -> Connection Pool >> Maximum Capacity
c. Increase the parameter "Maximum Capacity" of the connection pool (If it is 1, increase to 100)