Showing posts with label original. Show all posts
Showing posts with label original. Show all posts

Sunday, March 25, 2012

DB_ID() Replacement

In the BOL, it states to replace DB_ID() with a valid database name when the compatibility level is 80 or below.

The original statement is:

SELECT

object_id AS objectid,

index_id AS indexid,

partition_number AS partitionnum,

avg_fragmentation_in_percent AS frag

INTO #work_to_do

FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, 'LIMITED')

WHERE avg_fragmentation_in_percent > 10.0 AND index_id > 0;

I replaced DB_ID() as follows but none worked:

DB_ID(N'pubs')
pubs

What should the syntax look like?

I tried to run the following and it worked for me:

SELECT object_id AS objectid,

index_id AS indexid,

partition_number AS partitionnum,

avg_fragmentation_in_percent

AS frag

INTO #work_to_do FROM sys.dm_db_index_physical_stats (DB_ID( N'AdventureWorks'), NULL, NULL , NULL, 'LIMITED')

WHERE avg_fragmentation_in_percent > 10.0 AND index_id > 0;

|||

The BOL statement indicates the following issue:

If database is in 80 or earlier compat mode, certain newer features or syntax or keywords will not work. In this specific example, the ability to pass expressions as parameter values to TVFs is not possible if the database is below 90 compat mode. You will get a syntax error actually. So you have three alternatives to make it work:

1. Run the statement from a database that is in 90 compat mode. You can then do:

SELECT object_id AS objectid, index_id AS indexid, partition_number AS partitionnum, avg_fragmentation_in_percent AS frag

INTO #work_to_do

FROM pubs.sys.dm_db_index_physical_stats (DB_ID('pubs'), NULL, NULL , NULL, 'LIMITED')

WHERE avg_fragmentation_in_percent > 10.0 AND index_id > 0;


2. Or specify the database id explicitly like (will work in db with any compat mode):

SELECT object_id AS objectid, index_id AS indexid, partition_number AS partitionnum, avg_fragmentation_in_percent AS frag

INTO #work_to_do

FROM pubs.sys.dm_db_index_physical_stats (14, NULL, NULL , NULL, 'LIMITED')

WHERE avg_fragmentation_in_percent > 10.0 AND index_id > 0;

-- or

use pubs

go

SELECT object_id AS objectid, index_id AS indexid, partition_number AS partitionnum, avg_fragmentation_in_percent AS frag

INTO #work_to_do

FROM sys.dm_db_index_physical_stats (14, NULL, NULL , NULL, 'LIMITED')

WHERE avg_fragmentation_in_percent > 10.0 AND index_id > 0;

3. Or use variable to specify the database id like (will work in db with any compat mode):

declare @.dbid int;

set @.dbid = db_id('pubs');

SELECT object_id AS objectid, index_id AS indexid, partition_number AS partitionnum, avg_fragmentation_in_percent AS frag

INTO #work_to_do

FROM pubs.sys.dm_db_index_physical_stats (@.dbid, NULL, NULL , NULL, 'LIMITED')

WHERE avg_fragmentation_in_percent > 10.0 AND index_id > 0;

--or

use pubs

go

declare @.dbid int;

set @.dbid = db_id('pubs');

SELECT object_id AS objectid, index_id AS indexid, partition_number AS partitionnum, avg_fragmentation_in_percent AS frag

INTO #work_to_do

FROM sys.dm_db_index_physical_stats (@.dbid, NULL, NULL , NULL, 'LIMITED')

WHERE avg_fragmentation_in_percent > 10.0 AND index_id > 0;

Sunday, March 11, 2012

DB recovery

Since my client's log file is going extremely large, I
DETACH the database,
delete the .LDF file, and ATTACH the database from the
original file. This
method worked in the past, but this time when I tried to
ATTACH the
database, it prompts 'ERROR: 1813, unable to create
database' something like
that (I tried to translate it since it is a Chinese SQL
server). It seems
the original .MDF file has corrupted. Now, I have with me
is the original
..MDF file, what can I do?
TonyYou shouldn't have deleted the log file in the first place. When SQL Server starts it performs
recovery for each database, where it reads through the log and synchronizes the modifications in the
log to the database. Imagine what happen if the log isn't there!
In some situations, where there is not recovery to perform, SQL Server can happily create a new log
file for you, but how would you know that this is what will happen if you delete the log file? You
can't.
Deleting the log file is an extremely unsafe method to re-claim HD space.
I suggest that you restore from the latest clean backup. That is the only way to get a consistent
database back. If that isn't an option, let MS help you though this situation as they might have
tools/commands to save what can be saved.
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Tony Lam" <anonymous@.discussions.microsoft.com> wrote in message
news:006b01c3ba1c$e534a8b0$a001280a@.phx.gbl...
> Since my client's log file is going extremely large, I
> DETACH the database,
> delete the .LDF file, and ATTACH the database from the
> original file. This
> method worked in the past, but this time when I tried to
> ATTACH the
> database, it prompts 'ERROR: 1813, unable to create
> database' something like
> that (I tried to translate it since it is a Chinese SQL
> server). It seems
> the original .MDF file has corrupted. Now, I have with me
> is the original
> ..MDF file, what can I do?
> Tony
>|||sorry to contridict you Tibor (I bow to your superior knowledge), but
detaching the database (in situations where there is only ONE logfile)
causes it to be shutdown cleanly meaning that the current logfile is
not needed for the reattach operation. I agree with you that deleting
it is perhaps best advised against until a successful reattach (simply
rename it).
Kalen mentions this tip in her Inside SQL 2K book (Chpt 5,Other
Database Considerations).
Let me know if the current thinking has changed on doing this (either
by MS or the SQL professionals).
Br,
Mark Broadbent
mcdba , mcse+i
=============|||Mark,
> sorry to contridict you Tibor
No problem, one of the best way to learn things IMO...
> (I bow to your superior knowledge),
LOL... :-)
> but
> detaching the database (in situations where there is only ONE logfile)
> causes it to be shutdown cleanly meaning that the current logfile is
> not needed for the reattach operation.
Ahh, I didn't read the OP that close. IIRC, the doc's states that you can do this if you have only
one log file *and* only one data file. And then use sp_attach_single_file_db. If this is what Tony
did, then SQL Server didn't behave as per the documentation. I agree with that. :-)
Personally, I still don't feel comfortable doing this unless I have very good backup etc to fallback
on.
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Mark Broadbent" <no-spam-please_mark.broadbent@.virgin.net> wrote in message
news:Oo0LjdmuDHA.2304@.TK2MSFTNGP12.phx.gbl...
> sorry to contridict you Tibor (I bow to your superior knowledge), but
> detaching the database (in situations where there is only ONE logfile)
> causes it to be shutdown cleanly meaning that the current logfile is
> not needed for the reattach operation. I agree with you that deleting
> it is perhaps best advised against until a successful reattach (simply
> rename it).
> Kalen mentions this tip in her Inside SQL 2K book (Chpt 5,Other
> Database Considerations).
> Let me know if the current thinking has changed on doing this (either
> by MS or the SQL professionals).
>
> --
> Br,
> Mark Broadbent
> mcdba , mcse+i
> =============|||Full Backup always a good idea @.:-)
Amen to that!
--
Br,
Mark Broadbent
mcdba , mcse+i
=============

Thursday, March 8, 2012

DB Performance Issue

Hi,
Sorry to cross post but I think the original post is in the wrong
group. Could anybody take a look at this:
http://groups.google.co.uk/group/comp.databases.ms-sqlserver/browse_frm/thread/e54b8addadb0ffe7?hl=en
and see if they have any ideas?
Thanks very much,
Paul
Hi Robert,
Thanks for suggesting this, I suspected it may be the disk but wasn't
really in a position to check this at the time. It appears that it was
a problem with a RAID card that was installed on the machine. This how
been removed and it is now business as usual!
Thanks,
Paul
On 23 Jan, 17:54, Robert Klemme <shortcut...@.googlemail.com> wrote:
> On 23.01.2007 17:19, paulwragg2...@.hotmail.com wrote:
>
> statistics not up to date? More load on that machine (web server, other
> database getting traffic)?
> Regards
> robert

DB Performance Issue

Hi,
Sorry to cross post but I think the original post is in the wrong
group. Could anybody take a look at this:
http://groups.google.co.uk/group/co...dadb0ffe7?hl=en
and see if they have any ideas?
Thanks very much,
PaulOn 23.01.2007 17:19, paulwragg2323@.hotmail.com wrote:
> Could anybody take a look at this:
> http://groups.google.co.uk/group/co...dadb0ffe7?hl=en
> and see if they have any ideas?
Just a few to start: Different DB settings (mem, concurrency...)? DB
statistics not up to date? More load on that machine (web server, other
database getting traffic)?
Regards
robert|||Hi Robert,
Thanks for suggesting this, I suspected it may be the disk but wasn't
really in a position to check this at the time. It appears that it was
a problem with a RAID card that was installed on the machine. This how
been removed and it is now business as usual!
Thanks,
Paul
On 23 Jan, 17:54, Robert Klemme <shortcut...@.googlemail.com> wrote:
> On 23.01.2007 17:19, paulwragg2...@.hotmail.com wrote:
>
>
>
> statistics not up to date? More load on that machine (web server, other
> database getting traffic)?
> Regards
> robert

DB Performance Issue

Hi,
Sorry to cross post but I think the original post is in the wrong
group. Could anybody take a look at this:
http://groups.google.co.uk/group/comp.databases.ms-sqlserver/browse_frm/thread/e54b8addadb0ffe7?hl=en
and see if they have any ideas?
Thanks very much,
PaulOn 23.01.2007 17:19, paulwragg2323@.hotmail.com wrote:
> Could anybody take a look at this:
> http://groups.google.co.uk/group/comp.databases.ms-sqlserver/browse_frm/thread/e54b8addadb0ffe7?hl=en
> and see if they have any ideas?
Just a few to start: Different DB settings (mem, concurrency...)? DB
statistics not up to date? More load on that machine (web server, other
database getting traffic)?
Regards
robert|||Hi Robert,
Thanks for suggesting this, I suspected it may be the disk but wasn't
really in a position to check this at the time. It appears that it was
a problem with a RAID card that was installed on the machine. This how
been removed and it is now business as usual!
Thanks,
Paul
On 23 Jan, 17:54, Robert Klemme <shortcut...@.googlemail.com> wrote:
> On 23.01.2007 17:19, paulwragg2...@.hotmail.com wrote:
> > Could anybody take a look at this:
> >http://groups.google.co.uk/group/comp.databases.ms-sqlserver/browse_f...
> > and see if they have any ideas?Just a few to start: Different DB settings (mem, concurrency...)? DB
> statistics not up to date? More load on that machine (web server, other
> database getting traffic)?
> Regards
> robert

Friday, February 17, 2012

DB in "loading" state - error 22274

We had a situation where we had to restore one of our SQL
databases to the same server the original was running on.
We restored using Arcserve 2000 w/ SQL Agent and it
completed successfully to a different name & directory.
Name of DB was RES_LAW & we had the .mdf & .ldf files
named differently then the originals and in a different
folder.
Arcserve finished the restore successfully with no errors.
When you go into Enterprise Manager the database is there
but shows up GRAY and says "loading" underneath it. When
you double-click to expand properties, you get two errors:
1. error 22274 [SQL-DMO]This Database has been marked
inaccessible (then when you click OK, you get...)
2. Could not get property information for the
database "res_law"
Then it closes.
Does anyone know what is wrong or what we should do?
Computer Associates (maker of Arcserve, said it's not
their problem)
Any help is greatly appreciated.It may just need to be recovered. From Query Analyzer,
execute the following:
RESTORE DATABASE yourDB WITH RECOVERY
>Does anyone know what is wrong or what we should do?
>Computer Associates (maker of Arcserve, said it's not
>their problem)
Sounds familiar and you have my sympathy.
Linchi
>--Original Message--
>We had a situation where we had to restore one of our SQL
>databases to the same server the original was running
on.
>We restored using Arcserve 2000 w/ SQL Agent and it
>completed successfully to a different name & directory.
>Name of DB was RES_LAW & we had the .mdf & .ldf files
>named differently then the originals and in a different
>folder.
>Arcserve finished the restore successfully with no errors.
>When you go into Enterprise Manager the database is there
>but shows up GRAY and says "loading" underneath it. When
>you double-click to expand properties, you get two errors:
>1. error 22274 [SQL-DMO]This Database has been marked
>inaccessible (then when you click OK, you get...)
>2. Could not get property information for the
>database "res_law"
>Then it closes.
>Does anyone know what is wrong or what we should do?
>Computer Associates (maker of Arcserve, said it's not
>their problem)
>Any help is greatly appreciated.
>
>.
>

DB in "loading" state - error 22274

We had a situation where we had to restore one of our SQL
databases to the same server the original was running on.
We restored using Arcserve 2000 w/ SQL Agent and it
completed successfully to a different name & directory.
Name of DB was RES_LAW & we had the .mdf & .ldf files
named differently then the originals and in a different
folder.
Arcserve finished the restore successfully with no errors.
When you go into Enterprise Manager the database is there
but shows up GRAY and says "loading" underneath it. When
you double-click to expand properties, you get two errors:
1. error 22274 [SQL-DMO]This Database has been marked
inaccessible (then when you click OK, you get...)
2. Could not get property information for the
database "res_law"
Then it closes.
Does anyone know what is wrong or what we should do?
Computer Associates (maker of Arcserve, said it's not
their problem)
Any help is greatly appreciated.It may just need to be recovered. From Query Analyzer,
execute the following:
RESTORE DATABASE yourDB WITH RECOVERY
quote:

>Does anyone know what is wrong or what we should do?
>Computer Associates (maker of Arcserve, said it's not
>their problem)

Sounds familiar and you have my sympathy.
Linchi
quote:

>--Original Message--
>We had a situation where we had to restore one of our SQL
>databases to the same server the original was running

on.
quote:

>We restored using Arcserve 2000 w/ SQL Agent and it
>completed successfully to a different name & directory.
>Name of DB was RES_LAW & we had the .mdf & .ldf files
>named differently then the originals and in a different
>folder.
>Arcserve finished the restore successfully with no errors.
>When you go into Enterprise Manager the database is there
>but shows up GRAY and says "loading" underneath it. When
>you double-click to expand properties, you get two errors:
>1. error 22274 [SQL-DMO]This Database has been marked
>inaccessible (then when you click OK, you get...)
>2. Could not get property information for the
>database "res_law"
>Then it closes.
>Does anyone know what is wrong or what we should do?
>Computer Associates (maker of Arcserve, said it's not
>their problem)
>Any help is greatly appreciated.
>
>.
>