Running Stored Procs on Different Databases through Agent Job - sql-server

I have a list of three stored procedures that need to be ran daily on a number of separate SQL databases. Each database is named differently, but the stored procedures on each are the same.
I have extremely limited knowledge on anything other than basic queries, but was thinking I could have a SQL Server Agent job on a database I set up as Master. Then I have that server push that job to the other databases once I configure those as Targets. My issue is that in thinking through this, the database names are different and within the SQL Server Agent wizard I can only set the database to what's currently on master instance.
What would be the best approach to executing this looping through servers to run the stored procs?

What you're looking for is a linked-server. They allow servers to be linked so that you can call objects from one server to another. They are very easy to setup. In your case, you'll need to create 3 linked-servers on the main server, which will be used to schedule the job. A linked-server will allow the main server to link to listed servers. Here are tutorials of how you can create a linked-server.
Once you've created a linked-server you'll simply create a job that will execute all 3 sprocs, something like this:
EXEC [server1].[database].[schema].[sp_name];
EXEC [server2].[database].[schema].[sp_name];
EXEC [server3].[database].[schema].[sp_name];

Related

Does a Stored Procedure calling a SQL Agent Job have to reside on the same server?

I would like to create a stored procedure that calls a SQL Agent job, which will in turn call an SSIS package. The job and the SSIS package will reside on the same database server. However, I would prefer that the stored procedure resides on a different database server. The reason behind this is that we have an app that will be calling the sproc. I don't want to give it access to the database where the SQL Agent job and SSIS package reside.
How would I go about doing this?
In a different database in the same instance is very simple. Just use a doted name (db_name.schema_name.object_name).
In a different instance, you must create a linked server and use a doted name like :
instance_name.db_name.schema_name.object_name

How to execute a stored procedure present in database A/Server A and query database B/Server B as well?

I have a configurations database with a lot of stored procedures and then I have a large number of databases, all are part of one system and on the same database server.
When the stored procedures in the config database are executing, they often query other databases as well and it is possible to do so because the configuration and all the other database are on the same database server.
But with time, as the data is growing, customers are growing, databases are growing, this one database server is slowing down. So now we want to take some of our databases and put them on a different database server but we are unable to do so because these databases and the configuration database are tightly coupled to each other because many of the stored procedures in the config database query other databases as well.
Is there some way I can execute a stored procedure present in config database / Server A, but this stored procedure is also querying database 2 on Server B?
If not then what could be the best approach to decouple all the other databases from the configurations database? I know getting rid of the stored procedures by implementing an ORM or something could be an option but that would be very time taking as we 1000+ stored procedures.
Let's say your configure database is Server A and all your user databases are on Server A and your SP are using 3 part naming to query multiple databases.
Now you want to migration one of the databases (DB1) to Servers B. Now DB1 does not exist on Server A, it is now on Server B. You can then Create a place holder DB on Server A called DB1. Then you will create a linked server to Server B and in the Place holder DB1, you will create alias which uses the linked server object with the same table name. This way, no changes is required on your thousands of SP and its configuration.
However, Linked Server may introduce performance problems as joining and indexing is less efficient.

SQL Server 2008 R2 - Running a Stored Procedure against Linked Servers

I am trying to create a SQL Job that sits on what I like to call a Maintenance Server where details about all the other server databases sit. So I have a stored procedure to gather all the required data I have and this stored procedure is now in MaintenanceServer.MaintenanceDB.pr_MyProcedure.
Now what i'd like to do this is. I am creating Linked Servers on my MaintenanceServer which points to all the other Servers I'd like to maintain. Next on my list is to be able to run this procedure pr_MyProcedure against all those LinkedServers. I have over 25 servers to maintain and what i want to do is to run the procedure against them and insert the result to my local MaintenanceDB.
Can someone point me to a good way to do this? Also i'd like to hear the drawbacks of this method.
Thanks and Cheers!
EDIT:
I was also thinking about storing the SP on all the master databases of my other Servers and running them remotely on my Maintenance Server. Then i'll use OPENQUERY() to gather all the results that I need. However, I don't think I want to touch all the master databases on my server list. Please tell me if this would be better than the once I stated above.
The nice way to do it is run the SP on the target server, as that's nicely modular. If you want to query the remote server, it's going to be more painful. I'm not sure whether the undocumented sp_foreachdb deals with linked databases, if not you are down to dynamic sql.
As in build a string and call it with Exec(#somesql), that will need to deal with the results itself, as any variables will only be in scope inside the exec.
Personally I'd consider inverting all this. Have each server call it's own SP and the call an SP on the maintenance box to store the results.
EXEC [RemoteServer] .DatabaseName.DatabaseOwner.StoredProcedureName
‘Params’
Example:
EXEC [RemoteServer] .DatabaseName.DatabaseOwner.StoredProcedureName ’PramValue’

Creating a snapshot database to another SQL Server

I'm trying to save the values of several columns of one table to another table on a different server. I am using SQL Server. I would like to do this without running external programs that query from this database and insert the results into the new database. Is there any way to do this from within the SQL Server Management Studio?
This is a recurring event that occurs every hour. I have tried scheduling maintenance tasks that execute custom T-SQL scripts but I'm having trouble getting the connection to the remote server.
Any help would be appreciated.
If you can set up the remote server as a linked server you should be able to configure the SQL Server Agent to execute jobs that contain queries that access tables on both the local and linked server. Remember that you might have to configure the access rights for the account used to run SQL Server Agent so that it has permissions to read/write tables on both servers.
This practice might not be without issues though as this article discusses.
You can use a 4 part name like;
INSERT [InstanceName].[DatabaseName].[SchemaName].[TableName]
SELECT * FROM [SourceInstanceName].[SourceDatabaseName].[SourceSchemaName].[SourceTableName]
But first you will have to set the remote server as a linked server as so;
https://msdn.microsoft.com/en-us/library/aa560998.aspx

Call a sproc from another sproc on a different machine

I am using SQL server 2000.
I have a stored procedure sitting on machine A. I want to call this stored procedure from within a stored procedure on machine B. How do I go about this?
You could use the Linked Server feature of SQL Server.
A linked server configuration allows
Microsoft SQL Server to execute
commands against OLE DB data sources
on different servers. Linked servers
offer these advantages:
Remote server access
The ability to issue distributed
queries, updates, commands, and
transactions on heterogeneous data
sources across the enterprise.
The ability to address diverse data sources similarly.
A call could look like this:
exec MyRemoteServer.MyDB.dbo.sp_MyStoredProc
Read this blog post. Essentially, if the server is already set up as a linked server you can use EXEC RemoteServer.DatabaseName.DatabaseOwner.StoredProcedureName

Resources