Service Operations Insight

The time shown on my CCC interface is behind by two hours when compared to the time on the server hosting the application is that normal?

The server time zone is UTC +02:00 Cairo

Hi David

Yes, this is normal.

The Local Time timestamps are stored in Data Manager along with a GMT-offset as defined in the details when specifying a datasource.  All timestamps in CCC are normalized to GMT (UTC) - this is in order to support data from multiple data centres in different time-zones in the same interface.  Also, note that another corollary of this is that Daily rollups use a GMT midnight boundary not Local Time.

As part of the product enhancements under consideration to more fully support Business Hours (eg, M-F, 08:00-18:00 or similar), there are also enhancements to allow the user to select Local Time or GMT for reporting, but this is not currently supported in the OOTB CCC reports.

Regards,

Adrian

Hi Adrian

In relation to this i have a additional question , how can we handle the time offset difference between two timezone's  during daylight saving time

In this case the timedifference is shifted one hour from 10 hours from gmt to 11 hours from gmt .     

The datasource definition does not allow us to update the timezone once it is defined ?

Any practical experience with this ?

Thanks dirk

Hi Dirk

Data Manager uses Oracle's timezone capabilities to manage Daylight Savings auto-magically.  The difference between METRIC_DATE and GMT_METRIC_DATE will change on the appropriate date.

If you want to test this out for a European-based DM instance, you could try the following query:

select distinct

DAY_DIM_ID,

HOUR_DIM_ID,

GMT_DAY_DIM_ID,

GMT_HOUR_DIM_ID,

24*(METRIC_DATE - GMT_METRIC_DATE) as DIFF

from SERVER_FACT

where day_dim_id in (20141025, 20141026)  -- European Summer Time ended at 2am 2014-10-26

and server_dim_id = NNNNN -- choose a specific server_dim_id for your environment to reduce the query run-time :-)

order by 1, 2 ;

For a US-based instance, change the values for day_dim_id in the where clause appropriately.

You should see the value for the 'DIFF' column change at 2am Local Time...

At present all CCC reports, and all CCR reports that use ENTITY_DAY_FACT / ENTITY_HOUR_FACT will all be based off GMT / UTC.  As mentioned above, there is an Enhancement Request to provide more control over this, but it is not in the current release.

Another question I would have would be what "Best Practice" should we use to manage Capacity Management tools like these for a global enterprise with servers all around the world.

The CCC/DM/CCR applications and Data Manager database need to be on servers running in the same timezone.  Otherwise scheduling data collections and reporting is confusing at best, and just won't function correctly at worst.

Should we be using UTC on both database and application servers, and then just do something to change the User Interface's "local time" setting for each user?  In that way, could they still schedule a collection or a report to run at 6:00 PM in Cairo, and have the application and database figure out what time that would be under UTC?

If we have a large Data Manager database in production with data collected as GMT-6 or CST, will we have a problem attempting to switch over to UTC for future collections done as part of a globalization project?

Thanks.

Gary

Hi Gary

A few points that I hope will be helpful:

• The 'base timezone' of the Data Manager instance is defined by the timezone specified by the supporting instance of Oracle - and as stated in the Troubleshooting Common Errors section of the Admin Guide for DM: 'The Oracle server and Tomcat server must be in the same time zone. ...'.
• Every time a datasource is defined, a 'Server time zone' is specified for that datasource instance.  It is assumed that all servers within that datasource instance are reporting from the same timezone.
• Every time a load is scheduled, the timing of the pull itself is relative to the DM application server timezone - regardless of the timezone of the datasource instance or user's desktop timezone.
• Both Local Time and GMT Time are stored on the raw FACT tables after migration.
• At present, all roll-ups for ENTITY_DAY_FACT / ENTITY_HOUR_FACT are all based off GMT / UTC, regardless of the timezone of the datasource instance.

This already provides standardisation and normalisation such that servers from data centers in different timezones can be compared side-by-side.  On the other hand, there is also a case to be made that Daily Rollups based on GMT are less than ideal for managing a data center in Texas (GMT-6) for example.  As already stated, there are Enhancements under consideration to provide the user with more flexibility in this regard.  If you have specific use cases and requirements that you would like to be included and supported, please raise them with your local CA team and/or the Ideas section of this site - these are the best ways to get your feedback and input to the Product Management team.

To your specific question, 'Will we have a problem attempting to switch over to UTC for future collections done as part of a globalization project?'  - Not if it is correctly planned and managed...    The one thing that you will have to take care of is that the timezone of a datasource instance is fixed for all time - it cannot be changed after the initial setup.  At the appropriate time, I would anticipate that the primary change you will have to make is to build a new set of datasource instances that reflect the new timezones.

Regards,

Adrian