I am currently experiencing issues with DM and CCC. Below are the issues:
These two issues don't seem to report any errors in the logs and even the DB does not report and issues errors. casupport seem to think that this could be a networking problem that's causing these issues and have suggested that we implement network monitoring to see if there could be something going on during the transaction times. But now my question is what exactly do i need to look at?
I'm thinking of building a new VM and install CCC there and then connecting it to the DB and see if I will still experience the same issues. When doing this new install will I only need to install the WebServer and not the Schema as that was done when installing the existing Application?
Please provide any other suggestion if you have on how I can tackle this.
Couple of observations.
1. Disk data can generate HUGE amounts of data, especially on *nix servers. What is your requirement for collecting this data? The OOTB reports don’t leverage per disk data. I would recommend reviewing if this data is really needed.
2. Basic question, is there a reason you cannot just connect to VMware every day instead of every other?
Sr Principal Consultant, Presales
1. I'm not really sure if the data is needed as from where i'm standing the data is just gives us the storage rate of utilisation and not how much is available and how much is used from an eHealth Data Source perspective.
2. There was instance where when I was pulling data daily from the vCenter, for some reason the TempDB space was filling up on the vCenter DB and after resorting to pulling data every second day seemed to resolve the issue.
If the TEMPDB was filling up on the Vcenter DB there is a parameter that you can change to have it pull in smaller chunks.
Data Manager pulls in a list of servers, you can set the number of servers it pulls in with each “chunk”.
Under Configuration Settings, Global Parameters:
Numbers of entities in an iteration to collect data from a database
The default value could be set very high, you should always pull in the last 24 hours each night.
To adjust the size of the pulls change this “DB_ENTITY_BUCKET_SIZE” to a smaller value.
Principal Services Consultant
The application is currently set to 100.
1. The eHealth data source does not provide the total disk throughput value that CCC leverages. You are correct in that all the eHealth disk metircs are % disk busy, not how much bandwidth is used or total space used.
I would recommend not collecting disk metrics from eHealth.
2. Clarification, you can and should use the 'weekly' VMware data adapter and not use the 'daily'. BUT what I am recommending is to use the 'weekly' data adapter (DA) but schedule it to run 1x per day.
The 'Daily' and 'Weekly' data adapter names are referring the the vCenter database metric rollup table that is queried.
The 'Daily' DA pulls data at 5 min increments and is stored in the vCenter DB for 24 hours. The 'Weekly' DA pulls data at 15 minute increments which are stored for 7 days. This means that for the same time period the daily DA will pull 3x the rows as the weekly.
So again, use the Weekly DA and schedule it to run 1x per day.
And thanks for the response. I am currently not collecting the disk metrics data from the eHealth as it eliminated the problem. Regarding the VMware data, I am using the Weekly Data Adapter.
TEMPDB space issue... could be fixed by setting the value of 100, down to 50, or 25.
And stage data ever 24 hours.
Then double check the Migration Performance Reports, and check the rows/sec in staging and the duration.