Showing posts with label sp2. Show all posts
Showing posts with label sp2. Show all posts

Sunday, March 25, 2012

Changing Collation on a Cluster

Hi,
I am sure that someone has managed to do this. We have a 64_bit Clustered
SQL2005 SP2 build 3175 server that we created as Latin1_General_Bin. We want
to change it to the North American default but keep getting errors. The
latest was: - SQL Server Setup is unable to run on this node as it is
unavailable due to a SCC failure or other reason
SQL Server Setup is unable to run. Either the owning node or all nodes that
are currently part of the virtual server are not available. Review any SCC
failures and validate that all nodes are online.
Can someone help before we uninstall? Will we have problems if we uninstall?
Thanks
Chris
Ureka. We did it. We found that the registry key value as to where the
install came from was different on the two nodes and we were using the sa
password for the adminpassword instead of the Windows account we installed
with.
The build still shows 3200, where we had got to, even though BOL seems to
think that this may not be right. It mentioned about having to re-apply the
service packs and hotfix builds.
Chris
"Chris Wood" <anonymous@.microsoft.com> wrote in message
news:uWLbw$EOIHA.2376@.TK2MSFTNGP02.phx.gbl...
> Hi,
> I am sure that someone has managed to do this. We have a 64_bit Clustered
> SQL2005 SP2 build 3175 server that we created as Latin1_General_Bin. We
> want to change it to the North American default but keep getting errors.
> The latest was: - SQL Server Setup is unable to run on this node as it is
> unavailable due to a SCC failure or other reason
> SQL Server Setup is unable to run. Either the owning node or all nodes
> that are currently part of the virtual server are not available. Review
> any SCC failures and validate that all nodes are online.
> Can someone help before we uninstall? Will we have problems if we
> uninstall?
> Thanks
> Chris
>
|||BOL is correct.
The binaries on all the nodes are build 3200, but likely the procedures on
Master (and possibly the resource database) are still at RTM. Reapply all
service packs and hotfix/cumulative updates to guarantee binaries and data
elements are all in sync.
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP
"Chris Wood" <anonymous@.microsoft.com> wrote in message
news:u0QWCrFOIHA.4272@.TK2MSFTNGP06.phx.gbl...
> Ureka. We did it. We found that the registry key value as to where the
> install came from was different on the two nodes and we were using the sa
> password for the adminpassword instead of the Windows account we installed
> with.
> The build still shows 3200, where we had got to, even though BOL seems to
> think that this may not be right. It mentioned about having to re-apply
> the service packs and hotfix builds.
> Chris
> "Chris Wood" <anonymous@.microsoft.com> wrote in message
> news:uWLbw$EOIHA.2376@.TK2MSFTNGP02.phx.gbl...
>
|||Thanks Geoff.
I checked the summary.txt says 1399.06. That's what made me suspicious.
Looks like MS need to make a change somewhere otherwise people will not
re-run the updates.
Chris
PS. Hope this is handled better in SQL2008.
"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:e96bTBOOIHA.2208@.TK2MSFTNGP06.phx.gbl...
> BOL is correct.
> The binaries on all the nodes are build 3200, but likely the procedures on
> Master (and possibly the resource database) are still at RTM. Reapply all
> service packs and hotfix/cumulative updates to guarantee binaries and data
> elements are all in sync.
> --
> Geoff N. Hiten
> Senior SQL Infrastructure Consultant
> Microsoft SQL Server MVP
>
>
> "Chris Wood" <anonymous@.microsoft.com> wrote in message
> news:u0QWCrFOIHA.4272@.TK2MSFTNGP06.phx.gbl...
>

Thursday, March 8, 2012

Change to behavior in SQL 2005 SP2?

I just applied SQL 2005 SP2 to our SQL 2005 server. We have a maintenance
plan that does a transaction log backup on all databases every hour. Prior
to SP2 (running build 2153), the maintenance plan would silently skip
databases in simple recovery mode. Immediately after applying the service
pack though, the next scheduled job reported an error for every database in
simple recovery mode.
Is this an expected change in behavior with SP2? I did not see anything in
the release notes about this.
I've heard various rumblings that you're better off re-creating you
maintenance plans under SP2. The underlying mechanics have been overhauled,
and that just seems like the safest route.
"Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
news:%23HKkjvcVHHA.3592@.TK2MSFTNGP03.phx.gbl...
>I just applied SQL 2005 SP2 to our SQL 2005 server. We have a maintenance
>plan that does a transaction log backup on all databases every hour. Prior
>to SP2 (running build 2153), the maintenance plan would silently skip
>databases in simple recovery mode. Immediately after applying the service
>pack though, the next scheduled job reported an error for every database in
>simple recovery mode.
> Is this an expected change in behavior with SP2? I did not see anything
> in the release notes about this.
>
|||I actually tried this, but it didn't seem to help. The plan is very simple:
one Backup Database task, set to transaction log and configured to backup
all user databases.
"Aaron Bertrand [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:OCZR7DdVHHA.388@.TK2MSFTNGP04.phx.gbl...
> I've heard various rumblings that you're better off re-creating you
> maintenance plans under SP2. The underlying mechanics have been
> overhauled, and that just seems like the safest route.
>
> "Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
> news:%23HKkjvcVHHA.3592@.TK2MSFTNGP03.phx.gbl...
>
|||Michael,
Could this fix be what changed this:-
http://support.microsoft.com/kb/921003/ ?
We found that you could not create a maintenance plan unless the DB was in
Full recovery mode. If you created a maintenance plan and then the DB was
changed to the Bulk-logged recovery mode the log backup job ran but did not
do anything. This patch fixed both situations and could have caused yours!
Chris
"Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
news:uWZiEIdVHHA.1208@.TK2MSFTNGP03.phx.gbl...
>I actually tried this, but it didn't seem to help. The plan is very
>simple: one Backup Database task, set to transaction log and configured to
>backup all user databases.
> "Aaron Bertrand [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in
> message news:OCZR7DdVHHA.388@.TK2MSFTNGP04.phx.gbl...
>
|||It does seem possible, although that referse to bulk-logged recovery mode
and not simple.
I suppose my only recourse is to call PSS and see if they have a response
other than "only backup databases in full recovery mode."
I prefer to select "All Databases" in the maintenance plan so I don't have
to remember to add new databases to the plan as they are added.
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:OLswF8pVHHA.4404@.TK2MSFTNGP03.phx.gbl...
> Michael,
> Could this fix be what changed this:-
> http://support.microsoft.com/kb/921003/ ?
> We found that you could not create a maintenance plan unless the DB was in
> Full recovery mode. If you created a maintenance plan and then the DB was
> changed to the Bulk-logged recovery mode the log backup job ran but did
> not do anything. This patch fixed both situations and could have caused
> yours!
> Chris
> "Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
> news:uWZiEIdVHHA.1208@.TK2MSFTNGP03.phx.gbl...
>
|||On second thought maybe I can write a script to only do BACKUP LOG on
databases in FULL recovery mode instead of relying on the maintenance plan
to generate the script.
"Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
news:uz8E8y2VHHA.3948@.TK2MSFTNGP05.phx.gbl...
> It does seem possible, although that referse to bulk-logged recovery mode
> and not simple.
> I suppose my only recourse is to call PSS and see if they have a response
> other than "only backup databases in full recovery mode."
> I prefer to select "All Databases" in the maintenance plan so I don't have
> to remember to add new databases to the plan as they are added.
>
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:OLswF8pVHHA.4404@.TK2MSFTNGP03.phx.gbl...
>
|||Michael,
The wizard still gives you the choice of All User databases, All System
database and All databases. I would not expect the system ones to change so
create 2 sets of plans, 1 to cover the system ones and one to cover the user
ones.
Chris
"Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
news:uz8E8y2VHHA.3948@.TK2MSFTNGP05.phx.gbl...
> It does seem possible, although that referse to bulk-logged recovery mode
> and not simple.
> I suppose my only recourse is to call PSS and see if they have a response
> other than "only backup databases in full recovery mode."
> I prefer to select "All Databases" in the maintenance plan so I don't have
> to remember to add new databases to the plan as they are added.
>
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:OLswF8pVHHA.4404@.TK2MSFTNGP03.phx.gbl...
>
|||On Feb 23, 11:04 am, "Michael D'Angelo"
<nospamnmda...@.phoenixworx.org> wrote:
> It does seem possible, although that referse to bulk-logged recovery mode
> and not simple.
> I suppose my only recourse is to call PSS and see if they have a response
> other than "only backup databases in full recovery mode."
> I prefer to select "All Databases" in the maintenance plan so I don't have
> to remember to add new databases to the plan as they are added.
>
Have a look at this script of mine... It will automate all of your
backups, including the logs, and will pick up new databases
automatically...
http://realsqlguy.blogspot.com/2007/02/automating-database-backups.html
|||Actually, even selecting "All user databases" causes the error. I was
hoping not to have to select specific databases.
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:uPILJH3VHHA.3980@.TK2MSFTNGP02.phx.gbl...
> Michael,
> The wizard still gives you the choice of All User databases, All System
> database and All databases. I would not expect the system ones to change
> so create 2 sets of plans, 1 to cover the system ones and one to cover the
> user ones.
> Chris
> "Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
> news:uz8E8y2VHHA.3948@.TK2MSFTNGP05.phx.gbl...
>
|||Thanks I'll take a look!
"Tracy McKibben" <tracy.mckibben@.gmail.com> wrote in message
news:1172254771.872080.170760@.v33g2000cwv.googlegr oups.com...
> On Feb 23, 11:04 am, "Michael D'Angelo"
> <nospamnmda...@.phoenixworx.org> wrote:
> Have a look at this script of mine... It will automate all of your
> backups, including the logs, and will pick up new databases
> automatically...
> http://realsqlguy.blogspot.com/2007/02/automating-database-backups.html
>

Change to behavior in SQL 2005 SP2?

I just applied SQL 2005 SP2 to our SQL 2005 server. We have a maintenance
plan that does a transaction log backup on all databases every hour. Prior
to SP2 (running build 2153), the maintenance plan would silently skip
databases in simple recovery mode. Immediately after applying the service
pack though, the next scheduled job reported an error for every database in
simple recovery mode.
Is this an expected change in behavior with SP2? I did not see anything in
the release notes about this.I've heard various rumblings that you're better off re-creating you
maintenance plans under SP2. The underlying mechanics have been overhauled,
and that just seems like the safest route.
"Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
news:%23HKkjvcVHHA.3592@.TK2MSFTNGP03.phx.gbl...
>I just applied SQL 2005 SP2 to our SQL 2005 server. We have a maintenance
>plan that does a transaction log backup on all databases every hour. Prior
>to SP2 (running build 2153), the maintenance plan would silently skip
>databases in simple recovery mode. Immediately after applying the service
>pack though, the next scheduled job reported an error for every database in
>simple recovery mode.
> Is this an expected change in behavior with SP2? I did not see anything
> in the release notes about this.
>|||I actually tried this, but it didn't seem to help. The plan is very simple:
one Backup Database task, set to transaction log and configured to backup
all user databases.
"Aaron Bertrand [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:OCZR7DdVHHA.388@.TK2MSFTNGP04.phx.gbl...
> I've heard various rumblings that you're better off re-creating you
> maintenance plans under SP2. The underlying mechanics have been
> overhauled, and that just seems like the safest route.
>
> "Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
> news:%23HKkjvcVHHA.3592@.TK2MSFTNGP03.phx.gbl...
>>I just applied SQL 2005 SP2 to our SQL 2005 server. We have a maintenance
>>plan that does a transaction log backup on all databases every hour.
>>Prior to SP2 (running build 2153), the maintenance plan would silently
>>skip databases in simple recovery mode. Immediately after applying the
>>service pack though, the next scheduled job reported an error for every
>>database in simple recovery mode.
>> Is this an expected change in behavior with SP2? I did not see anything
>> in the release notes about this.
>|||Michael,
Could this fix be what changed this:-
http://support.microsoft.com/kb/921003/ ?
We found that you could not create a maintenance plan unless the DB was in
Full recovery mode. If you created a maintenance plan and then the DB was
changed to the Bulk-logged recovery mode the log backup job ran but did not
do anything. This patch fixed both situations and could have caused yours!
Chris
"Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
news:uWZiEIdVHHA.1208@.TK2MSFTNGP03.phx.gbl...
>I actually tried this, but it didn't seem to help. The plan is very
>simple: one Backup Database task, set to transaction log and configured to
>backup all user databases.
> "Aaron Bertrand [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in
> message news:OCZR7DdVHHA.388@.TK2MSFTNGP04.phx.gbl...
>> I've heard various rumblings that you're better off re-creating you
>> maintenance plans under SP2. The underlying mechanics have been
>> overhauled, and that just seems like the safest route.
>>
>> "Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
>> news:%23HKkjvcVHHA.3592@.TK2MSFTNGP03.phx.gbl...
>>I just applied SQL 2005 SP2 to our SQL 2005 server. We have a
>>maintenance plan that does a transaction log backup on all databases
>>every hour. Prior to SP2 (running build 2153), the maintenance plan would
>>silently skip databases in simple recovery mode. Immediately after
>>applying the service pack though, the next scheduled job reported an
>>error for every database in simple recovery mode.
>> Is this an expected change in behavior with SP2? I did not see anything
>> in the release notes about this.
>>
>|||It does seem possible, although that referse to bulk-logged recovery mode
and not simple.
I suppose my only recourse is to call PSS and see if they have a response
other than "only backup databases in full recovery mode."
I prefer to select "All Databases" in the maintenance plan so I don't have
to remember to add new databases to the plan as they are added.
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:OLswF8pVHHA.4404@.TK2MSFTNGP03.phx.gbl...
> Michael,
> Could this fix be what changed this:-
> http://support.microsoft.com/kb/921003/ ?
> We found that you could not create a maintenance plan unless the DB was in
> Full recovery mode. If you created a maintenance plan and then the DB was
> changed to the Bulk-logged recovery mode the log backup job ran but did
> not do anything. This patch fixed both situations and could have caused
> yours!
> Chris
> "Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
> news:uWZiEIdVHHA.1208@.TK2MSFTNGP03.phx.gbl...
>>I actually tried this, but it didn't seem to help. The plan is very
>>simple: one Backup Database task, set to transaction log and configured to
>>backup all user databases.
>> "Aaron Bertrand [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in
>> message news:OCZR7DdVHHA.388@.TK2MSFTNGP04.phx.gbl...
>> I've heard various rumblings that you're better off re-creating you
>> maintenance plans under SP2. The underlying mechanics have been
>> overhauled, and that just seems like the safest route.
>>
>> "Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
>> news:%23HKkjvcVHHA.3592@.TK2MSFTNGP03.phx.gbl...
>>I just applied SQL 2005 SP2 to our SQL 2005 server. We have a
>>maintenance plan that does a transaction log backup on all databases
>>every hour. Prior to SP2 (running build 2153), the maintenance plan
>>would silently skip databases in simple recovery mode. Immediately
>>after applying the service pack though, the next scheduled job reported
>>an error for every database in simple recovery mode.
>> Is this an expected change in behavior with SP2? I did not see
>> anything in the release notes about this.
>>
>>
>|||On second thought maybe I can write a script to only do BACKUP LOG on
databases in FULL recovery mode instead of relying on the maintenance plan
to generate the script.
"Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
news:uz8E8y2VHHA.3948@.TK2MSFTNGP05.phx.gbl...
> It does seem possible, although that referse to bulk-logged recovery mode
> and not simple.
> I suppose my only recourse is to call PSS and see if they have a response
> other than "only backup databases in full recovery mode."
> I prefer to select "All Databases" in the maintenance plan so I don't have
> to remember to add new databases to the plan as they are added.
>
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:OLswF8pVHHA.4404@.TK2MSFTNGP03.phx.gbl...
>> Michael,
>> Could this fix be what changed this:-
>> http://support.microsoft.com/kb/921003/ ?
>> We found that you could not create a maintenance plan unless the DB was
>> in Full recovery mode. If you created a maintenance plan and then the DB
>> was changed to the Bulk-logged recovery mode the log backup job ran but
>> did not do anything. This patch fixed both situations and could have
>> caused yours!
>> Chris
>> "Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
>> news:uWZiEIdVHHA.1208@.TK2MSFTNGP03.phx.gbl...
>>I actually tried this, but it didn't seem to help. The plan is very
>>simple: one Backup Database task, set to transaction log and configured
>>to backup all user databases.
>> "Aaron Bertrand [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in
>> message news:OCZR7DdVHHA.388@.TK2MSFTNGP04.phx.gbl...
>> I've heard various rumblings that you're better off re-creating you
>> maintenance plans under SP2. The underlying mechanics have been
>> overhauled, and that just seems like the safest route.
>>
>> "Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
>> news:%23HKkjvcVHHA.3592@.TK2MSFTNGP03.phx.gbl...
>>I just applied SQL 2005 SP2 to our SQL 2005 server. We have a
>>maintenance plan that does a transaction log backup on all databases
>>every hour. Prior to SP2 (running build 2153), the maintenance plan
>>would silently skip databases in simple recovery mode. Immediately
>>after applying the service pack though, the next scheduled job reported
>>an error for every database in simple recovery mode.
>> Is this an expected change in behavior with SP2? I did not see
>> anything in the release notes about this.
>>
>>
>>
>|||Michael,
The wizard still gives you the choice of All User databases, All System
database and All databases. I would not expect the system ones to change so
create 2 sets of plans, 1 to cover the system ones and one to cover the user
ones.
Chris
"Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
news:uz8E8y2VHHA.3948@.TK2MSFTNGP05.phx.gbl...
> It does seem possible, although that referse to bulk-logged recovery mode
> and not simple.
> I suppose my only recourse is to call PSS and see if they have a response
> other than "only backup databases in full recovery mode."
> I prefer to select "All Databases" in the maintenance plan so I don't have
> to remember to add new databases to the plan as they are added.
>
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:OLswF8pVHHA.4404@.TK2MSFTNGP03.phx.gbl...
>> Michael,
>> Could this fix be what changed this:-
>> http://support.microsoft.com/kb/921003/ ?
>> We found that you could not create a maintenance plan unless the DB was
>> in Full recovery mode. If you created a maintenance plan and then the DB
>> was changed to the Bulk-logged recovery mode the log backup job ran but
>> did not do anything. This patch fixed both situations and could have
>> caused yours!
>> Chris
>> "Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
>> news:uWZiEIdVHHA.1208@.TK2MSFTNGP03.phx.gbl...
>>I actually tried this, but it didn't seem to help. The plan is very
>>simple: one Backup Database task, set to transaction log and configured
>>to backup all user databases.
>> "Aaron Bertrand [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in
>> message news:OCZR7DdVHHA.388@.TK2MSFTNGP04.phx.gbl...
>> I've heard various rumblings that you're better off re-creating you
>> maintenance plans under SP2. The underlying mechanics have been
>> overhauled, and that just seems like the safest route.
>>
>> "Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
>> news:%23HKkjvcVHHA.3592@.TK2MSFTNGP03.phx.gbl...
>>I just applied SQL 2005 SP2 to our SQL 2005 server. We have a
>>maintenance plan that does a transaction log backup on all databases
>>every hour. Prior to SP2 (running build 2153), the maintenance plan
>>would silently skip databases in simple recovery mode. Immediately
>>after applying the service pack though, the next scheduled job reported
>>an error for every database in simple recovery mode.
>> Is this an expected change in behavior with SP2? I did not see
>> anything in the release notes about this.
>>
>>
>>
>|||On Feb 23, 11:04 am, "Michael D'Angelo"
<nospamnmda...@.phoenixworx.org> wrote:
> It does seem possible, although that referse to bulk-logged recovery mode
> and not simple.
> I suppose my only recourse is to call PSS and see if they have a response
> other than "only backup databases in full recovery mode."
> I prefer to select "All Databases" in the maintenance plan so I don't have
> to remember to add new databases to the plan as they are added.
>
Have a look at this script of mine... It will automate all of your
backups, including the logs, and will pick up new databases
automatically...
http://realsqlguy.blogspot.com/2007/02/automating-database-backups.html|||Actually, even selecting "All user databases" causes the error. I was
hoping not to have to select specific databases.
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:uPILJH3VHHA.3980@.TK2MSFTNGP02.phx.gbl...
> Michael,
> The wizard still gives you the choice of All User databases, All System
> database and All databases. I would not expect the system ones to change
> so create 2 sets of plans, 1 to cover the system ones and one to cover the
> user ones.
> Chris
> "Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
> news:uz8E8y2VHHA.3948@.TK2MSFTNGP05.phx.gbl...
>> It does seem possible, although that referse to bulk-logged recovery mode
>> and not simple.
>> I suppose my only recourse is to call PSS and see if they have a response
>> other than "only backup databases in full recovery mode."
>> I prefer to select "All Databases" in the maintenance plan so I don't
>> have to remember to add new databases to the plan as they are added.
>>
>> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
>> news:OLswF8pVHHA.4404@.TK2MSFTNGP03.phx.gbl...
>> Michael,
>> Could this fix be what changed this:-
>> http://support.microsoft.com/kb/921003/ ?
>> We found that you could not create a maintenance plan unless the DB was
>> in Full recovery mode. If you created a maintenance plan and then the DB
>> was changed to the Bulk-logged recovery mode the log backup job ran but
>> did not do anything. This patch fixed both situations and could have
>> caused yours!
>> Chris
>> "Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
>> news:uWZiEIdVHHA.1208@.TK2MSFTNGP03.phx.gbl...
>>I actually tried this, but it didn't seem to help. The plan is very
>>simple: one Backup Database task, set to transaction log and configured
>>to backup all user databases.
>> "Aaron Bertrand [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in
>> message news:OCZR7DdVHHA.388@.TK2MSFTNGP04.phx.gbl...
>> I've heard various rumblings that you're better off re-creating you
>> maintenance plans under SP2. The underlying mechanics have been
>> overhauled, and that just seems like the safest route.
>>
>> "Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
>> news:%23HKkjvcVHHA.3592@.TK2MSFTNGP03.phx.gbl...
>>I just applied SQL 2005 SP2 to our SQL 2005 server. We have a
>>maintenance plan that does a transaction log backup on all databases
>>every hour. Prior to SP2 (running build 2153), the maintenance plan
>>would silently skip databases in simple recovery mode. Immediately
>>after applying the service pack though, the next scheduled job
>>reported an error for every database in simple recovery mode.
>> Is this an expected change in behavior with SP2? I did not see
>> anything in the release notes about this.
>>
>>
>>
>>
>|||Thanks I'll take a look!
"Tracy McKibben" <tracy.mckibben@.gmail.com> wrote in message
news:1172254771.872080.170760@.v33g2000cwv.googlegroups.com...
> On Feb 23, 11:04 am, "Michael D'Angelo"
> <nospamnmda...@.phoenixworx.org> wrote:
>> It does seem possible, although that referse to bulk-logged recovery mode
>> and not simple.
>> I suppose my only recourse is to call PSS and see if they have a response
>> other than "only backup databases in full recovery mode."
>> I prefer to select "All Databases" in the maintenance plan so I don't
>> have
>> to remember to add new databases to the plan as they are added.
> Have a look at this script of mine... It will automate all of your
> backups, including the logs, and will pick up new databases
> automatically...
> http://realsqlguy.blogspot.com/2007/02/automating-database-backups.html
>

Change to behavior in SQL 2005 SP2?

I just applied SQL 2005 SP2 to our SQL 2005 server. We have a maintenance
plan that does a transaction log backup on all databases every hour. Prior
to SP2 (running build 2153), the maintenance plan would silently skip
databases in simple recovery mode. Immediately after applying the service
pack though, the next scheduled job reported an error for every database in
simple recovery mode.
Is this an expected change in behavior with SP2? I did not see anything in
the release notes about this.I've heard various rumblings that you're better off re-creating you
maintenance plans under SP2. The underlying mechanics have been overhauled,
and that just seems like the safest route.
"Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
news:%23HKkjvcVHHA.3592@.TK2MSFTNGP03.phx.gbl...
>I just applied SQL 2005 SP2 to our SQL 2005 server. We have a maintenance
>plan that does a transaction log backup on all databases every hour. Prior
>to SP2 (running build 2153), the maintenance plan would silently skip
>databases in simple recovery mode. Immediately after applying the service
>pack though, the next scheduled job reported an error for every database in
>simple recovery mode.
> Is this an expected change in behavior with SP2? I did not see anything
> in the release notes about this.
>|||I actually tried this, but it didn't seem to help. The plan is very simple:
one Backup Database task, set to transaction log and configured to backup
all user databases.
"Aaron Bertrand [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in mess
age
news:OCZR7DdVHHA.388@.TK2MSFTNGP04.phx.gbl...
> I've heard various rumblings that you're better off re-creating you
> maintenance plans under SP2. The underlying mechanics have been
> overhauled, and that just seems like the safest route.
>
> "Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
> news:%23HKkjvcVHHA.3592@.TK2MSFTNGP03.phx.gbl...
>|||Michael,
Could this fix be what changed this:-
http://support.microsoft.com/kb/921003/ ?
We found that you could not create a maintenance plan unless the DB was in
Full recovery mode. If you created a maintenance plan and then the DB was
changed to the Bulk-logged recovery mode the log backup job ran but did not
do anything. This patch fixed both situations and could have caused yours!
Chris
"Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
news:uWZiEIdVHHA.1208@.TK2MSFTNGP03.phx.gbl...
>I actually tried this, but it didn't seem to help. The plan is very
>simple: one Backup Database task, set to transaction log and configured to
>backup all user databases.
> "Aaron Bertrand [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in
> message news:OCZR7DdVHHA.388@.TK2MSFTNGP04.phx.gbl...
>|||It does seem possible, although that referse to bulk-logged recovery mode
and not simple.
I suppose my only recourse is to call PSS and see if they have a response
other than "only backup databases in full recovery mode."
I prefer to select "All Databases" in the maintenance plan so I don't have
to remember to add new databases to the plan as they are added.
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:OLswF8pVHHA.4404@.TK2MSFTNGP03.phx.gbl...
> Michael,
> Could this fix be what changed this:-
> http://support.microsoft.com/kb/921003/ ?
> We found that you could not create a maintenance plan unless the DB was in
> Full recovery mode. If you created a maintenance plan and then the DB was
> changed to the Bulk-logged recovery mode the log backup job ran but did
> not do anything. This patch fixed both situations and could have caused
> yours!
> Chris
> "Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
> news:uWZiEIdVHHA.1208@.TK2MSFTNGP03.phx.gbl...
>|||On second thought maybe I can write a script to only do BACKUP LOG on
databases in FULL recovery mode instead of relying on the maintenance plan
to generate the script.
"Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
news:uz8E8y2VHHA.3948@.TK2MSFTNGP05.phx.gbl...
> It does seem possible, although that referse to bulk-logged recovery mode
> and not simple.
> I suppose my only recourse is to call PSS and see if they have a response
> other than "only backup databases in full recovery mode."
> I prefer to select "All Databases" in the maintenance plan so I don't have
> to remember to add new databases to the plan as they are added.
>
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:OLswF8pVHHA.4404@.TK2MSFTNGP03.phx.gbl...
>|||Michael,
The wizard still gives you the choice of All User databases, All System
database and All databases. I would not expect the system ones to change so
create 2 sets of plans, 1 to cover the system ones and one to cover the user
ones.
Chris
"Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
news:uz8E8y2VHHA.3948@.TK2MSFTNGP05.phx.gbl...
> It does seem possible, although that referse to bulk-logged recovery mode
> and not simple.
> I suppose my only recourse is to call PSS and see if they have a response
> other than "only backup databases in full recovery mode."
> I prefer to select "All Databases" in the maintenance plan so I don't have
> to remember to add new databases to the plan as they are added.
>
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:OLswF8pVHHA.4404@.TK2MSFTNGP03.phx.gbl...
>|||On Feb 23, 11:04 am, "Michael D'Angelo"
<nospamnmda...@.phoenixworx.org> wrote:
> It does seem possible, although that referse to bulk-logged recovery mode
> and not simple.
> I suppose my only recourse is to call PSS and see if they have a response
> other than "only backup databases in full recovery mode."
> I prefer to select "All Databases" in the maintenance plan so I don't have
> to remember to add new databases to the plan as they are added.
>
Have a look at this script of mine... It will automate all of your
backups, including the logs, and will pick up new databases
automatically...
http://realsqlguy.blogspot.com/2007...se-backups.html|||Actually, even selecting "All user databases" causes the error. I was
hoping not to have to select specific databases.
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:uPILJH3VHHA.3980@.TK2MSFTNGP02.phx.gbl...
> Michael,
> The wizard still gives you the choice of All User databases, All System
> database and All databases. I would not expect the system ones to change
> so create 2 sets of plans, 1 to cover the system ones and one to cover the
> user ones.
> Chris
> "Michael D'Angelo" <nospamnmdange@.phoenixworx.org> wrote in message
> news:uz8E8y2VHHA.3948@.TK2MSFTNGP05.phx.gbl...
>|||Thanks I'll take a look!
"Tracy McKibben" <tracy.mckibben@.gmail.com> wrote in message
news:1172254771.872080.170760@.v33g2000cwv.googlegroups.com...
> On Feb 23, 11:04 am, "Michael D'Angelo"
> <nospamnmda...@.phoenixworx.org> wrote:
> Have a look at this script of mine... It will automate all of your
> backups, including the logs, and will pick up new databases
> automatically...
> http://realsqlguy.blogspot.com/2007...se-backups.html
>

Friday, February 24, 2012

change sqlvdi.dll IdentifySQLServer

I've inherited a SQL 2005 Server with SP2 installed that throws this error whenever it's backed up via EMC Insignia's Retrospect 7.5:

Source: SQLVDI
Event ID: 1

SQLVDI: Loc=IdentifySQLServer. Desc=MSSQL$DATALIBRARY1. ErrorCode=(1060)The specified service does not exist as an installed service.
. Process=4788. Thread=4672. Client. Instance=DATALIBRARY1. VD=.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

As far as I can tell, the name should be DATALIBRARY, not DATALIBRARY1. Is there a way to change that reference without having to uninstall / reinstall?

Thanks,

- Al

If the SQL instance is named DATALIBRARY, then you'll need to look at the Retrospect configuration to see why it's using the wrong name. It may be as simple as revising the Retrospect backup job. I don't have a copy of Retrospect to play with, so I can't tell exactly how that would be done.|||Thanks Kevin. After uninstalling / re-installing the Retrospect client countless times, I was finally able to get it to sync with the SQL instance DATALIBRARY. Now I'm getting the same error message with the correct server name:

SQLVDI: Loc=IdentifySQLServer. Desc=MSSQL$DATALIBRARY. ErrorCode=(1060)The specified service does not exist as an installed service.
. Process=2540. Thread=2760. Client. Instance=DATALIBRARY. VD=.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Any other ideas / troubleshooting I can try?

Thanks,

- Al

|||Thanks Kevin.

I uninstalled / re-installed the Retrospect client and was able to get the client to sync up with the correct SQL instance name. Now the error message is the same, except that it points to the correct name:

SQLVDI: Loc=IdentifySQLServer. Desc=MSSQL$DATALIBRARY. ErrorCode=(1060)The specified service does not exist as an installed service.
. Process=2540. Thread=2760. Client. Instance=DATALIBRARY. VD=.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Any other troubleshooting you can think of?

Thanks,

- Al

|||Thanks Kevin,

I uninstalled / re-installed the Retrospect client and was able to pick up the correct SQL instance name. Now we're logging the same error with the right server name:

SQLVDI: Loc=IdentifySQLServer. Desc=MSSQL$DATALIBRARY. ErrorCode=(1060)The specified service does not exist as an installed service.
. Process=2540. Thread=2760. Client. Instance=DATALIBRARY. VD=.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Any other troubleshooting tips I can try?

Thanks,

- Al

change sqlvdi.dll IdentifySQLServer

I've inherited a SQL 2005 Server with SP2 installed that throws this error whenever it's backed up via EMC Insignia's Retrospect 7.5:

Source: SQLVDI
Event ID: 1

SQLVDI: Loc=IdentifySQLServer. Desc=MSSQL$DATALIBRARY1. ErrorCode=(1060)The specified service does not exist as an installed service.
. Process=4788. Thread=4672. Client. Instance=DATALIBRARY1. VD=.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

As far as I can tell, the name should be DATALIBRARY, not DATALIBRARY1. Is there a way to change that reference without having to uninstall / reinstall?

Thanks,

- AlIf the SQL instance is named DATALIBRARY, then you'll need to look at the Retrospect configuration to see why it's using the wrong name. It may be as simple as revising the Retrospect backup job. I don't have a copy of Retrospect to play with, so I can't tell exactly how that would be done.|||Thanks Kevin. After uninstalling / re-installing the Retrospect client countless times, I was finally able to get it to sync with the SQL instance DATALIBRARY. Now I'm getting the same error message with the correct server name:

SQLVDI: Loc=IdentifySQLServer. Desc=MSSQL$DATALIBRARY. ErrorCode=(1060)The specified service does not exist as an installed service.
. Process=2540. Thread=2760. Client. Instance=DATALIBRARY. VD=.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Any other ideas / troubleshooting I can try?

Thanks,

- Al|||Thanks Kevin.

I uninstalled / re-installed the Retrospect client and was able to get the client to sync up with the correct SQL instance name. Now the error message is the same, except that it points to the correct name:

SQLVDI: Loc=IdentifySQLServer. Desc=MSSQL$DATALIBRARY. ErrorCode=(1060)The specified service does not exist as an installed service.
. Process=2540. Thread=2760. Client. Instance=DATALIBRARY. VD=.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Any other troubleshooting you can think of?

Thanks,

- Al|||Thanks Kevin,

I uninstalled / re-installed the Retrospect client and was able to pick up the correct SQL instance name. Now we're logging the same error with the right server name:

SQLVDI: Loc=IdentifySQLServer. Desc=MSSQL$DATALIBRARY. ErrorCode=(1060)The specified service does not exist as an installed service.
. Process=2540. Thread=2760. Client. Instance=DATALIBRARY. VD=.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Any other troubleshooting tips I can try?

Thanks,

- Al

change sqlvdi.dll IdentifySQLServer

I've inherited a SQL 2005 Server with SP2 installed that throws this error whenever it's backed up via EMC Insignia's Retrospect 7.5:

Source: SQLVDI
Event ID: 1

SQLVDI: Loc=IdentifySQLServer. Desc=MSSQL$DATALIBRARY1. ErrorCode=(1060)The specified service does not exist as an installed service.
. Process=4788. Thread=4672. Client. Instance=DATALIBRARY1. VD=.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

As far as I can tell, the name should be DATALIBRARY, not DATALIBRARY1. Is there a way to change that reference without having to uninstall / reinstall?

Thanks,

- AlIf the SQL instance is named DATALIBRARY, then you'll need to look at the Retrospect configuration to see why it's using the wrong name. It may be as simple as revising the Retrospect backup job. I don't have a copy of Retrospect to play with, so I can't tell exactly how that would be done.|||Thanks Kevin. After uninstalling / re-installing the Retrospect client countless times, I was finally able to get it to sync with the SQL instance DATALIBRARY. Now I'm getting the same error message with the correct server name:

SQLVDI: Loc=IdentifySQLServer. Desc=MSSQL$DATALIBRARY. ErrorCode=(1060)The specified service does not exist as an installed service.
. Process=2540. Thread=2760. Client. Instance=DATALIBRARY. VD=.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Any other ideas / troubleshooting I can try?

Thanks,

- Al|||Thanks Kevin.

I uninstalled / re-installed the Retrospect client and was able to get the client to sync up with the correct SQL instance name. Now the error message is the same, except that it points to the correct name:

SQLVDI: Loc=IdentifySQLServer. Desc=MSSQL$DATALIBRARY. ErrorCode=(1060)The specified service does not exist as an installed service.
. Process=2540. Thread=2760. Client. Instance=DATALIBRARY. VD=.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Any other troubleshooting you can think of?

Thanks,

- Al|||Thanks Kevin,

I uninstalled / re-installed the Retrospect client and was able to pick up the correct SQL instance name. Now we're logging the same error with the right server name:

SQLVDI: Loc=IdentifySQLServer. Desc=MSSQL$DATALIBRARY. ErrorCode=(1060)The specified service does not exist as an installed service.
. Process=2540. Thread=2760. Client. Instance=DATALIBRARY. VD=.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Any other troubleshooting tips I can try?

Thanks,

- Al