Hello,
I am running an active-active cluster on SQL 2000 SP3a over a Windows 2003
Enterprise server. We have two production instances running (SQL1 and SQL2).
Each was setup on a different node originally. When the two instances are
running on the same node, the instance that was not setup on that node
experiences locked files and failed backups.
Here is an example:
SQL1 was setup on Node1 and SQL2 was setup on Node2. When SQL1 and SQL2 are
both running on Node1, our backup job fails because it sees that a couple of
the database backup files are locked. Even after I clear the locks and re-ru
n
the backup script, the job still fails for the same reason. Now when I run
the same job when SQL2 is back on Node2, the job completes successfully. Not
all of the database backups fail, just the ones that are over 2Gb.
Has anyone experienced this or heard about this before? I've checked posting
s
here as well as TechNet, but haven't found anything.
Thanks for your assistance.
Michael
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200609/1> both running on Node1, our backup job fails
By 'our backup job', I assume you meant the SQL Server database backup job.
The problem should not have anything to do with how the two instances were
originally set up. Nor should it necessarily have anything to do with the
fact that the two instances were running on the same node. It was a
coincident that it did happen when the two instances were running on the sam
e
node.
To resolve the problem, you need to first determine what process(es) or
programs are locking the backup files. My hunch is that they are most likely
locked either by an anti-virus program or a network file backup job. In othe
r
words, the anti-virus or the network file backup job happened to collide wit
h
the database backup on this particular node.
One way to be sure about what is locking the backup file is to add another
step immediately before the SQL Server backup to dump out all the NT handles
or just the handles on the backup file. You can use the sysinternals tool
handle.exe for this purpose.
Linchi
"michaelg via droptable.com" wrote:
> Hello,
> I am running an active-active cluster on SQL 2000 SP3a over a Windows 2003
> Enterprise server. We have two production instances running (SQL1 and SQL2
).
> Each was setup on a different node originally. When the two instances are
> running on the same node, the instance that was not setup on that node
> experiences locked files and failed backups.
> Here is an example:
> SQL1 was setup on Node1 and SQL2 was setup on Node2. When SQL1 and SQL2 ar
e
> both running on Node1, our backup job fails because it sees that a couple
of
> the database backup files are locked. Even after I clear the locks and re-
run
> the backup script, the job still fails for the same reason. Now when I run
> the same job when SQL2 is back on Node2, the job completes successfully. N
ot
> all of the database backups fail, just the ones that are over 2Gb.
> Has anyone experienced this or heard about this before? I've checked posti
ngs
> here as well as TechNet, but haven't found anything.
> Thanks for your assistance.
> Michael
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forum...server/200609/1
>|||Yes, I meant the SQL Server database backup jobs.
This is not a one-time event. No matter what time I run the database backup
job on Node1, the job fails. This makes me think that it is not a tape backu
p
or any scheduled event. When I moved back to Node2 this morning, the job ran
fine multiple times.
I am not familiar with the handle.exe. Is this a 3rd party tool or is it
included in Microsoft?
Thanks!
Linchi Shea wrote:[vbcol=seagreen]
>By 'our backup job', I assume you meant the SQL Server database backup job.
>The problem should not have anything to do with how the two instances were
>originally set up. Nor should it necessarily have anything to do with the
>fact that the two instances were running on the same node. It was a
>coincident that it did happen when the two instances were running on the sa
me
>node.
>To resolve the problem, you need to first determine what process(es) or
>programs are locking the backup files. My hunch is that they are most likel
y
>locked either by an anti-virus program or a network file backup job. In oth
er
>words, the anti-virus or the network file backup job happened to collide wi
th
>the database backup on this particular node.
>One way to be sure about what is locking the backup file is to add another
>step immediately before the SQL Server backup to dump out all the NT handle
s
>or just the handles on the backup file. You can use the sysinternals tool
>handle.exe for this purpose.
>Linchi
>
>[quoted text clipped - 18 lines]
Message posted via http://www.droptable.com|||This is a sysinternals tool available from www.sysinternals.com.
Linchi
"michaelg via droptable.com" wrote:
> Yes, I meant the SQL Server database backup jobs.
> This is not a one-time event. No matter what time I run the database backu
p
> job on Node1, the job fails. This makes me think that it is not a tape bac
kup
> or any scheduled event. When I moved back to Node2 this morning, the job r
an
> fine multiple times.
> I am not familiar with the handle.exe. Is this a 3rd party tool or is it
> included in Microsoft?
> Thanks!
> Linchi Shea wrote:
> --
> Message posted via http://www.droptable.com
>
Showing posts with label instances. Show all posts
Showing posts with label instances. Show all posts
Friday, March 30, 2012
Locked files during backups on a cluster
Hello,
I am running an active-active cluster on SQL 2000 SP3a over a Windows 2003
Enterprise server. We have two production instances running (SQL1 and SQL2).
Each was setup on a different node originally. When the two instances are
running on the same node, the instance that was not setup on that node
experiences locked files and failed backups.
Here is an example:
SQL1 was setup on Node1 and SQL2 was setup on Node2. When SQL1 and SQL2 are
both running on Node1, our backup job fails because it sees that a couple of
the database backup files are locked. Even after I clear the locks and re-run
the backup script, the job still fails for the same reason. Now when I run
the same job when SQL2 is back on Node2, the job completes successfully. Not
all of the database backups fail, just the ones that are over 2Gb.
Has anyone experienced this or heard about this before? I've checked postings
here as well as TechNet, but haven't found anything.
Thanks for your assistance.
Michael
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200609/1> both running on Node1, our backup job fails
By 'our backup job', I assume you meant the SQL Server database backup job.
The problem should not have anything to do with how the two instances were
originally set up. Nor should it necessarily have anything to do with the
fact that the two instances were running on the same node. It was a
coincident that it did happen when the two instances were running on the same
node.
To resolve the problem, you need to first determine what process(es) or
programs are locking the backup files. My hunch is that they are most likely
locked either by an anti-virus program or a network file backup job. In other
words, the anti-virus or the network file backup job happened to collide with
the database backup on this particular node.
One way to be sure about what is locking the backup file is to add another
step immediately before the SQL Server backup to dump out all the NT handles
or just the handles on the backup file. You can use the sysinternals tool
handle.exe for this purpose.
Linchi
"michaelg via SQLMonster.com" wrote:
> Hello,
> I am running an active-active cluster on SQL 2000 SP3a over a Windows 2003
> Enterprise server. We have two production instances running (SQL1 and SQL2).
> Each was setup on a different node originally. When the two instances are
> running on the same node, the instance that was not setup on that node
> experiences locked files and failed backups.
> Here is an example:
> SQL1 was setup on Node1 and SQL2 was setup on Node2. When SQL1 and SQL2 are
> both running on Node1, our backup job fails because it sees that a couple of
> the database backup files are locked. Even after I clear the locks and re-run
> the backup script, the job still fails for the same reason. Now when I run
> the same job when SQL2 is back on Node2, the job completes successfully. Not
> all of the database backups fail, just the ones that are over 2Gb.
> Has anyone experienced this or heard about this before? I've checked postings
> here as well as TechNet, but haven't found anything.
> Thanks for your assistance.
> Michael
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200609/1
>|||Yes, I meant the SQL Server database backup jobs.
This is not a one-time event. No matter what time I run the database backup
job on Node1, the job fails. This makes me think that it is not a tape backup
or any scheduled event. When I moved back to Node2 this morning, the job ran
fine multiple times.
I am not familiar with the handle.exe. Is this a 3rd party tool or is it
included in Microsoft?
Thanks!
Linchi Shea wrote:
>> both running on Node1, our backup job fails
>By 'our backup job', I assume you meant the SQL Server database backup job.
>The problem should not have anything to do with how the two instances were
>originally set up. Nor should it necessarily have anything to do with the
>fact that the two instances were running on the same node. It was a
>coincident that it did happen when the two instances were running on the same
>node.
>To resolve the problem, you need to first determine what process(es) or
>programs are locking the backup files. My hunch is that they are most likely
>locked either by an anti-virus program or a network file backup job. In other
>words, the anti-virus or the network file backup job happened to collide with
>the database backup on this particular node.
>One way to be sure about what is locking the backup file is to add another
>step immediately before the SQL Server backup to dump out all the NT handles
>or just the handles on the backup file. You can use the sysinternals tool
>handle.exe for this purpose.
>Linchi
>> Hello,
>[quoted text clipped - 18 lines]
>> Thanks for your assistance.
>> Michael
--
Message posted via http://www.sqlmonster.com|||This is a sysinternals tool available from www.sysinternals.com.
Linchi
"michaelg via SQLMonster.com" wrote:
> Yes, I meant the SQL Server database backup jobs.
> This is not a one-time event. No matter what time I run the database backup
> job on Node1, the job fails. This makes me think that it is not a tape backup
> or any scheduled event. When I moved back to Node2 this morning, the job ran
> fine multiple times.
> I am not familiar with the handle.exe. Is this a 3rd party tool or is it
> included in Microsoft?
> Thanks!
> Linchi Shea wrote:
> >> both running on Node1, our backup job fails
> >
> >By 'our backup job', I assume you meant the SQL Server database backup job.
> >
> >The problem should not have anything to do with how the two instances were
> >originally set up. Nor should it necessarily have anything to do with the
> >fact that the two instances were running on the same node. It was a
> >coincident that it did happen when the two instances were running on the same
> >node.
> >
> >To resolve the problem, you need to first determine what process(es) or
> >programs are locking the backup files. My hunch is that they are most likely
> >locked either by an anti-virus program or a network file backup job. In other
> >words, the anti-virus or the network file backup job happened to collide with
> >the database backup on this particular node.
> >
> >One way to be sure about what is locking the backup file is to add another
> >step immediately before the SQL Server backup to dump out all the NT handles
> >or just the handles on the backup file. You can use the sysinternals tool
> >handle.exe for this purpose.
> >
> >Linchi
> >
> >> Hello,
> >>
> >[quoted text clipped - 18 lines]
> >> Thanks for your assistance.
> >> Michael
> --
> Message posted via http://www.sqlmonster.com
>
I am running an active-active cluster on SQL 2000 SP3a over a Windows 2003
Enterprise server. We have two production instances running (SQL1 and SQL2).
Each was setup on a different node originally. When the two instances are
running on the same node, the instance that was not setup on that node
experiences locked files and failed backups.
Here is an example:
SQL1 was setup on Node1 and SQL2 was setup on Node2. When SQL1 and SQL2 are
both running on Node1, our backup job fails because it sees that a couple of
the database backup files are locked. Even after I clear the locks and re-run
the backup script, the job still fails for the same reason. Now when I run
the same job when SQL2 is back on Node2, the job completes successfully. Not
all of the database backups fail, just the ones that are over 2Gb.
Has anyone experienced this or heard about this before? I've checked postings
here as well as TechNet, but haven't found anything.
Thanks for your assistance.
Michael
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200609/1> both running on Node1, our backup job fails
By 'our backup job', I assume you meant the SQL Server database backup job.
The problem should not have anything to do with how the two instances were
originally set up. Nor should it necessarily have anything to do with the
fact that the two instances were running on the same node. It was a
coincident that it did happen when the two instances were running on the same
node.
To resolve the problem, you need to first determine what process(es) or
programs are locking the backup files. My hunch is that they are most likely
locked either by an anti-virus program or a network file backup job. In other
words, the anti-virus or the network file backup job happened to collide with
the database backup on this particular node.
One way to be sure about what is locking the backup file is to add another
step immediately before the SQL Server backup to dump out all the NT handles
or just the handles on the backup file. You can use the sysinternals tool
handle.exe for this purpose.
Linchi
"michaelg via SQLMonster.com" wrote:
> Hello,
> I am running an active-active cluster on SQL 2000 SP3a over a Windows 2003
> Enterprise server. We have two production instances running (SQL1 and SQL2).
> Each was setup on a different node originally. When the two instances are
> running on the same node, the instance that was not setup on that node
> experiences locked files and failed backups.
> Here is an example:
> SQL1 was setup on Node1 and SQL2 was setup on Node2. When SQL1 and SQL2 are
> both running on Node1, our backup job fails because it sees that a couple of
> the database backup files are locked. Even after I clear the locks and re-run
> the backup script, the job still fails for the same reason. Now when I run
> the same job when SQL2 is back on Node2, the job completes successfully. Not
> all of the database backups fail, just the ones that are over 2Gb.
> Has anyone experienced this or heard about this before? I've checked postings
> here as well as TechNet, but haven't found anything.
> Thanks for your assistance.
> Michael
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200609/1
>|||Yes, I meant the SQL Server database backup jobs.
This is not a one-time event. No matter what time I run the database backup
job on Node1, the job fails. This makes me think that it is not a tape backup
or any scheduled event. When I moved back to Node2 this morning, the job ran
fine multiple times.
I am not familiar with the handle.exe. Is this a 3rd party tool or is it
included in Microsoft?
Thanks!
Linchi Shea wrote:
>> both running on Node1, our backup job fails
>By 'our backup job', I assume you meant the SQL Server database backup job.
>The problem should not have anything to do with how the two instances were
>originally set up. Nor should it necessarily have anything to do with the
>fact that the two instances were running on the same node. It was a
>coincident that it did happen when the two instances were running on the same
>node.
>To resolve the problem, you need to first determine what process(es) or
>programs are locking the backup files. My hunch is that they are most likely
>locked either by an anti-virus program or a network file backup job. In other
>words, the anti-virus or the network file backup job happened to collide with
>the database backup on this particular node.
>One way to be sure about what is locking the backup file is to add another
>step immediately before the SQL Server backup to dump out all the NT handles
>or just the handles on the backup file. You can use the sysinternals tool
>handle.exe for this purpose.
>Linchi
>> Hello,
>[quoted text clipped - 18 lines]
>> Thanks for your assistance.
>> Michael
--
Message posted via http://www.sqlmonster.com|||This is a sysinternals tool available from www.sysinternals.com.
Linchi
"michaelg via SQLMonster.com" wrote:
> Yes, I meant the SQL Server database backup jobs.
> This is not a one-time event. No matter what time I run the database backup
> job on Node1, the job fails. This makes me think that it is not a tape backup
> or any scheduled event. When I moved back to Node2 this morning, the job ran
> fine multiple times.
> I am not familiar with the handle.exe. Is this a 3rd party tool or is it
> included in Microsoft?
> Thanks!
> Linchi Shea wrote:
> >> both running on Node1, our backup job fails
> >
> >By 'our backup job', I assume you meant the SQL Server database backup job.
> >
> >The problem should not have anything to do with how the two instances were
> >originally set up. Nor should it necessarily have anything to do with the
> >fact that the two instances were running on the same node. It was a
> >coincident that it did happen when the two instances were running on the same
> >node.
> >
> >To resolve the problem, you need to first determine what process(es) or
> >programs are locking the backup files. My hunch is that they are most likely
> >locked either by an anti-virus program or a network file backup job. In other
> >words, the anti-virus or the network file backup job happened to collide with
> >the database backup on this particular node.
> >
> >One way to be sure about what is locking the backup file is to add another
> >step immediately before the SQL Server backup to dump out all the NT handles
> >or just the handles on the backup file. You can use the sysinternals tool
> >handle.exe for this purpose.
> >
> >Linchi
> >
> >> Hello,
> >>
> >[quoted text clipped - 18 lines]
> >> Thanks for your assistance.
> >> Michael
> --
> Message posted via http://www.sqlmonster.com
>
Friday, February 24, 2012
Local instances being used for all linked (remote) instances
I'm getting this bizarre behavior where the local instances are being used i
ntead of the remote instances I'm trying to attach to. For background sake,
I'm running on a Windows 2003 Server that is a Domain controller. The other
SQL instances are on other
systems on another domain.
On the Windows 2003 server that has this problem it can only connect to remo
te instances that have similar names and then it overrides it with its own i
nstance. For example:
2003 server domain D2:
Instance: SRV1 (default, using maching name only)
Other systems on other domain D1:
Instance: SRV2 (default, using maching name only)
SRV2\Test
SRV3
SRV3\Test2
Assume all default instances have same sa password.
In enterprise manager on SRV1 you can register remote default instances and
it seems to connect up to them but when you view the databases you realize i
t connected to the local default instance.
Now if you try to connect up to an remote instance name that isn't on the lo
cal SRV1 system or if the password is different, it can't register it.
Finally if you go on SRV2 or SRV3, there is no conflicts registering instanc
es from the other systems including SRV1.
I tried to remove/reinstall SQL (and all instances) from SRV1, but same thin
g occurred.
Any ideas?Try registring the server using the IP and port number instead of the DNS
name. See if that helps..
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"MJF" <anonymous@.discussions.microsoft.com> wrote in message
news:F7B2A2D9-5304-4B3A-8F39-04C4AB9F390B@.microsoft.com...
> I'm getting this bizarre behavior where the local instances are being used
intead of the remote instances I'm trying to attach to. For background sake,
I'm running on a Windows 2003 Server that is a Domain controller. The other
SQL instances are on other systems on another domain.
> On the Windows 2003 server that has this problem it can only connect to
remote instances that have similar names and then it overrides it with its
own instance. For example:
> 2003 server domain D2:
> Instance: SRV1 (default, using maching name only)
> Other systems on other domain D1:
> Instance: SRV2 (default, using maching name only)
> SRV2\Test
> SRV3
> SRV3\Test2
> Assume all default instances have same sa password.
> In enterprise manager on SRV1 you can register remote default instances
and it seems to connect up to them but when you view the databases you
realize it connected to the local default instance.
> Now if you try to connect up to an remote instance name that isn't on the
local SRV1 system or if the password is different, it can't register it.
> Finally if you go on SRV2 or SRV3, there is no conflicts registering
instances from the other systems including SRV1.
> I tried to remove/reinstall SQL (and all instances) from SRV1, but same
thing occurred.
> Any ideas?
>
>|||Also look at the SQL Client Network Utility on the SRV1 server and see if
there is an alias that points to SRV1. It could be using that alias when
you rgister the other SRV1 servers. If there is one there, remove it and
see what happnes. You should not need an alias on the actual server itself.
Rand
This posting is provided "as is" with no warranties and confers no rights.
ntead of the remote instances I'm trying to attach to. For background sake,
I'm running on a Windows 2003 Server that is a Domain controller. The other
SQL instances are on other
systems on another domain.
On the Windows 2003 server that has this problem it can only connect to remo
te instances that have similar names and then it overrides it with its own i
nstance. For example:
2003 server domain D2:
Instance: SRV1 (default, using maching name only)
Other systems on other domain D1:
Instance: SRV2 (default, using maching name only)
SRV2\Test
SRV3
SRV3\Test2
Assume all default instances have same sa password.
In enterprise manager on SRV1 you can register remote default instances and
it seems to connect up to them but when you view the databases you realize i
t connected to the local default instance.
Now if you try to connect up to an remote instance name that isn't on the lo
cal SRV1 system or if the password is different, it can't register it.
Finally if you go on SRV2 or SRV3, there is no conflicts registering instanc
es from the other systems including SRV1.
I tried to remove/reinstall SQL (and all instances) from SRV1, but same thin
g occurred.
Any ideas?Try registring the server using the IP and port number instead of the DNS
name. See if that helps..
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"MJF" <anonymous@.discussions.microsoft.com> wrote in message
news:F7B2A2D9-5304-4B3A-8F39-04C4AB9F390B@.microsoft.com...
> I'm getting this bizarre behavior where the local instances are being used
intead of the remote instances I'm trying to attach to. For background sake,
I'm running on a Windows 2003 Server that is a Domain controller. The other
SQL instances are on other systems on another domain.
> On the Windows 2003 server that has this problem it can only connect to
remote instances that have similar names and then it overrides it with its
own instance. For example:
> 2003 server domain D2:
> Instance: SRV1 (default, using maching name only)
> Other systems on other domain D1:
> Instance: SRV2 (default, using maching name only)
> SRV2\Test
> SRV3
> SRV3\Test2
> Assume all default instances have same sa password.
> In enterprise manager on SRV1 you can register remote default instances
and it seems to connect up to them but when you view the databases you
realize it connected to the local default instance.
> Now if you try to connect up to an remote instance name that isn't on the
local SRV1 system or if the password is different, it can't register it.
> Finally if you go on SRV2 or SRV3, there is no conflicts registering
instances from the other systems including SRV1.
> I tried to remove/reinstall SQL (and all instances) from SRV1, but same
thing occurred.
> Any ideas?
>
>|||Also look at the SQL Client Network Utility on the SRV1 server and see if
there is an alias that points to SRV1. It could be using that alias when
you rgister the other SRV1 servers. If there is one there, remove it and
see what happnes. You should not need an alias on the actual server itself.
Rand
This posting is provided "as is" with no warranties and confers no rights.
Subscribe to:
Posts (Atom)