Home -> Mailing Lists -> Oracle-L -> Re: CPU rounding

Re: CPU rounding

From: Gerry Miller <gerry_at_millerandbowman.com>
Date: Fri, 18 Nov 2011 06:22:50 +1000
Message-ID: <4EC56D1A.1030001_at_millerandbowman.com> 



 


Thanks Joel. Are those databases on the same server, or at least on the same
Solaris version?  It could be either the database release or the OS version
that is at fault.



Joel.Patterson_at_crowley.com[1] wrote: column value format
999999999999.999999999999 I get 4 zeroes before the decimal on 11.2.0.1
251290000.000000000000 I get 0 zeroes before decimal on 10.2.0.4
56729894.000000000000 Joel Patterson Database Administrator 904 727-2546
-----Original Message----- From: oracle-l-bounce_at_freelists.org[2]
[mailto:oracle-l-bounce_at_freelists.org[3]] On Behalf Of Gerry Miller Sent:
Thursday, November 17, 2011 4:13 AM To: gerry_at_millerandbowman.com[4] Cc:
Oracle-L Group Subject: Re: CPU rounding Hi I hate to bang on about this but
I am no nearer to a solution. We have 3 Solaris 10 boxes running 11.2.0.2
Enterprise Edition and the problem exists on all 3 and I would like to ask
anyone with the same configuration out there to run: SELECT value FROM
v$sess_time_model WHERE stat_name = 'DB CPU'; and tell me if the results are
rounded to centiseconds, that is, all end with 4 zeroes. Thanks Gerry Gerry
Miller wrote: Hi, Can any one help me get to the bottom of this? We have two
Solaris servers one hosting Oracle 10.1 and the other 11.2. The CPU stats on
the 11g box are rounded to centiseconds while on 10g they are
inmicroseconds:Example: In 11g: select value from v$sys_time_model where
stat_name = 'DB CPU'; VALUE ----------- 27089090000 In 10g: select value
fromv$sys_time_model where stat_name = 'DB CPU'; VALUE -------------
1373214613234 It is the same in v$sess_time_model and I suspect it is an OS
setting that isat the root of the issue. Regards Gerry Miller --

http://www.freelists.org/webpage/oracle-l[5] --
http://www.freelists.org/webpage/oracle-l[6] --
http://www.freelists.org/webpage/oracle-l[7] 






Received on Thu Nov 17 2011 - 14:22:50 CST












Original text of this message