Can MSDE run stored procedures? Does MSDE have the same job scheduling features that SQL Standard and Enterprise Edition have?
SR
Yes and yes.
HTH,
Greg Low [MVP]
MSDE Manager SQL Tools
www.whitebearconsulting.com
"SR" <mv2k_2003-news@.yahoo.com> wrote in message news:ALq0d.13990$QJ3.9851@.newssvr21.news.prodigy.c om...
Can MSDE run stored procedures? Does MSDE have the same job scheduling features that SQL Standard and Enterprise Edition have?
SR
|||yes and no.
The SQL Express does not have job scheduler on board.
regards
bav
Showing posts with label job. Show all posts
Showing posts with label job. Show all posts
Friday, March 9, 2012
Saturday, February 25, 2012
msdb Restore......
I have restored the production msdb database on a test box. I can see my
entire DTS package and the scheduled jobs.
When I try to modify the job I am getting the following error.
Error 14274: Cannot add, update, or delete a job (or its steps or schedules)
that originated from an MSZSERVER. The job was not saved. OK Button
How to delete/update then?
SQL 2K.
Thank you,
Benjamin
Dear Benjamin,
Is the server was renamed from one name to another, if so see the
logins were in sync, another work around is
The best way to handle this problem after the rename process is to follow
these steps: 1. Rename the server back to the original name.
2. Script out all of the jobs and then delete them.
3. Rename the server to the new name.
4. Add back the jobs by running the script generated from step 2.
Or
1.Script the jobs in the server from where u backed up the msdb database.
2.Run the scripts in the new server.
for more details go through the following kb site
http://support.microsoft.com/default...b;en-us;281642
"Benjamin Nethan" wrote:
> I have restored the production msdb database on a test box. I can see my
> entire DTS package and the scheduled jobs.
> When I try to modify the job I am getting the following error.
> Error 14274: Cannot add, update, or delete a job (or its steps or schedules)
> that originated from an MSZSERVER. The job was not saved. OK Button
> How to delete/update then?
> SQL 2K.
> Thank you,
> Benjamin
>
>
>
|||You need to update the originating_server column in sysjobs to reflect the
name of the instance you restored the database to. You can use the following
code to do that http://sqldev.net/download/sqlagent/...ent_rename.sql
HTH
Jasper Smith (SQL Server MVP)
http://www.sqldbatips.com
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Benjamin Nethan" <BNethan@.hotmail.com> wrote in message
news:e59AAE5pFHA.820@.TK2MSFTNGP09.phx.gbl...
>I have restored the production msdb database on a test box. I can see my
> entire DTS package and the scheduled jobs.
> When I try to modify the job I am getting the following error.
> Error 14274: Cannot add, update, or delete a job (or its steps or
> schedules)
> that originated from an MSZSERVER. The job was not saved. OK Button
> How to delete/update then?
> SQL 2K.
> Thank you,
> Benjamin
>
>
entire DTS package and the scheduled jobs.
When I try to modify the job I am getting the following error.
Error 14274: Cannot add, update, or delete a job (or its steps or schedules)
that originated from an MSZSERVER. The job was not saved. OK Button
How to delete/update then?
SQL 2K.
Thank you,
Benjamin
Dear Benjamin,
Is the server was renamed from one name to another, if so see the
logins were in sync, another work around is
The best way to handle this problem after the rename process is to follow
these steps: 1. Rename the server back to the original name.
2. Script out all of the jobs and then delete them.
3. Rename the server to the new name.
4. Add back the jobs by running the script generated from step 2.
Or
1.Script the jobs in the server from where u backed up the msdb database.
2.Run the scripts in the new server.
for more details go through the following kb site
http://support.microsoft.com/default...b;en-us;281642
"Benjamin Nethan" wrote:
> I have restored the production msdb database on a test box. I can see my
> entire DTS package and the scheduled jobs.
> When I try to modify the job I am getting the following error.
> Error 14274: Cannot add, update, or delete a job (or its steps or schedules)
> that originated from an MSZSERVER. The job was not saved. OK Button
> How to delete/update then?
> SQL 2K.
> Thank you,
> Benjamin
>
>
>
|||You need to update the originating_server column in sysjobs to reflect the
name of the instance you restored the database to. You can use the following
code to do that http://sqldev.net/download/sqlagent/...ent_rename.sql
HTH
Jasper Smith (SQL Server MVP)
http://www.sqldbatips.com
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Benjamin Nethan" <BNethan@.hotmail.com> wrote in message
news:e59AAE5pFHA.820@.TK2MSFTNGP09.phx.gbl...
>I have restored the production msdb database on a test box. I can see my
> entire DTS package and the scheduled jobs.
> When I try to modify the job I am getting the following error.
> Error 14274: Cannot add, update, or delete a job (or its steps or
> schedules)
> that originated from an MSZSERVER. The job was not saved. OK Button
> How to delete/update then?
> SQL 2K.
> Thank you,
> Benjamin
>
>
msdb Restore......
I have restored the production msdb database on a test box. I can see my
entire DTS package and the scheduled jobs.
When I try to modify the job I am getting the following error.
Error 14274: Cannot add, update, or delete a job (or its steps or schedules)
that originated from an MSZSERVER. The job was not saved. OK Button
How to delete/update then?
SQL 2K.
Thank you,
BenjaminDear Benjamin,
Is the server was renamed from one name to another, if so see the
logins were in sync, another work around is
The best way to handle this problem after the rename process is to follow
these steps: 1. Rename the server back to the original name.
2. Script out all of the jobs and then delete them.
3. Rename the server to the new name.
4. Add back the jobs by running the script generated from step 2.
Or
1.Script the jobs in the server from where u backed up the msdb database.
2.Run the scripts in the new server.
for more details go through the following kb site
http://support.microsoft.com/default.aspx?scid=kb;en-us;281642
"Benjamin Nethan" wrote:
> I have restored the production msdb database on a test box. I can see my
> entire DTS package and the scheduled jobs.
> When I try to modify the job I am getting the following error.
> Error 14274: Cannot add, update, or delete a job (or its steps or schedules)
> that originated from an MSZSERVER. The job was not saved. OK Button
> How to delete/update then?
> SQL 2K.
> Thank you,
> Benjamin
>
>
>|||You need to update the originating_server column in sysjobs to reflect the
name of the instance you restored the database to. You can use the following
code to do that http://sqldev.net/download/sqlagent/sp_sqlagent_rename.sql
--
HTH
Jasper Smith (SQL Server MVP)
http://www.sqldbatips.com
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Benjamin Nethan" <BNethan@.hotmail.com> wrote in message
news:e59AAE5pFHA.820@.TK2MSFTNGP09.phx.gbl...
>I have restored the production msdb database on a test box. I can see my
> entire DTS package and the scheduled jobs.
> When I try to modify the job I am getting the following error.
> Error 14274: Cannot add, update, or delete a job (or its steps or
> schedules)
> that originated from an MSZSERVER. The job was not saved. OK Button
> How to delete/update then?
> SQL 2K.
> Thank you,
> Benjamin
>
>
entire DTS package and the scheduled jobs.
When I try to modify the job I am getting the following error.
Error 14274: Cannot add, update, or delete a job (or its steps or schedules)
that originated from an MSZSERVER. The job was not saved. OK Button
How to delete/update then?
SQL 2K.
Thank you,
BenjaminDear Benjamin,
Is the server was renamed from one name to another, if so see the
logins were in sync, another work around is
The best way to handle this problem after the rename process is to follow
these steps: 1. Rename the server back to the original name.
2. Script out all of the jobs and then delete them.
3. Rename the server to the new name.
4. Add back the jobs by running the script generated from step 2.
Or
1.Script the jobs in the server from where u backed up the msdb database.
2.Run the scripts in the new server.
for more details go through the following kb site
http://support.microsoft.com/default.aspx?scid=kb;en-us;281642
"Benjamin Nethan" wrote:
> I have restored the production msdb database on a test box. I can see my
> entire DTS package and the scheduled jobs.
> When I try to modify the job I am getting the following error.
> Error 14274: Cannot add, update, or delete a job (or its steps or schedules)
> that originated from an MSZSERVER. The job was not saved. OK Button
> How to delete/update then?
> SQL 2K.
> Thank you,
> Benjamin
>
>
>|||You need to update the originating_server column in sysjobs to reflect the
name of the instance you restored the database to. You can use the following
code to do that http://sqldev.net/download/sqlagent/sp_sqlagent_rename.sql
--
HTH
Jasper Smith (SQL Server MVP)
http://www.sqldbatips.com
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Benjamin Nethan" <BNethan@.hotmail.com> wrote in message
news:e59AAE5pFHA.820@.TK2MSFTNGP09.phx.gbl...
>I have restored the production msdb database on a test box. I can see my
> entire DTS package and the scheduled jobs.
> When I try to modify the job I am getting the following error.
> Error 14274: Cannot add, update, or delete a job (or its steps or
> schedules)
> that originated from an MSZSERVER. The job was not saved. OK Button
> How to delete/update then?
> SQL 2K.
> Thank you,
> Benjamin
>
>
msdb Restore......
I have restored the production msdb database on a test box. I can see my
entire DTS package and the scheduled jobs.
When I try to modify the job I am getting the following error.
Error 14274: Cannot add, update, or delete a job (or its steps or schedules)
that originated from an MSZSERVER. The job was not saved. OK Button
How to delete/update then?
SQL 2K.
Thank you,
BenjaminDear Benjamin,
Is the server was renamed from one name to another, if so see the
logins were in sync, another work around is
The best way to handle this problem after the rename process is to follow
these steps: 1. Rename the server back to the original name.
2. Script out all of the jobs and then delete them.
3. Rename the server to the new name.
4. Add back the jobs by running the script generated from step 2.
Or
1.Script the jobs in the server from where u backed up the msdb database.
2.Run the scripts in the new server.
for more details go through the following kb site
http://support.microsoft.com/defaul...kb;en-us;281642
"Benjamin Nethan" wrote:
> I have restored the production msdb database on a test box. I can see my
> entire DTS package and the scheduled jobs.
> When I try to modify the job I am getting the following error.
> Error 14274: Cannot add, update, or delete a job (or its steps or schedule
s)
> that originated from an MSZSERVER. The job was not saved. OK Button
> How to delete/update then?
> SQL 2K.
> Thank you,
> Benjamin
>
>
>|||You need to update the originating_server column in sysjobs to reflect the
name of the instance you restored the database to. You can use the following
code to do that http://sqldev.net/download/sqlagent...gent_rename.sql
HTH
Jasper Smith (SQL Server MVP)
http://www.sqldbatips.com
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Benjamin Nethan" <BNethan@.hotmail.com> wrote in message
news:e59AAE5pFHA.820@.TK2MSFTNGP09.phx.gbl...
>I have restored the production msdb database on a test box. I can see my
> entire DTS package and the scheduled jobs.
> When I try to modify the job I am getting the following error.
> Error 14274: Cannot add, update, or delete a job (or its steps or
> schedules)
> that originated from an MSZSERVER. The job was not saved. OK Button
> How to delete/update then?
> SQL 2K.
> Thank you,
> Benjamin
>
>
entire DTS package and the scheduled jobs.
When I try to modify the job I am getting the following error.
Error 14274: Cannot add, update, or delete a job (or its steps or schedules)
that originated from an MSZSERVER. The job was not saved. OK Button
How to delete/update then?
SQL 2K.
Thank you,
BenjaminDear Benjamin,
Is the server was renamed from one name to another, if so see the
logins were in sync, another work around is
The best way to handle this problem after the rename process is to follow
these steps: 1. Rename the server back to the original name.
2. Script out all of the jobs and then delete them.
3. Rename the server to the new name.
4. Add back the jobs by running the script generated from step 2.
Or
1.Script the jobs in the server from where u backed up the msdb database.
2.Run the scripts in the new server.
for more details go through the following kb site
http://support.microsoft.com/defaul...kb;en-us;281642
"Benjamin Nethan" wrote:
> I have restored the production msdb database on a test box. I can see my
> entire DTS package and the scheduled jobs.
> When I try to modify the job I am getting the following error.
> Error 14274: Cannot add, update, or delete a job (or its steps or schedule
s)
> that originated from an MSZSERVER. The job was not saved. OK Button
> How to delete/update then?
> SQL 2K.
> Thank you,
> Benjamin
>
>
>|||You need to update the originating_server column in sysjobs to reflect the
name of the instance you restored the database to. You can use the following
code to do that http://sqldev.net/download/sqlagent...gent_rename.sql
HTH
Jasper Smith (SQL Server MVP)
http://www.sqldbatips.com
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Benjamin Nethan" <BNethan@.hotmail.com> wrote in message
news:e59AAE5pFHA.820@.TK2MSFTNGP09.phx.gbl...
>I have restored the production msdb database on a test box. I can see my
> entire DTS package and the scheduled jobs.
> When I try to modify the job I am getting the following error.
> Error 14274: Cannot add, update, or delete a job (or its steps or
> schedules)
> that originated from an MSZSERVER. The job was not saved. OK Button
> How to delete/update then?
> SQL 2K.
> Thank you,
> Benjamin
>
>
Monday, February 20, 2012
MSDB (Subspect)
Does anyone know how I can recover the MSDB once it is not subspect?
The reason is the server was down during the backup job running in night and I have already copy the database file to the orginial location but only the MSDB was subspected...
Just restore your latest backup of the msdb database. Msdb is just like any other database when it comes to
handling a suspect database. General recommendations for handling a suspect database:
http://www.karaszi.com/SQLServer/inf...suspect_db.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Philip" <zeta_01@.hotmail.com> wrote in message news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com...
> Does anyone know how I can recover the MSDB once it is not subspect?
> The reason is the server was down during the backup job running in night and I have already copy the
database file to the orginial location but only the MSDB was subspected...
>
|||Hi,
I have already tried restore the msdb database from the backup but don't know why still subspected....
Any Idea?
-- Tibor Karaszi wrote: --
Just restore your latest backup of the msdb database. Msdb is just like any other database when it comes to
handling a suspect database. General recommendations for handling a suspect database:
http://www.karaszi.com/SQLServer/inf...suspect_db.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Philip" <zeta_01@.hotmail.com> wrote in message news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com...[vbcol=seagreen]
> Does anyone know how I can recover the MSDB once it is not subspect?
database file to the orginial location but only the MSDB was subspected...[vbcol=seagreen]
|||Probably because the database was damaged when you took the backup. Do you perform regular DBCC checks against
the MSDB database?
You can always rebuild the system databases (rebuildm.exe). This is a rather advanced option, don't do this
unless you know what happens and how it work.
Or perhaps use another SQL Server. Disconnect from network. Make sure you have the same machine name. Install
SQL Server. Make sure you select the same collation as the production machine. Stop that SQL Server. Copy the
files from the msdb database to the production SQL Server. You will of course have an "empty" msdb database
now. This should work, but is most probably not supported.
Also, I think that you can run the script file which creates the msdb database. You probably need to set some
trace flag to allow you to drop the msdb database in the first place. This could be documented in KB 224071.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Philip" <anonymous@.discussions.microsoft.com> wrote in message
news:5ACC3100-003F-4686-9AC7-06603C8EB86E@.microsoft.com...
> Hi,
> I have already tried restore the msdb database from the backup but don't know why still subspected....
> Any Idea?
> -- Tibor Karaszi wrote: --
> Just restore your latest backup of the msdb database. Msdb is just like any other database when it
comes to
> handling a suspect database. General recommendations for handling a suspect database:
> http://www.karaszi.com/SQLServer/inf...suspect_db.asp
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Philip" <zeta_01@.hotmail.com> wrote in message
news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com...[vbcol=seagreen]
> database file to the orginial location but only the MSDB was subspected...
|||Your best bet is to call PSS (http://support.microsoft.com) who will be able
to help you with this.
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:OMEBrpsJEHA.428@.TK2MSFTNGP11.phx.gbl...
> Probably because the database was damaged when you took the backup. Do you
perform regular DBCC checks against
> the MSDB database?
> You can always rebuild the system databases (rebuildm.exe). This is a
rather advanced option, don't do this
> unless you know what happens and how it work.
> Or perhaps use another SQL Server. Disconnect from network. Make sure you
have the same machine name. Install
> SQL Server. Make sure you select the same collation as the production
machine. Stop that SQL Server. Copy the
> files from the msdb database to the production SQL Server. You will of
course have an "empty" msdb database
> now. This should work, but is most probably not supported.
> Also, I think that you can run the script file which creates the msdb
database. You probably need to set some
> trace flag to allow you to drop the msdb database in the first place. This
could be documented in KB 224071.[vbcol=seagreen]
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Philip" <anonymous@.discussions.microsoft.com> wrote in message
> news:5ACC3100-003F-4686-9AC7-06603C8EB86E@.microsoft.com...
know why still subspected....[vbcol=seagreen]
like any other database when it[vbcol=seagreen]
> comes to
suspect database:[vbcol=seagreen]
> news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com...
subspect?[vbcol=seagreen]
in night and I have already copy the[vbcol=seagreen]
subspected...
>
|||Hi Tiber / Philip,
I have one more suggestion to this issue, I feel that during the MSDB mdf
and LDF physical file copy (cold Backup), they would have started the SQL
server service. In this case during MSDB startup the files may be used by
the backup process and startup would have been failed and marked the
database "Suspect".
If this case he can run the procedure sp_resetstaus <dbname> and restart sql
server service.
steps:
1.
Use Master
GO
EXEC sp_resetstatus <dbname>
2. Stop & Start the SQL Server
Thanks
Hari
MCDBA
2."Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in message news:OMEBrpsJEHA.428@.TK2MSFTNGP11.phx.gbl...
> Probably because the database was damaged when you took the backup. Do you
perform regular DBCC checks against
> the MSDB database?
> You can always rebuild the system databases (rebuildm.exe). This is a
rather advanced option, don't do this
> unless you know what happens and how it work.
> Or perhaps use another SQL Server. Disconnect from network. Make sure you
have the same machine name. Install
> SQL Server. Make sure you select the same collation as the production
machine. Stop that SQL Server. Copy the
> files from the msdb database to the production SQL Server. You will of
course have an "empty" msdb database
> now. This should work, but is most probably not supported.
> Also, I think that you can run the script file which creates the msdb
database. You probably need to set some
> trace flag to allow you to drop the msdb database in the first place. This
could be documented in KB 224071.[vbcol=seagreen]
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Philip" <anonymous@.discussions.microsoft.com> wrote in message
> news:5ACC3100-003F-4686-9AC7-06603C8EB86E@.microsoft.com...
know why still subspected....[vbcol=seagreen]
like any other database when it[vbcol=seagreen]
> comes to
suspect database:[vbcol=seagreen]
> news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com...
subspect?[vbcol=seagreen]
in night and I have already copy the[vbcol=seagreen]
subspected...
>
The reason is the server was down during the backup job running in night and I have already copy the database file to the orginial location but only the MSDB was subspected...
Just restore your latest backup of the msdb database. Msdb is just like any other database when it comes to
handling a suspect database. General recommendations for handling a suspect database:
http://www.karaszi.com/SQLServer/inf...suspect_db.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Philip" <zeta_01@.hotmail.com> wrote in message news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com...
> Does anyone know how I can recover the MSDB once it is not subspect?
> The reason is the server was down during the backup job running in night and I have already copy the
database file to the orginial location but only the MSDB was subspected...
>
|||Hi,
I have already tried restore the msdb database from the backup but don't know why still subspected....
Any Idea?
-- Tibor Karaszi wrote: --
Just restore your latest backup of the msdb database. Msdb is just like any other database when it comes to
handling a suspect database. General recommendations for handling a suspect database:
http://www.karaszi.com/SQLServer/inf...suspect_db.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Philip" <zeta_01@.hotmail.com> wrote in message news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com...[vbcol=seagreen]
> Does anyone know how I can recover the MSDB once it is not subspect?
database file to the orginial location but only the MSDB was subspected...[vbcol=seagreen]
|||Probably because the database was damaged when you took the backup. Do you perform regular DBCC checks against
the MSDB database?
You can always rebuild the system databases (rebuildm.exe). This is a rather advanced option, don't do this
unless you know what happens and how it work.
Or perhaps use another SQL Server. Disconnect from network. Make sure you have the same machine name. Install
SQL Server. Make sure you select the same collation as the production machine. Stop that SQL Server. Copy the
files from the msdb database to the production SQL Server. You will of course have an "empty" msdb database
now. This should work, but is most probably not supported.
Also, I think that you can run the script file which creates the msdb database. You probably need to set some
trace flag to allow you to drop the msdb database in the first place. This could be documented in KB 224071.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Philip" <anonymous@.discussions.microsoft.com> wrote in message
news:5ACC3100-003F-4686-9AC7-06603C8EB86E@.microsoft.com...
> Hi,
> I have already tried restore the msdb database from the backup but don't know why still subspected....
> Any Idea?
> -- Tibor Karaszi wrote: --
> Just restore your latest backup of the msdb database. Msdb is just like any other database when it
comes to
> handling a suspect database. General recommendations for handling a suspect database:
> http://www.karaszi.com/SQLServer/inf...suspect_db.asp
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Philip" <zeta_01@.hotmail.com> wrote in message
news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com...[vbcol=seagreen]
> database file to the orginial location but only the MSDB was subspected...
|||Your best bet is to call PSS (http://support.microsoft.com) who will be able
to help you with this.
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:OMEBrpsJEHA.428@.TK2MSFTNGP11.phx.gbl...
> Probably because the database was damaged when you took the backup. Do you
perform regular DBCC checks against
> the MSDB database?
> You can always rebuild the system databases (rebuildm.exe). This is a
rather advanced option, don't do this
> unless you know what happens and how it work.
> Or perhaps use another SQL Server. Disconnect from network. Make sure you
have the same machine name. Install
> SQL Server. Make sure you select the same collation as the production
machine. Stop that SQL Server. Copy the
> files from the msdb database to the production SQL Server. You will of
course have an "empty" msdb database
> now. This should work, but is most probably not supported.
> Also, I think that you can run the script file which creates the msdb
database. You probably need to set some
> trace flag to allow you to drop the msdb database in the first place. This
could be documented in KB 224071.[vbcol=seagreen]
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Philip" <anonymous@.discussions.microsoft.com> wrote in message
> news:5ACC3100-003F-4686-9AC7-06603C8EB86E@.microsoft.com...
know why still subspected....[vbcol=seagreen]
like any other database when it[vbcol=seagreen]
> comes to
suspect database:[vbcol=seagreen]
> news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com...
subspect?[vbcol=seagreen]
in night and I have already copy the[vbcol=seagreen]
subspected...
>
|||Hi Tiber / Philip,
I have one more suggestion to this issue, I feel that during the MSDB mdf
and LDF physical file copy (cold Backup), they would have started the SQL
server service. In this case during MSDB startup the files may be used by
the backup process and startup would have been failed and marked the
database "Suspect".
If this case he can run the procedure sp_resetstaus <dbname> and restart sql
server service.
steps:
1.
Use Master
GO
EXEC sp_resetstatus <dbname>
2. Stop & Start the SQL Server
Thanks
Hari
MCDBA
2."Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in message news:OMEBrpsJEHA.428@.TK2MSFTNGP11.phx.gbl...
> Probably because the database was damaged when you took the backup. Do you
perform regular DBCC checks against
> the MSDB database?
> You can always rebuild the system databases (rebuildm.exe). This is a
rather advanced option, don't do this
> unless you know what happens and how it work.
> Or perhaps use another SQL Server. Disconnect from network. Make sure you
have the same machine name. Install
> SQL Server. Make sure you select the same collation as the production
machine. Stop that SQL Server. Copy the
> files from the msdb database to the production SQL Server. You will of
course have an "empty" msdb database
> now. This should work, but is most probably not supported.
> Also, I think that you can run the script file which creates the msdb
database. You probably need to set some
> trace flag to allow you to drop the msdb database in the first place. This
could be documented in KB 224071.[vbcol=seagreen]
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Philip" <anonymous@.discussions.microsoft.com> wrote in message
> news:5ACC3100-003F-4686-9AC7-06603C8EB86E@.microsoft.com...
know why still subspected....[vbcol=seagreen]
like any other database when it[vbcol=seagreen]
> comes to
suspect database:[vbcol=seagreen]
> news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com...
subspect?[vbcol=seagreen]
in night and I have already copy the[vbcol=seagreen]
subspected...
>
MSDB (Subspect)
Does anyone know how I can recover the MSDB once it is not subspect
The reason is the server was down during the backup job running in night and I have already copy the database file to the orginial location but only the MSDB was subspected...Just restore your latest backup of the msdb database. Msdb is just like any other database when it comes to
handling a suspect database. General recommendations for handling a suspect database:
http://www.karaszi.com/SQLServer/info_corrupt_suspect_db.asp
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Philip" <zeta_01@.hotmail.com> wrote in message news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com...
> Does anyone know how I can recover the MSDB once it is not subspect?
> The reason is the server was down during the backup job running in night and I have already copy the
database file to the orginial location but only the MSDB was subspected...
>|||Hi
I have already tried restore the msdb database from the backup but don't know why still subspected...
Any Idea?
-- Tibor Karaszi wrote: --
Just restore your latest backup of the msdb database. Msdb is just like any other database when it comes t
handling a suspect database. General recommendations for handling a suspect database
http://www.karaszi.com/SQLServer/info_corrupt_suspect_db.as
--
Tibor Karaszi, SQL Server MV
http://www.karaszi.com/sqlserver/default.as
"Philip" <zeta_01@.hotmail.com> wrote in message news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com..
> Does anyone know how I can recover the MSDB once it is not subspect
>> The reason is the server was down during the backup job running in night and I have already copy th
database file to the orginial location but only the MSDB was subspected...
>>|||Probably because the database was damaged when you took the backup. Do you perform regular DBCC checks against
the MSDB database?
You can always rebuild the system databases (rebuildm.exe). This is a rather advanced option, don't do this
unless you know what happens and how it work.
Or perhaps use another SQL Server. Disconnect from network. Make sure you have the same machine name. Install
SQL Server. Make sure you select the same collation as the production machine. Stop that SQL Server. Copy the
files from the msdb database to the production SQL Server. You will of course have an "empty" msdb database
now. This should work, but is most probably not supported.
Also, I think that you can run the script file which creates the msdb database. You probably need to set some
trace flag to allow you to drop the msdb database in the first place. This could be documented in KB 224071.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Philip" <anonymous@.discussions.microsoft.com> wrote in message
news:5ACC3100-003F-4686-9AC7-06603C8EB86E@.microsoft.com...
> Hi,
> I have already tried restore the msdb database from the backup but don't know why still subspected....
> Any Idea?
> -- Tibor Karaszi wrote: --
> Just restore your latest backup of the msdb database. Msdb is just like any other database when it
comes to
> handling a suspect database. General recommendations for handling a suspect database:
> http://www.karaszi.com/SQLServer/info_corrupt_suspect_db.asp
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Philip" <zeta_01@.hotmail.com> wrote in message
news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com...
> > Does anyone know how I can recover the MSDB once it is not subspect?
> >> The reason is the server was down during the backup job running in night and I have already copy the
> database file to the orginial location but only the MSDB was subspected...
> >>|||Your best bet is to call PSS (http://support.microsoft.com) who will be able
to help you with this.
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:OMEBrpsJEHA.428@.TK2MSFTNGP11.phx.gbl...
> Probably because the database was damaged when you took the backup. Do you
perform regular DBCC checks against
> the MSDB database?
> You can always rebuild the system databases (rebuildm.exe). This is a
rather advanced option, don't do this
> unless you know what happens and how it work.
> Or perhaps use another SQL Server. Disconnect from network. Make sure you
have the same machine name. Install
> SQL Server. Make sure you select the same collation as the production
machine. Stop that SQL Server. Copy the
> files from the msdb database to the production SQL Server. You will of
course have an "empty" msdb database
> now. This should work, but is most probably not supported.
> Also, I think that you can run the script file which creates the msdb
database. You probably need to set some
> trace flag to allow you to drop the msdb database in the first place. This
could be documented in KB 224071.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Philip" <anonymous@.discussions.microsoft.com> wrote in message
> news:5ACC3100-003F-4686-9AC7-06603C8EB86E@.microsoft.com...
> >
> > Hi,
> >
> > I have already tried restore the msdb database from the backup but don't
know why still subspected....
> >
> > Any Idea?
> > -- Tibor Karaszi wrote: --
> >
> > Just restore your latest backup of the msdb database. Msdb is just
like any other database when it
> comes to
> > handling a suspect database. General recommendations for handling a
suspect database:
> >
> > http://www.karaszi.com/SQLServer/info_corrupt_suspect_db.asp
> >
> > --
> > Tibor Karaszi, SQL Server MVP
> > http://www.karaszi.com/sqlserver/default.asp
> >
> >
> > "Philip" <zeta_01@.hotmail.com> wrote in message
> news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com...
> > > Does anyone know how I can recover the MSDB once it is not
subspect?
> > >> The reason is the server was down during the backup job running
in night and I have already copy the
> > database file to the orginial location but only the MSDB was
subspected...
> > >>
>|||Hi Tiber / Philip,
I have one more suggestion to this issue, I feel that during the MSDB mdf
and LDF physical file copy (cold Backup), they would have started the SQL
server service. In this case during MSDB startup the files may be used by
the backup process and startup would have been failed and marked the
database "Suspect".
If this case he can run the procedure sp_resetstaus <dbname> and restart sql
server service.
steps:
1.
Use Master
GO
EXEC sp_resetstatus <dbname>
2. Stop & Start the SQL Server
Thanks
Hari
MCDBA
2."Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in message news:OMEBrpsJEHA.428@.TK2MSFTNGP11.phx.gbl...
> Probably because the database was damaged when you took the backup. Do you
perform regular DBCC checks against
> the MSDB database?
> You can always rebuild the system databases (rebuildm.exe). This is a
rather advanced option, don't do this
> unless you know what happens and how it work.
> Or perhaps use another SQL Server. Disconnect from network. Make sure you
have the same machine name. Install
> SQL Server. Make sure you select the same collation as the production
machine. Stop that SQL Server. Copy the
> files from the msdb database to the production SQL Server. You will of
course have an "empty" msdb database
> now. This should work, but is most probably not supported.
> Also, I think that you can run the script file which creates the msdb
database. You probably need to set some
> trace flag to allow you to drop the msdb database in the first place. This
could be documented in KB 224071.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Philip" <anonymous@.discussions.microsoft.com> wrote in message
> news:5ACC3100-003F-4686-9AC7-06603C8EB86E@.microsoft.com...
> >
> > Hi,
> >
> > I have already tried restore the msdb database from the backup but don't
know why still subspected....
> >
> > Any Idea?
> > -- Tibor Karaszi wrote: --
> >
> > Just restore your latest backup of the msdb database. Msdb is just
like any other database when it
> comes to
> > handling a suspect database. General recommendations for handling a
suspect database:
> >
> > http://www.karaszi.com/SQLServer/info_corrupt_suspect_db.asp
> >
> > --
> > Tibor Karaszi, SQL Server MVP
> > http://www.karaszi.com/sqlserver/default.asp
> >
> >
> > "Philip" <zeta_01@.hotmail.com> wrote in message
> news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com...
> > > Does anyone know how I can recover the MSDB once it is not
subspect?
> > >> The reason is the server was down during the backup job running
in night and I have already copy the
> > database file to the orginial location but only the MSDB was
subspected...
> > >>
>
The reason is the server was down during the backup job running in night and I have already copy the database file to the orginial location but only the MSDB was subspected...Just restore your latest backup of the msdb database. Msdb is just like any other database when it comes to
handling a suspect database. General recommendations for handling a suspect database:
http://www.karaszi.com/SQLServer/info_corrupt_suspect_db.asp
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Philip" <zeta_01@.hotmail.com> wrote in message news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com...
> Does anyone know how I can recover the MSDB once it is not subspect?
> The reason is the server was down during the backup job running in night and I have already copy the
database file to the orginial location but only the MSDB was subspected...
>|||Hi
I have already tried restore the msdb database from the backup but don't know why still subspected...
Any Idea?
-- Tibor Karaszi wrote: --
Just restore your latest backup of the msdb database. Msdb is just like any other database when it comes t
handling a suspect database. General recommendations for handling a suspect database
http://www.karaszi.com/SQLServer/info_corrupt_suspect_db.as
--
Tibor Karaszi, SQL Server MV
http://www.karaszi.com/sqlserver/default.as
"Philip" <zeta_01@.hotmail.com> wrote in message news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com..
> Does anyone know how I can recover the MSDB once it is not subspect
>> The reason is the server was down during the backup job running in night and I have already copy th
database file to the orginial location but only the MSDB was subspected...
>>|||Probably because the database was damaged when you took the backup. Do you perform regular DBCC checks against
the MSDB database?
You can always rebuild the system databases (rebuildm.exe). This is a rather advanced option, don't do this
unless you know what happens and how it work.
Or perhaps use another SQL Server. Disconnect from network. Make sure you have the same machine name. Install
SQL Server. Make sure you select the same collation as the production machine. Stop that SQL Server. Copy the
files from the msdb database to the production SQL Server. You will of course have an "empty" msdb database
now. This should work, but is most probably not supported.
Also, I think that you can run the script file which creates the msdb database. You probably need to set some
trace flag to allow you to drop the msdb database in the first place. This could be documented in KB 224071.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Philip" <anonymous@.discussions.microsoft.com> wrote in message
news:5ACC3100-003F-4686-9AC7-06603C8EB86E@.microsoft.com...
> Hi,
> I have already tried restore the msdb database from the backup but don't know why still subspected....
> Any Idea?
> -- Tibor Karaszi wrote: --
> Just restore your latest backup of the msdb database. Msdb is just like any other database when it
comes to
> handling a suspect database. General recommendations for handling a suspect database:
> http://www.karaszi.com/SQLServer/info_corrupt_suspect_db.asp
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Philip" <zeta_01@.hotmail.com> wrote in message
news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com...
> > Does anyone know how I can recover the MSDB once it is not subspect?
> >> The reason is the server was down during the backup job running in night and I have already copy the
> database file to the orginial location but only the MSDB was subspected...
> >>|||Your best bet is to call PSS (http://support.microsoft.com) who will be able
to help you with this.
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:OMEBrpsJEHA.428@.TK2MSFTNGP11.phx.gbl...
> Probably because the database was damaged when you took the backup. Do you
perform regular DBCC checks against
> the MSDB database?
> You can always rebuild the system databases (rebuildm.exe). This is a
rather advanced option, don't do this
> unless you know what happens and how it work.
> Or perhaps use another SQL Server. Disconnect from network. Make sure you
have the same machine name. Install
> SQL Server. Make sure you select the same collation as the production
machine. Stop that SQL Server. Copy the
> files from the msdb database to the production SQL Server. You will of
course have an "empty" msdb database
> now. This should work, but is most probably not supported.
> Also, I think that you can run the script file which creates the msdb
database. You probably need to set some
> trace flag to allow you to drop the msdb database in the first place. This
could be documented in KB 224071.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Philip" <anonymous@.discussions.microsoft.com> wrote in message
> news:5ACC3100-003F-4686-9AC7-06603C8EB86E@.microsoft.com...
> >
> > Hi,
> >
> > I have already tried restore the msdb database from the backup but don't
know why still subspected....
> >
> > Any Idea?
> > -- Tibor Karaszi wrote: --
> >
> > Just restore your latest backup of the msdb database. Msdb is just
like any other database when it
> comes to
> > handling a suspect database. General recommendations for handling a
suspect database:
> >
> > http://www.karaszi.com/SQLServer/info_corrupt_suspect_db.asp
> >
> > --
> > Tibor Karaszi, SQL Server MVP
> > http://www.karaszi.com/sqlserver/default.asp
> >
> >
> > "Philip" <zeta_01@.hotmail.com> wrote in message
> news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com...
> > > Does anyone know how I can recover the MSDB once it is not
subspect?
> > >> The reason is the server was down during the backup job running
in night and I have already copy the
> > database file to the orginial location but only the MSDB was
subspected...
> > >>
>|||Hi Tiber / Philip,
I have one more suggestion to this issue, I feel that during the MSDB mdf
and LDF physical file copy (cold Backup), they would have started the SQL
server service. In this case during MSDB startup the files may be used by
the backup process and startup would have been failed and marked the
database "Suspect".
If this case he can run the procedure sp_resetstaus <dbname> and restart sql
server service.
steps:
1.
Use Master
GO
EXEC sp_resetstatus <dbname>
2. Stop & Start the SQL Server
Thanks
Hari
MCDBA
2."Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in message news:OMEBrpsJEHA.428@.TK2MSFTNGP11.phx.gbl...
> Probably because the database was damaged when you took the backup. Do you
perform regular DBCC checks against
> the MSDB database?
> You can always rebuild the system databases (rebuildm.exe). This is a
rather advanced option, don't do this
> unless you know what happens and how it work.
> Or perhaps use another SQL Server. Disconnect from network. Make sure you
have the same machine name. Install
> SQL Server. Make sure you select the same collation as the production
machine. Stop that SQL Server. Copy the
> files from the msdb database to the production SQL Server. You will of
course have an "empty" msdb database
> now. This should work, but is most probably not supported.
> Also, I think that you can run the script file which creates the msdb
database. You probably need to set some
> trace flag to allow you to drop the msdb database in the first place. This
could be documented in KB 224071.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Philip" <anonymous@.discussions.microsoft.com> wrote in message
> news:5ACC3100-003F-4686-9AC7-06603C8EB86E@.microsoft.com...
> >
> > Hi,
> >
> > I have already tried restore the msdb database from the backup but don't
know why still subspected....
> >
> > Any Idea?
> > -- Tibor Karaszi wrote: --
> >
> > Just restore your latest backup of the msdb database. Msdb is just
like any other database when it
> comes to
> > handling a suspect database. General recommendations for handling a
suspect database:
> >
> > http://www.karaszi.com/SQLServer/info_corrupt_suspect_db.asp
> >
> > --
> > Tibor Karaszi, SQL Server MVP
> > http://www.karaszi.com/sqlserver/default.asp
> >
> >
> > "Philip" <zeta_01@.hotmail.com> wrote in message
> news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com...
> > > Does anyone know how I can recover the MSDB once it is not
subspect?
> > >> The reason is the server was down during the backup job running
in night and I have already copy the
> > database file to the orginial location but only the MSDB was
subspected...
> > >>
>
MSDB (Subspect)
Does anyone know how I can recover the MSDB once it is not subspect?
The reason is the server was down during the backup job running in night and
I have already copy the database file to the orginial location but only the
MSDB was subspected...Just restore your latest backup of the msdb database. Msdb is just like any
other database when it comes to
handling a suspect database. General recommendations for handling a suspect
database:
http://www.karaszi.com/SQLServer/in..._suspect_db.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Philip" <zeta_01@.hotmail.com> wrote in message news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.mi
crosoft.com...
> Does anyone know how I can recover the MSDB once it is not subspect?
> The reason is the server was down during the backup job running in night and I hav
e already copy the
database file to the orginial location but only the MSDB was subspected...
>|||Hi,
I have already tried restore the msdb database from the backup but don't kno
w why still subspected....
Any Idea?
-- Tibor Karaszi wrote: --
Just restore your latest backup of the msdb database. Msdb is just like any
other database when it comes to
handling a suspect database. General recommendations for handling a suspect
database:
http://www.karaszi.com/SQLServer/in..._suspect_db.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Philip" <zeta_01@.hotmail.com> wrote in message news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.mi
crosoft.com...[vbcol=seagreen]
> Does anyone know how I can recover the MSDB once it is not subspect?
database file to the orginial location but only the MSDB was subspected...[vbcol=seagreen]|||Probably because the database was damaged when you took the backup. Do you p
erform regular DBCC checks against
the MSDB database?
You can always rebuild the system databases (rebuildm.exe). This is a rather
advanced option, don't do this
unless you know what happens and how it work.
Or perhaps use another SQL Server. Disconnect from network. Make sure you ha
ve the same machine name. Install
SQL Server. Make sure you select the same collation as the production machin
e. Stop that SQL Server. Copy the
files from the msdb database to the production SQL Server. You will of cours
e have an "empty" msdb database
now. This should work, but is most probably not supported.
Also, I think that you can run the script file which creates the msdb databa
se. You probably need to set some
trace flag to allow you to drop the msdb database in the first place. This c
ould be documented in KB 224071.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Philip" <anonymous@.discussions.microsoft.com> wrote in message
news:5ACC3100-003F-4686-9AC7-06603C8EB86E@.microsoft.com...
> Hi,
> I have already tried restore the msdb database from the backup but don't k
now why still subspected....
> Any Idea?
> -- Tibor Karaszi wrote: --
> Just restore your latest backup of the msdb database. Msdb is just like any o
ther database when it
comes to
> handling a suspect database. General recommendations for handling a s
uspect database:
> http://www.karaszi.com/SQLServer/in..._suspect_db.asp
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Philip" <zeta_01@.hotmail.com> wrote in message
news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com...[vbcol=seagreen]
> database file to the orginial location but only the MSDB was subspect
ed...|||Your best bet is to call PSS (http://support.microsoft.com) who will be able
to help you with this.
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:OMEBrpsJEHA.428@.TK2MSFTNGP11.phx.gbl...
> Probably because the database was damaged when you took the backup. Do you
perform regular DBCC checks against
> the MSDB database?
> You can always rebuild the system databases (rebuildm.exe). This is a
rather advanced option, don't do this
> unless you know what happens and how it work.
> Or perhaps use another SQL Server. Disconnect from network. Make sure you
have the same machine name. Install
> SQL Server. Make sure you select the same collation as the production
machine. Stop that SQL Server. Copy the
> files from the msdb database to the production SQL Server. You will of
course have an "empty" msdb database
> now. This should work, but is most probably not supported.
> Also, I think that you can run the script file which creates the msdb
database. You probably need to set some
> trace flag to allow you to drop the msdb database in the first place. This
could be documented in KB 224071.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Philip" <anonymous@.discussions.microsoft.com> wrote in message
> news:5ACC3100-003F-4686-9AC7-06603C8EB86E@.microsoft.com...
know why still subspected....[vbcol=seagreen]
like any other database when it[vbcol=seagreen]
> comes to
suspect database:[vbcol=seagreen]
> news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com...
subspect?[vbcol=seagreen]
in night and I have already copy the[vbcol=seagreen]
subspected...[vbcol=seagreen]
>|||Hi Tiber / Philip,
I have one more suggestion to this issue, I feel that during the MSDB mdf
and LDF physical file copy (cold Backup), they would have started the SQL
server service. In this case during MSDB startup the files may be used by
the backup process and startup would have been failed and marked the
database "Suspect".
If this case he can run the procedure sp_resetstaus <dbname> and restart sql
server service.
steps:
1.
Use Master
GO
EXEC sp_resetstatus <dbname>
2. Stop & Start the SQL Server
Thanks
Hari
MCDBA
2."Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in message news:OMEBrpsJEHA.428@.TK2MSFTNGP11.phx.gbl...
> Probably because the database was damaged when you took the backup. Do you
perform regular DBCC checks against
> the MSDB database?
> You can always rebuild the system databases (rebuildm.exe). This is a
rather advanced option, don't do this
> unless you know what happens and how it work.
> Or perhaps use another SQL Server. Disconnect from network. Make sure you
have the same machine name. Install
> SQL Server. Make sure you select the same collation as the production
machine. Stop that SQL Server. Copy the
> files from the msdb database to the production SQL Server. You will of
course have an "empty" msdb database
> now. This should work, but is most probably not supported.
> Also, I think that you can run the script file which creates the msdb
database. You probably need to set some
> trace flag to allow you to drop the msdb database in the first place. This
could be documented in KB 224071.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Philip" <anonymous@.discussions.microsoft.com> wrote in message
> news:5ACC3100-003F-4686-9AC7-06603C8EB86E@.microsoft.com...
know why still subspected....[vbcol=seagreen]
like any other database when it[vbcol=seagreen]
> comes to
suspect database:[vbcol=seagreen]
> news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com...
subspect?[vbcol=seagreen]
in night and I have already copy the[vbcol=seagreen]
subspected...[vbcol=seagreen]
>
The reason is the server was down during the backup job running in night and
I have already copy the database file to the orginial location but only the
MSDB was subspected...Just restore your latest backup of the msdb database. Msdb is just like any
other database when it comes to
handling a suspect database. General recommendations for handling a suspect
database:
http://www.karaszi.com/SQLServer/in..._suspect_db.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Philip" <zeta_01@.hotmail.com> wrote in message news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.mi
crosoft.com...
> Does anyone know how I can recover the MSDB once it is not subspect?
> The reason is the server was down during the backup job running in night and I hav
e already copy the
database file to the orginial location but only the MSDB was subspected...
>|||Hi,
I have already tried restore the msdb database from the backup but don't kno
w why still subspected....
Any Idea?
-- Tibor Karaszi wrote: --
Just restore your latest backup of the msdb database. Msdb is just like any
other database when it comes to
handling a suspect database. General recommendations for handling a suspect
database:
http://www.karaszi.com/SQLServer/in..._suspect_db.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Philip" <zeta_01@.hotmail.com> wrote in message news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.mi
crosoft.com...[vbcol=seagreen]
> Does anyone know how I can recover the MSDB once it is not subspect?
database file to the orginial location but only the MSDB was subspected...[vbcol=seagreen]|||Probably because the database was damaged when you took the backup. Do you p
erform regular DBCC checks against
the MSDB database?
You can always rebuild the system databases (rebuildm.exe). This is a rather
advanced option, don't do this
unless you know what happens and how it work.
Or perhaps use another SQL Server. Disconnect from network. Make sure you ha
ve the same machine name. Install
SQL Server. Make sure you select the same collation as the production machin
e. Stop that SQL Server. Copy the
files from the msdb database to the production SQL Server. You will of cours
e have an "empty" msdb database
now. This should work, but is most probably not supported.
Also, I think that you can run the script file which creates the msdb databa
se. You probably need to set some
trace flag to allow you to drop the msdb database in the first place. This c
ould be documented in KB 224071.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Philip" <anonymous@.discussions.microsoft.com> wrote in message
news:5ACC3100-003F-4686-9AC7-06603C8EB86E@.microsoft.com...
> Hi,
> I have already tried restore the msdb database from the backup but don't k
now why still subspected....
> Any Idea?
> -- Tibor Karaszi wrote: --
> Just restore your latest backup of the msdb database. Msdb is just like any o
ther database when it
comes to
> handling a suspect database. General recommendations for handling a s
uspect database:
> http://www.karaszi.com/SQLServer/in..._suspect_db.asp
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Philip" <zeta_01@.hotmail.com> wrote in message
news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com...[vbcol=seagreen]
> database file to the orginial location but only the MSDB was subspect
ed...|||Your best bet is to call PSS (http://support.microsoft.com) who will be able
to help you with this.
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:OMEBrpsJEHA.428@.TK2MSFTNGP11.phx.gbl...
> Probably because the database was damaged when you took the backup. Do you
perform regular DBCC checks against
> the MSDB database?
> You can always rebuild the system databases (rebuildm.exe). This is a
rather advanced option, don't do this
> unless you know what happens and how it work.
> Or perhaps use another SQL Server. Disconnect from network. Make sure you
have the same machine name. Install
> SQL Server. Make sure you select the same collation as the production
machine. Stop that SQL Server. Copy the
> files from the msdb database to the production SQL Server. You will of
course have an "empty" msdb database
> now. This should work, but is most probably not supported.
> Also, I think that you can run the script file which creates the msdb
database. You probably need to set some
> trace flag to allow you to drop the msdb database in the first place. This
could be documented in KB 224071.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Philip" <anonymous@.discussions.microsoft.com> wrote in message
> news:5ACC3100-003F-4686-9AC7-06603C8EB86E@.microsoft.com...
know why still subspected....[vbcol=seagreen]
like any other database when it[vbcol=seagreen]
> comes to
suspect database:[vbcol=seagreen]
> news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com...
subspect?[vbcol=seagreen]
in night and I have already copy the[vbcol=seagreen]
subspected...[vbcol=seagreen]
>|||Hi Tiber / Philip,
I have one more suggestion to this issue, I feel that during the MSDB mdf
and LDF physical file copy (cold Backup), they would have started the SQL
server service. In this case during MSDB startup the files may be used by
the backup process and startup would have been failed and marked the
database "Suspect".
If this case he can run the procedure sp_resetstaus <dbname> and restart sql
server service.
steps:
1.
Use Master
GO
EXEC sp_resetstatus <dbname>
2. Stop & Start the SQL Server
Thanks
Hari
MCDBA
2."Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in message news:OMEBrpsJEHA.428@.TK2MSFTNGP11.phx.gbl...
> Probably because the database was damaged when you took the backup. Do you
perform regular DBCC checks against
> the MSDB database?
> You can always rebuild the system databases (rebuildm.exe). This is a
rather advanced option, don't do this
> unless you know what happens and how it work.
> Or perhaps use another SQL Server. Disconnect from network. Make sure you
have the same machine name. Install
> SQL Server. Make sure you select the same collation as the production
machine. Stop that SQL Server. Copy the
> files from the msdb database to the production SQL Server. You will of
course have an "empty" msdb database
> now. This should work, but is most probably not supported.
> Also, I think that you can run the script file which creates the msdb
database. You probably need to set some
> trace flag to allow you to drop the msdb database in the first place. This
could be documented in KB 224071.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Philip" <anonymous@.discussions.microsoft.com> wrote in message
> news:5ACC3100-003F-4686-9AC7-06603C8EB86E@.microsoft.com...
know why still subspected....[vbcol=seagreen]
like any other database when it[vbcol=seagreen]
> comes to
suspect database:[vbcol=seagreen]
> news:A51A7CEF-958B-4911-B647-810C27A2DCE4@.microsoft.com...
subspect?[vbcol=seagreen]
in night and I have already copy the[vbcol=seagreen]
subspected...[vbcol=seagreen]
>
Subscribe to:
Posts (Atom)