Thanks Seth and Fairlie. I read the articles and watched the video. They are
good. It's still not clear what extra information or monitoring GIMR provides
on top of what we already have. An Oracle database contains plenty of
performance information. We also have OEM to monitor it. (I also set up a job
that frequently records the output of Linux `top' command, along with
information about the non-idle sessions in gv$session including spid column in
order to correlate with my `top' output.) A quick look at the table content in
-MGMTDB does not reveal anything particularly interesting. Neither does the
output of running `oclumon dumpnodeview'. Will I lose some crucial diagnostic
data if GIMR is kept down? If so, what is that data exactly?
In 12cR2, the database takes 32 GB disk space on a 2-node RAC using external
storage, and 1 GB SGA. Its use_large_pages is the default true, unlike +ASM
where it's false. If I configure HugePages for it, I have to make HugePages 1
GB larger on this node than the other on a 2-node cluster, and when -MGMTDB
fails over, I either have to adjust HugePages again on both nodes, or waste 1
GB of memory on this node. So overall, I think it's better to not consider
-MGMTDB when configuring HugePages. In any case, I have to tolerate the
imbalance of the available memory at the OS level. 1 GB is not much, but not
negligible either.
In short, I haven't found any real use of this database. I leave it up and
running only because it's unsupported to not do so.
Yong
--
//www.freelists.org/webpage/oracle-l
