Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I need to manually run a job on more than 150 sql server instances (sql server 2000, remote) from a sql server 2005 instance (the local server). The job is the same on all these instances. The job just calls a stored procedure without parameter, which is also the same across all the instances. These jobs are on a schedule. But now they want me to manually run the job for all the instance or for specified instances upon request.
What is the best practice for this? I have tried openrowset to call the remote stored procedure. But each run of the job takes couple of minutes, so if I use a loop to run all these jobs, it will run one by one and that's a long time. Ideally, it should be able to run the stored procedure on each instance without waiting for it to finish. More ideally, it should be able to run the job on each instance without waiting for it to finish, so it can leave a record in the job history on each instance.
And the stored procedure is from a third party so it can't be altered.
update:
since the 'people' ask this to be initialised from a SSRS report, use SSRS to call some T-SQL/proc on the server would be most appropriate. The problem I got now is when calling msdb.dbo.sp_start_job on remote SQL Server 2000 instances from local server using OPENQUERY or OPENROWSET I got Cannot following error.
process the object "exec msdb.dbo.sp_start_job #job_name = 'xxx' ". The OLE DB provider "SQLNCLI" for linked server "xxx" indicates that either the object has no columns or the current user does not have permissions on that object.
I guess this may because the sp_start_job doesn't return anything because I can use OPENQUERY/OPENROWSET to call other remote proc without problem. So any workaround?
update:
I have found it actually pretty simple in t-sql.
EXEC [linkedServerName].msdb.dbo.sp_start_job #job_name = 'test2'
So I don't need to use OPENROWSET/OPENQUERY atually since all the remote SQL Server 2000 instances are already added as remote servers.
Is this actually a SQL Agent job that calls the procedure? If so you remotely call sp_start_job which will kick off the job asynchronously. I assume you're connecting as a sysadmin to do this.
If you had SQL Server 2008 client tools you could use "Local Server Groups". If you register all 150 SQL instances you can connect to them all at once by right-clicking the entire group and selecting "New Query". Down in the status bar you'll see it connect to 150/150 servers. Then whatever command you run it will run it on all 150 at the same time.
The servers don't have to be 2008, only your client tools. I routinely use this feature on SQL 2000 servers.
Related
We have a AG Group setup for 2 server A (Primary) ,B (Secondary)
A,B have identical setup for sql agent job
A job run successful and
B job's failed in initial step when trying to access the db (Due to The target database , is participating in an availability group and is currently not accessible for queries.)
Once A failover and B become Primary. We notice a behaviour that A & B sql agent Job also running successfully, so the job run twice.
We tried to modify script in sql agent Job, by adding printing ##servername variable, we found that A & B sql agent job are also printing B(now is primary) servername. Likely 2 job are also running in B(primary) server.
The only way to resolve is currently just to restart the sql agent service. Would like to know if any other solution?
SQL server version is 13.0.5888.11
Below Issue is similar to mine, but no solution yet
[https://stackoverflow.com/questions/47433964/sql-server-ag-agent-jobs-running-successfully-on-secondary-replica][1]
The specific issue is that I want a SQL Server to connect to an Oracle database and the Oracle database has a Virtual Private Database configured. I need to execute a static stored procedure to enable the VPD to see data. How can I configure SQL Server to fire a stored procedure upon connecting to a remote database? I figure if I can fire a local stored procedure, I can put the remote stored procedure call inside of that. The key is, I need the SQL Server to fire this as soon as it is done connecting to the remote database and before it tries to pass any other queries to it. I'm trying to avoid making the applications do it explicitly.
SQL Server does not offer a solution to my problem.
However, you can setup the service account to have a logon trigger to execute what is needed.
Create Trigger My_User.Logon_Trigger_Name
AFTER LOGON
ON SCHEMA
WHEN (USER = 'MY_USER')
BEGIN
--Do Stuff Here.
NULL;
EXCEPTION
WHEN OTHERS THEN
NULL; --Consume errors so you can still log on.
END;
I have a report running against a Data Driven subscription in SSRS. The subscription runs a report and produces PDFs - about 1000 of them. The process takes about 2 minutes to complete.
I have been kicking this off manually using the following SQL:
EXEC msdb.dbo.sp_start_job #job_name = '<job_name>'
This works, but what I would like to know is when the job has finished. According to what I have read so far, I should be able to run:
exec msdb.dbo.sp_help_job
This lists my job, but it always has a status of 4 (Idle), even while I can see that reports are being produced.
How can I tell when the job has completed and all my reports have been produced?
MSDB shouldn't contain informtaion on the reporting server. The reporting server is seperate from Sql Server Management Server and will only tell you if the job ran or not not what happened in the job. If you have access to the DB I don't know how you have it set up but I have a subscriptions table that I can check with email sent and when it was sent. IF you don't have that you can go onto the reportserver web site and check the subscription and check the status and it should have a date of when it was last sent.
The only way you can access the information in Sql Server Management Studio is by queryng the DB and its tables assuming it is setup correctly.
When I am executing a select statement with 4 'inner' joins and two 'WHERE' conditions it took 13-15 s in local SSMS (I have executed 5 times). But when I connect the same instance from another server's SSMS and execute the same query it took 5 s to execute first time and then it took 0 s! I am using the same user SA.
Is there any possible explanation for that?
Host instance is SQL 2008 and Remote instance has SQL 2008 R2.
If your query is returning data to display in your local SSMS then this data needs to be transferred from the server to your local SSMS. The time to transfer the data from the server to your local SSMS is included in the execution time. So, the execution time is a combination of executing the script and fetching the data in order to display it.
You might want to "Include Client Statistics" and then review the row "Bytes received from server" in the "Client Statistic" tab of the result window.
In order to verify my assumption you can alter your select only to execute without fetching the data.
For linked servers, I see how it is possible to change the "remote query timeout" configuration to hint a call to a linked server should complete or rollback within the specific timeout value. This appears to work across the SQL Server engine--is it possible to change the hint within a stored procedure, so that a specific stored procedure could run longer if needs to, but all other non-hinted SPROCs would timeout quicker if they run long?
Linked Query Timeout is discussed here:
http://support.microsoft.com/kb/314530
Example code to set it to timeout in 3 seconds is here:
sp_configure 'remote query timeout', 3
go
reconfigure with override
go
Not really advisable to change it within a stored procedure. remote query timeout is a global server setting when altered with sp_configure, so changing it in a stored procedure affects all remote queries for all linked servers on the server.
Additionally, executing sp_configure requires the ALTER SETTINGS server permission, which typically only sysadmin and serveradmin have. Granting these permissions to a data access account would be a security concern since they could potentially take your server down with sp_configure commands.
What I would suggest is creating a second linked server with a different name that you would use with just this one stored procedure. You can, in SSMS, configure a query timeout for each individual linked server. Adding a second linked server would enable you to query the same server with different linked server client settings. You might need to create a DNS CNAME to accomplish this if you're using plain SQL Server Linked Servers.