EducationSoftwareStrategy.com
StrategyCommunity

Knowledge Base

Product

Community

Knowledge Base

TopicsBrowse ArticlesDeveloper Zone

Product

Download SoftwareProduct DocumentationSecurity Hub

Education

Tutorial VideosSolution GalleryEducation courses

Community

GuidelinesGrandmastersEvents
x_social-icon_white.svglinkedin_social-icon_white.svg
Strategy logoCommunity

© Strategy Inc. All Rights Reserved.

LegalTerms of UsePrivacy Policy
  1. Home
  2. Topics

KB38144: MicroStrategy Enterprise Manager scheduled data loads do not run even when the MicroStrategy Enterprise Manager data loader service is running.


Community Admin

• Strategy


SYMPTOM
Strategy Enterprise Manager 9.4.x scheduled data loads do not start even when the Strategy Enterprise Manager data loader service is running.
 

ka04W000000Oeo0QAC_0EM440000002AYB.jpeg

 
The data load service is running under an administrator account and the DCOM permissions are set correctly for the user. The schedule definition is defined correctly on the console. Also, it is seen that there are previous data load processes running on the machine. Windows task manager shows that there are no existing MAEMETL.exe processes.
 
The MSTRMigration logs show that a data load is not even initiated at the expected time.
 
CAUSE
One of the possible causes for this issue can be a previously failed scheduled data load caused by system failure, for example, Enterprise Manager machine going down or process killed using windows task manager. In this case, the values of the Windows registry keys which store information about the scheduled data load can look like below:
 

ka04W000000Oeo0QAC_0EM440000002AYO.jpeg

 
The LoadStart key indicates the timestamp at which the last data load process started. This need not be the timestamp corresponding to a successful data load.
The LoadFinish key indicates the timestamp which the last data load finished. This can be an unsuccessful or a successful data load.
The LastSuccess key indicates the timestamp at which the last successful data load started.
 
As seen from the values in the screenshot above, a successful dataload started on October 6th 2011 at 2:00PM. The start time of the last data load process is on October 6th 2011 at 3:30PM as per the LoadStart key. This data load process did not finish successfully. If this process was successful, the LastSuccess timestamp would have been the same as the LoadStart time.
 
When the values of the key are in this state, it is seen that the next scheduled data load does not kick off.
 
ACTION 
In the more common cases of data load failure, where a scheduled data load fails because of some error message from the database or other generic errors, this issue is not seen. The registry in that case is seen as below. The LoadFinish key indicates the timestamp at which the last (unsuccessful) data load ended and not the timestamp of the last successful data load:
 

ka04W000000Oeo0QAC_0EM440000002AYN.jpeg

 
 
An issue has been logged to fix the issue that the next scheduled data load does not kick off in the case of a previous data load failure because of system failure or abrupt termination of process.
 
WORKAROUND
Implement the following workaround to fix the scheduled data load.
 
Open the Windows registry and blank the values of the keys: LastSuccess, LoadFinish and LoadStart in the following registry location:
 


HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\MicroStrategy\Enterprise Manager\Schedule

 
After this change, the next scheduled data load will kick off at the required time.
 
Registry Modification:WARNING:
Modifying registry values incorrectly may cause serious, system-wide problems that may require the re-installation of Microsoft Windows NT. Any edit of the registry is done at the user's own risk. Since these are user-initiated changes, they are not covered by any Strategy warranty. If using Microsoft Windows NT, the user should backup the registry and/or update an Emergency Repair Disk (ERD) prior to alterations.
 
 
 
 


Comment

0 comments

Details

Knowledge Article

Published:

June 5, 2017

Last Updated:

June 5, 2017