Managed Server is Not coming UP from STARTING state

Question

Managed Server is Not coming UP from STARTING state

Answer 1

Hi,
Please try the following options:
1) Apply -D_Offline_FileDataArchive=true
The WebLogic Diagnostics Framework creates the diagnostic store (DAT) file which is used for different purposes. The initial size of the store file is about 1M.
Here are the details of the parameter suggested: -D_Offline_FileDataArchive=true
The above parameter is a (undocumented and unsupported) system property that disables WLDF indexing on the log file.
Engineering has delivered an undocumented system property to disable the file archive indexing task (-D_Offline_FileDataArchive=true),
This property will disable incremental as well as full indexing of WLDF archiving, if property is not properly applied, you can see a File Indexer timer kicks in for every 30 seconds.
2) WLW page-flow event reporter may be creating several entries in the diagnostics store
apply -Dcom.bea.wlw.netui.disableInstrumentation=true
3) Disable JDBC profiling. (Under JDBC/datasource_name/diagnostics uncheck all the options there)
If JDBC profiling is turned on, it inserts profiling data into the diagnostic store, which can cause it to grow.
4) Disable Harvesting (change the value for Profile Harvest Frequency Seconds to zero)
5) try setting the "synchronous-write-policy" parameter in the server configuration to "Cache-Flush". This bypasses the "direct I/O" code in the file store.
Servers--->Configuration--->Services--->Default Store you can set the synchronous-write-policy to Cache-Flush
Synchronous Write Policy:
The disk write policy that determines how the file store writes data to disk.
This policy also affects the JMS file store's performance, scalability, and reliability. The valid policy options are:
* Direct-Write
File store writes are written directly to disk. This policy is supported on Solaris, HP-UX, and Windows. On Windows systems, this option generally performs faster than the Cache-Flush option writes.
* Disabled
Transactions are complete as soon as their writes are cached in memory, instead of waiting for the writes to successfully reach the disk. This policy is the fastest, but the least reliable (that is, transactionally safe). It can be more than 100 times faster than the other policies, but power outages or operating system failures can cause lost and/or duplicate messages.
* Cache-Flush
      Transactions cannot complete until all of their writes have been flushed down to disk. This policy is reliable and scales well as the number of simultaneous users increases.
HTH
Regards
RC2
http://crkthoughts.blogspot.com