Remote queries using sp_executesql run inconsistently

This one has stumped me!
I recently implemented a process to monitor database usage and growth
on our production servers. I use on server as the "master" that
collects data from all the other servers into one database. The
problem I'm having is that only every other day the process completes
after having successfully collected data from all servers. On the
alternate days, only data from the "master" server is collected. I've
used some debugging code to determine that my process is successfully
communicating with each server each day, but I can reliably plan on the
every-other-day behavior.
I apologize if this explanantion is too vague. Here is some code...
This is the SP on the "master" server that contacts all the other
servers and collects the data (this is within a cursor that loops
through the list of server names as stored in a local table):
-- Creates the generic linked server
select @.svrlgn = lower(left(@.svr_nm, @.svr_nm_len))
exec sp_addlinkedserver 'MSSQL', '', 'SQLOLEDB', @.svr_nm
exec sp_addlinkedsrvlogin 'MSSQL', 'false', null, @.svrlgn, @.svrlgn
exec sp_serveroption 'MSSQL', 'rpc', 'true'
exec sp_serveroption 'MSSQL', 'rpc out', 'true'
set @.sqlstr = 'insert into temp_drives (DriveLetter, MBFree) exec
MSSQL.master..xp_fixeddrives; update temp_drives set ServerName = ''' +
@.svr_nm + ''' where ServerName = ''new'''
execute sp_executesql @.sqlstr
set @.sqlstr = 'exec master.dbo.mjr_GetDatabaseSize_Data'
execute MSSQL.master.dbo.sp_executesql @.sqlstr
-- clean-up
exec sp_droplinkedsrvlogin 'MSSQL',null
exec sp_dropserver 'MSSQL'Still reviewing your code, but just wondering why are you adding and
dropping links to the remote servers each time you run the job? Why not
just permanently link the servers?
Will get back to you on the rest when I can review your code in more detail.
Thx
"vogelm" <vogelm@.discussions.microsoft.com> wrote in message
news:1B4E5251-D928-4156-A19D-41F24C745456@.microsoft.com...
> This one has stumped me!
>
> I recently implemented a process to monitor database usage and growth
> on our production servers. I use on server as the "master" that
> collects data from all the other servers into one database. The
> problem I'm having is that only every other day the process completes
> after having successfully collected data from all servers. On the
> alternate days, only data from the "master" server is collected. I've
> used some debugging code to determine that my process is successfully
> communicating with each server each day, but I can reliably plan on the
> every-other-day behavior.
>
> I apologize if this explanantion is too vague. Here is some code...
>
> This is the SP on the "master" server that contacts all the other
> servers and collects the data (this is within a cursor that loops
> through the list of server names as stored in a local table):
>
> -- Creates the generic linked server
> select @.svrlgn = lower(left(@.svr_nm, @.svr_nm_len))
>
> exec sp_addlinkedserver 'MSSQL', '', 'SQLOLEDB', @.svr_nm
> exec sp_addlinkedsrvlogin 'MSSQL', 'false', null, @.svrlgn, @.svrlgn
> exec sp_serveroption 'MSSQL', 'rpc', 'true'
> exec sp_serveroption 'MSSQL', 'rpc out', 'true'
>
> set @.sqlstr = 'insert into temp_drives (DriveLetter, MBFree) exec
> MSSQL.master..xp_fixeddrives; update temp_drives set ServerName = ''' +
> @.svr_nm + ''' where ServerName = ''new'''
>
> execute sp_executesql @.sqlstr
>
> set @.sqlstr = 'exec master.dbo.mjr_GetDatabaseSize_Data'
> execute MSSQL.master.dbo.sp_executesql @.sqlstr
>
> -- clean-up
> exec sp_droplinkedsrvlogin 'MSSQL',null
> exec sp_dropserver 'MSSQL'
>|||We would prefer not to leave permanent linked servers out our servers if not
for a specific database or purpose; we've found that developers can sometime
s
abuse them. Also, the dynamic nature of the script allows us to add and
remove servers from the process more easily.
Thanks for reviewing my code. I look forward to your feedback!
"Michael C#" wrote:

> Still reviewing your code, but just wondering why are you adding and
> dropping links to the remote servers each time you run the job? Why not
> just permanently link the servers?
> Will get back to you on the rest when I can review your code in more detai
l.
> Thx
> "vogelm" <vogelm@.discussions.microsoft.com> wrote in message
> news:1B4E5251-D928-4156-A19D-41F24C745456@.microsoft.com...
>
>|||Nothing's jumping out at me, other than you're not fully-qualifying all of
the tables (i.e., temp_drives). Are you seeing anything in your Event Logs
on either the local computer or remote linked servers? My best guess would
be a security/login failure on the remote machine, but you'd have to check
the logs for that. Could be that the commands are timing out, for instance
if you're running intensive operations every other day like backups and
index rebuilds, etc. Look for any other activities that are occurring on
your server on days of failure. It might end up just being a case of
scheduling the job to run earlier or later in the day.
There might be additional info in the SQL Server Logs (under "Management" in
EM).
Let me know if you see anything in your logs.
"vogelm" <vogelm@.discussions.microsoft.com> wrote in message
news:B4EDC587-A45D-4FBE-9F28-F3C2FE46A7E1@.microsoft.com...
> We would prefer not to leave permanent linked servers out our servers if
> not
> for a specific database or purpose; we've found that developers can
> sometimes
> abuse them. Also, the dynamic nature of the script allows us to add and
> remove servers from the process more easily.
> Thanks for reviewing my code. I look forward to your feedback!
>
> "Michael C#" wrote:
>|||No, nothing in the event logs. The security is set up correctly. It could
be a timeout issue, but I would assume that I'd receive an error message in
that case.
Also, there are no other long-running jobs during this time, and no
processes that run only every other day.
I'm going to be adding a bit more code to the process this w, so
hopefully my additional testing will help to reveal the answer.
Thanks for your help
"Michael C#" wrote:

> Nothing's jumping out at me, other than you're not fully-qualifying all of
> the tables (i.e., temp_drives). Are you seeing anything in your Event Log
s
> on either the local computer or remote linked servers? My best guess woul
d
> be a security/login failure on the remote machine, but you'd have to check
> the logs for that. Could be that the commands are timing out, for instanc
e
> if you're running intensive operations every other day like backups and
> index rebuilds, etc. Look for any other activities that are occurring on
> your server on days of failure. It might end up just being a case of
> scheduling the job to run earlier or later in the day.
> There might be additional info in the SQL Server Logs (under "Management"
in
> EM).
> Let me know if you see anything in your logs.
> "vogelm" <vogelm@.discussions.microsoft.com> wrote in message
> news:B4EDC587-A45D-4FBE-9F28-F3C2FE46A7E1@.microsoft.com...
>
>|||Did you find a resolution on this?
"vogelm" <vogelm@.discussions.microsoft.com> wrote in message
news:277700A6-9FDD-44E7-847B-EF51E572387A@.microsoft.com...
> No, nothing in the event logs. The security is set up correctly. It
> could
> be a timeout issue, but I would assume that I'd receive an error message
> in
> that case.
> Also, there are no other long-running jobs during this time, and no
> processes that run only every other day.
> I'm going to be adding a bit more code to the process this w, so
> hopefully my additional testing will help to reveal the answer.
> Thanks for your help
> "Michael C#" wrote:
>|||No, not yet. This is only something I can work on when I have all my other
"regular" work done. :-(
"Michael C#" wrote:

> Did you find a resolution on this?
> "vogelm" <vogelm@.discussions.microsoft.com> wrote in message
> news:277700A6-9FDD-44E7-847B-EF51E572387A@.microsoft.com...
>
>