I have a bunch of Software engineers that are complaining about the DLO Agent indexing all the file changes while they are running their intensive tests. Is there a way to keep the Agent from scanning for changes during the normal working hours? I believe that it is related to the DLO Agent Change Journal Reader scanning the changed files. I would reather not have to shut down the Agent service in the services control panel.
Your query seems to be related to the DLO agent indexing all file changes during tests.Is this causing other applications to run slowly? In case you are referring to the user bandwidth settings, you can change them. Refer to pg. 1196 of the administartor's guide. you can dowload it from the following link:
In case you problem is not the one mentioned above, you can write up in this forum. However if we do not receive your intimation within two business days, this post would be "assumed answered" and archived.
I am having the same problem with my Software group as well. The DLOchangelogSvcu.exe stays at 100% CPU. When I refresh the agent, it clears but upon the auto scan, it returns at 100%. Knowing that open files are not backed up, and these engineers use Rational Rose and have local folders to back up(with files still open at times), is it possible to to disable the Change log? I verified that my network is not the concern here.
Hi, We too suffer from the DLOClientu.exe process using excessive processor time, which makes the laptop virtually unusable. We are currently testing DLO with a view to rolling it out to our users. However if there isn't a solution to this problem, we will probably look elsewhere for a solution.
Here is a pre-released tech note that solved my problem and will help others with the same issue... Bug: When a drive or path that doesn't exist on a DLO agent is specified for backup, DLO processes take up as much as 80% or more of CPU usage. The DLOChangeLogSVCu.exe and DLOClientu.exe processes specifically will be seen consuming CPU.
Bug ID: 319077
Master Log Files: N/A
Media Server Log Files: N/A
Client Log Files: N/A
Workaround: Examine the backup selection information within the profiles for the affected machines. Identify the use of static drive letters that may not exist on some DLO Agents. For example, suppose that "d:\data" is specified as a backup selection. If this folder doesn't exist for one of the DLO Agents that use that profile, that DLO Agent will experience the CPU usage issue mentioned above. Instead of specifying an exact drive, use the %LOCALFIXEDDRIVES% macro. For example, if there is a folder called "data" at the root level, add the following entry as a backup selection: %LOCALFIXEDDRIVES%data This macro will back up paths such as c:\data, d:\data, e:\data, etc. This applies only to local fixed disk drives.
ETA of Fix: This issue is scheduled to be addressed in a forthcoming release of DLO. Another TechNote of interest is here: http://seer.support.veritas.com/docs/275960.htm and here: http://seer.support.veritas.com/docs/277986.htm