Showing posts with label level. Show all posts
Showing posts with label level. 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;

Wednesday, March 21, 2012

db server slow - SET TRANSACTION LEVEL READ COMMITTED causing it?

Our entire server is extremely slow right now. We are getting locks left
and right. We've got locks on databases that we don't even use. When we
look at the activity and the locks that are taking the longest, we notice
that this statement is occurring over and over again:
SET TRANSACTION LEVEL READ COMMITTED
This is confusing to me because I thought this was the default? So I guess
I thought that this was being internally executed, or the equivalent, all
along. So, I don't know what to do or what to look at. Is there a setting
that could have been changed that would cause this behavior?
thanks,
Cory
Cory
> This is confusing to me because I thought this was the default?
Yes , it is
Do you have set SET TRANSACTION LEVEL READ COMMITTED in all stored
procedures. Its per connection ?
Try running SQL Server Profiler to see what is going on
"Cory Harrison" <charrison@.csiweb.com> wrote in message
news:uRW4%2370LHHA.536@.TK2MSFTNGP02.phx.gbl...
> Our entire server is extremely slow right now. We are getting locks left
> and right. We've got locks on databases that we don't even use. When we
> look at the activity and the locks that are taking the longest, we notice
> that this statement is occurring over and over again:
> SET TRANSACTION LEVEL READ COMMITTED
> This is confusing to me because I thought this was the default? So I
> guess I thought that this was being internally executed, or the
> equivalent, all along. So, I don't know what to do or what to look at.
> Is there a setting that could have been changed that would cause this
> behavior?
>
> thanks,
> Cory
>
>

db server slow - SET TRANSACTION LEVEL READ COMMITTED causing it?

Our entire server is extremely slow right now. We are getting locks left
and right. We've got locks on databases that we don't even use. When we
look at the activity and the locks that are taking the longest, we notice
that this statement is occurring over and over again:
SET TRANSACTION LEVEL READ COMMITTED
This is confusing to me because I thought this was the default? So I guess
I thought that this was being internally executed, or the equivalent, all
along. So, I don't know what to do or what to look at. Is there a setting
that could have been changed that would cause this behavior?
thanks,
CoryCory
> This is confusing to me because I thought this was the default?
Yes , it is
Do you have set SET TRANSACTION LEVEL READ COMMITTED in all stored
procedures. Its per connection ?
Try running SQL Server Profiler to see what is going on
"Cory Harrison" <charrison@.csiweb.com> wrote in message
news:uRW4%2370LHHA.536@.TK2MSFTNGP02.phx.gbl...
> Our entire server is extremely slow right now. We are getting locks left
> and right. We've got locks on databases that we don't even use. When we
> look at the activity and the locks that are taking the longest, we notice
> that this statement is occurring over and over again:
> SET TRANSACTION LEVEL READ COMMITTED
> This is confusing to me because I thought this was the default? So I
> guess I thought that this was being internally executed, or the
> equivalent, all along. So, I don't know what to do or what to look at.
> Is there a setting that could have been changed that would cause this
> behavior?
>
> thanks,
> Cory
>
>

db server slow - SET TRANSACTION LEVEL READ COMMITTED causing it?

Our entire server is extremely slow right now. We are getting locks left
and right. We've got locks on databases that we don't even use. When we
look at the activity and the locks that are taking the longest, we notice
that this statement is occurring over and over again:
SET TRANSACTION LEVEL READ COMMITTED
This is confusing to me because I thought this was the default? So I guess
I thought that this was being internally executed, or the equivalent, all
along. So, I don't know what to do or what to look at. Is there a setting
that could have been changed that would cause this behavior?
thanks,
CoryCory
> This is confusing to me because I thought this was the default?
Yes , it is
Do you have set SET TRANSACTION LEVEL READ COMMITTED in all stored
procedures. Its per connection ?
Try running SQL Server Profiler to see what is going on
"Cory Harrison" <charrison@.csiweb.com> wrote in message
news:uRW4%2370LHHA.536@.TK2MSFTNGP02.phx.gbl...
> Our entire server is extremely slow right now. We are getting locks left
> and right. We've got locks on databases that we don't even use. When we
> look at the activity and the locks that are taking the longest, we notice
> that this statement is occurring over and over again:
> SET TRANSACTION LEVEL READ COMMITTED
> This is confusing to me because I thought this was the default? So I
> guess I thought that this was being internally executed, or the
> equivalent, all along. So, I don't know what to do or what to look at.
> Is there a setting that could have been changed that would cause this
> behavior?
>
> thanks,
> Cory
>
>sql

Wednesday, March 7, 2012

DB Mirroring question

Hi everyone,
I have a quick question. Can I use DB mirroring if the database is set
to SQL 2000 compatibility level?
TIA,
JoeHi
Yes, it works and is supported.
8.0 compatibility level only determines how queries run against the DB, and
not the DB structure itself.
Regards
--
Mike
This posting is provided "AS IS" with no warranties, and confers no rights.
"Joe D" <jkdriscoll@.qg.com> wrote in message
news:ea2id3$24pd$1@.sxnews1.qg.com...
> Hi everyone,
> I have a quick question. Can I use DB mirroring if the database is set
> to SQL 2000 compatibility level?
> TIA,
> Joe
>

Sunday, February 19, 2012

db mail with encryption

hi,
Is there anyway to do an encryption for any emails by using send db mail?
Do i need to do the encryption at the database level or exchange server level?
Any idea, please help.
Thanks
Ed
See other post!
"Ed" wrote:

> hi,
> Is there anyway to do an encryption for any emails by using send db mail?
> Do i need to do the encryption at the database level or exchange server level?
> Any idea, please help.
> Thanks
> Ed

db mail with encryption

hi,
Is there anyway to do an encryption for any emails by using send db mail?
Do i need to do the encryption at the database level or exchange server leve
l?
Any idea, please help.
Thanks
EdSee other post!
"Ed" wrote:

> hi,
> Is there anyway to do an encryption for any emails by using send db mail
?
> Do i need to do the encryption at the database level or exchange server le
vel?
> Any idea, please help.
> Thanks
> Ed

db mail with encryption

hi,
Is there anyway to do an encryption for any emails by using send db mail?
Do i need to do the encryption at the database level or exchange server level?
Any idea, please help.
Thanks
EdSee other post!
"Ed" wrote:
> hi,
> Is there anyway to do an encryption for any emails by using send db mail?
> Do i need to do the encryption at the database level or exchange server level?
> Any idea, please help.
> Thanks
> Ed