This content has been marked as final. Show 5 replies
We re-ran prvtrsch.plb and reset the password. Still given the same error. I can see that the dbms_isched_remote_access package was created in the database, and the it has references to procedures owned by the remote_scheduler_agent user. Is there any way to verify that the registration procedure is available via http? Also, I'm unsure if this makes a difference or not, but when we specify host during registration, we are using atlantic. Atlantic is our physical hardware where several databases reside. The database we want to register with is called stage and the port we set for xdb is 16021. It is the only place where this port is being used. When we register is it fine to say the host is atlantic and the port is 16021, or do we need to find a way to expose stage?
When you register the agent you must specify the physical host that the database is running on and the port that XDB HTTP server is running on and the host (physical or virtual) that the database is running on must be accessible from the agent (no firewalls in between).
It could be that you are in fact connecting to some other application by mistake.
Also did you see any errors when you reran prvtrsch.plb ? That sql file runs several commands that setup authentication and any errors could signal a problem.
Ok, we have the agent registered successfully! It looks like we have another problem now in that when running a job, it always returns invalid username or password. I went through several other posts that indicate jssu as the culprit and not having much luck as everything in our environment looks correct. Thank you for the help!
This setup enables secure communications between the database and remote Scheduler agents.
Enabling remote external jobs involves the following steps:
Setting Up the Database for Remote Job
Installing, Configuring, and Starting the Scheduler Agent
This section also contains the following topics:
Stopping the Scheduler Agent
Disabling Remote External Jobs