Data Mover currently uses ARC, TPTAPI and JDBC to extract data from a source system and load data to the target system. Based on different scenarios, Data Mover may choose to use one of the 3 mentioned load utilities.
When copying data from source to target, the user provides the login information for the source and target systems as part of the job definition that is used to login to the source and target systems to extract/load the data. There are certain limitations in providing the login information for each job that is executed:
Same user already logged in to dbs". This prevents multiple ARC jobs to run at the same time using the same target user.
In order to resolve these issues, a feature to support a pool of users was designed.
When using this feature, the user does not provide the target user name and password when executing the Create/Move command. Data Mover selects the target user from the pool of target users instead that is saved using the
save_configuration command. When multiple ARC jobs are run at the same time, Data Mover checks if a particular user in the pool is already being used by an ARC task and allocates an alternate available user to other ARC tasks. This way each ARC task logs in to the target system with a different user, thus avoiding the "
Same user already logged in to dbs" error. For TPTAPI/JDBC jobs, Data Mover may choose the same target user for 2 or more jobs being run at the same time since there is no problem with multiple users being logged in to a target system at the same time when using those utilities.
The System Admin needs to set up a pool of target User IDs using the configuration file. To do this, run the
list_configuration command first to get all of the configuration properties. There is a property called
job.useUserIdPool that defaults to
Add target users to the pool as:
<description>Purpose: Use a target user from the pool of users. This enables running multiple arc tasks at the same time</description>
The above XML adds 2 target users to the pool for system
Grenach and one target user to the pool for system
Poplin. Unless the value is set to
true, the pool of user IDs will not be used by any Data Mover job.
Note: ARC users can also be added to the pool through the Data Mover admin portlet.
Passwords can be provided as plain text or in encrypted format. Providing both will result in an error when trying to save the configurations. Providing no username/password when the value for this property is
true will also result in an error when trying to save the configurations.
Save the configuration properties using the
Once the pool of users has been saved, a job can be run using the user pool by specifying
<use_userid_pool> in the job definition. E.g.
Trying to provide the target user/password when
true results in a create time error. If
<use_userid_pool> is set to false then the user will have to provide a target user name and password.
Also, if the value for
job.useUserIdPool was set to false when saving the configuration properties then trying to use the target User ID pool will result in an error.
<use_userid_pool> is set to
true, Data Mover will chose a target user from the target User ID pool. If multiple ARC jobs are being run at the same time with
true, then Data Mover chooses an available target user from the pool that is not already being used by other ARC jobs. This way multiple ARC jobs can run at the same time.
For TPTAPI/JDBC jobs, Data Mover may choose the same target user for 2 or more jobs being run at the same time since there is no problem with multiple users being logged in to a target system at the same time when using those utilities.
When running ARC jobs with
<use_userid_pool> set to
true, if all target users in the pool are already being used by other ARC tasks then the ARC task waits for other ARC tasks to complete and return the user to the pool. Once the user is available in the pool the waiting ARC task uses that particular user.
When running an ARC job with
<use_userid_pool> set to
If a user in the pool is being used by another ARC job that does not use the User ID Pool (i.e. the target user was specified in the XML file), then
that user is not chosen from the pool. An alternate user is chosen or if no users are available in pool, the ARC job waits until a user is available.
When running an ARC job that DOES NOT use the User ID pool:
Error: Target user is present in the user ID pool and is currently being used by another ARC job. Please try running the job later.
All target users in the target user pool (
config_user_pool table) are marked as available every time the Data Mover Daemon is restarted or the
job.useUserIdPool configuration property is modified.
Note: The user pool is only for target users. ARC does not have any restriction with same users logging in to the source system at the same time. Therefore, Data Mover does not use a user pool for source users.
When the System Admin saves a configuration file containing a pool of users, the users and encrypted passwords are stored in the repository table called
config_user_pool. This table can be used to view all the users in the pool that are currently being used and other users that are available.
Note: Every time a user from the pool is consumed by an ARC Task, the user is marked as
unavailable in the
If users in the pool were used up by multiple ARC jobs and the ARC processes were manually killed or the Agent was abnormally shutdown, then users may not be returned to the pool. Restarting the DM Daemon or re-saving the DM configuration properties (
save_configuration command) would return all the users back to the
available state. If this happens then make sure that all ARC processes have been terminated as well. If the stale ARC processes have not been terminated then trying to login as one of the users in the pool may result in the "
Same user already logged in to dbs" error.
Our Data mover(DM) jobs are using a pool of users for data mover arcmain and tptapi. Assume a scenario , DM has launched multiple tptapi sessions with username "john"(avalable from the user pool). Now another DM job runs in parallel and launches a arcmain, is there a possibility of DM job launching arcmain to pick up "john"? or will it up other pool of users available?
We are getting frequent "same user logged on to the dbs error" and most of the DM jobs using arcmain complete. We are not able to find any idle sessions from the same arcmain user while we check history on viewpoint using rewind.
When ARC jobs are run simultaneously with TPT jobs, then the ARC jobs can use the same user from the pool as the TPT jobs. This is OK becasue the "same user logged on to the dbs error" only occurs when 2 ARC jobs are logged in to the target system usign the same user.
Its hard to say what is causin the "same user logged on to the dbs error" error but here are a few reasons :
1. Maybe there is another ARC process outside of datamover (maybe a standalone arc process) that is logged in using one of the same user from the pool. DM does not validate if same users are logged in using a NON-DM application.
2. Maybe the user ID pool is in a bad state. High highly doubt this is the issue but restarting the DMDaemon should fix this issue.
Please make sure there are no orphaned ARC sessions on the TARGET system which could be causing this issue.
Thanks Jaison..We are trying to find out the stale archive session. Is there a table on the data mover side either on the DB or on the DM application side to check the assigned and unassigned pool of users?
You should check for stale sessions on the COPY (target)side. Same ARC users being logged on to the source system will not give you the same user logged on to the dbs error" error.
Same ARC users logged on to the target system will give you that error. YOu can use view point to check if same users are logged on to target system. Did you try restarting the DMDaemon service just incase ?