Autonumber field: secondary

Showing posts with label secondary. Show all posts

Tuesday, March 27, 2012

Backing up secondary DB in log shipping ...

Hello can someone clear this up for me?
In BOL "Log Shipping Tips and Best Practices" is the following
recommendation:
"Generating Database Backups from the Secondary
Since the log shipped database is only a small increment of time out
of sync with the primary database, it is a good idea to use it to
generate the full database backups. This would keep the primary
production server free of the potential overhead and contention
incurred by a daily (or scheduled) backup. "
In my experience and from searching other threads in this group this
is actually not true - backing up the log shipped database will not
work, it will fail with the error:
"Database is in warm-standby state (set by executing RESTORE WITH
STANDBY) and cannot be backed up until the entire load sequence is
completed."
Am I missing something or is BOL just being misleading?
thanks,
PeterPeter,
http://support.microsoft.com/kb/311115 contains the correction.
Note: With SQL Server 2005, you it might be possible to create a snapshot
database over the secondary and back that up. (But I have no experience
with trying.)
RLF
<peter.wismer@.gmail.com> wrote in message
news:1187280994.613717.77730@.l22g2000prc.googlegroups.com...
> Hello can someone clear this up for me?
> In BOL "Log Shipping Tips and Best Practices" is the following
> recommendation:
> "Generating Database Backups from the Secondary
> Since the log shipped database is only a small increment of time out
> of sync with the primary database, it is a good idea to use it to
> generate the full database backups. This would keep the primary
> production server free of the potential overhead and contention
> incurred by a daily (or scheduled) backup. "
> In my experience and from searching other threads in this group this
> is actually not true - backing up the log shipped database will not
> work, it will fail with the error:
> "Database is in warm-standby state (set by executing RESTORE WITH
> STANDBY) and cannot be backed up until the entire load sequence is
> completed."
> Am I missing something or is BOL just being misleading?
> thanks,
> Peter
>|||On Aug 16, 1:12 pm, "Russell Fields" <russellfie...@.nomail.com> wrote:
> Peter,
> http://support.microsoft.com/kb/311115contains the correction.
> Note: With SQL Server 2005, you it might be possible to create a snapshot
> database over the secondary and back that up. (But I have no experience
> with trying.)
> RLF<peter.wis...@.gmail.com> wrote in message
> news:1187280994.613717.77730@.l22g2000prc.googlegroups.com...
>
> > Hello can someone clear this up for me?
> > In BOL "Log Shipping Tips and Best Practices" is the following
> > recommendation:
> > "Generating Database Backups from the Secondary
> > Since the log shipped database is only a small increment of time out
> > of sync with the primary database, it is a good idea to use it to
> > generate the full database backups. This would keep the primary
> > production server free of the potential overhead and contention
> > incurred by a daily (or scheduled) backup. "
> > In my experience and from searching other threads in this group this
> > is actually not true - backing up the log shipped database will not
> > work, it will fail with the error:
> > "Database is in warm-standby state (set by executing RESTORE WITH
> > STANDBY) and cannot be backed up until the entire load sequence is
> > completed."
> > Am I missing something or is BOL just being misleading?
> > thanks,
> > Peter- Hide quoted text -
> - Show quoted text -
Thanks very much Russell (I was beginning to mistrust my command of
the english language - thought I might need to find a Canadian
translation of BOL...)
Peter|||I think it was a case of wishes versus reality. - RLF
<peter.wismer@.gmail.com> wrote in message
news:1187288061.528821.290710@.j4g2000prf.googlegroups.com...
> On Aug 16, 1:12 pm, "Russell Fields" <russellfie...@.nomail.com> wrote:
>> Peter,
>> http://support.microsoft.com/kb/311115contains the correction.
>> Note: With SQL Server 2005, you it might be possible to create a snapshot
>> database over the secondary and back that up. (But I have no experience
>> with trying.)
>> RLF<peter.wis...@.gmail.com> wrote in message
>> news:1187280994.613717.77730@.l22g2000prc.googlegroups.com...
>>
>> > Hello can someone clear this up for me?
>> > In BOL "Log Shipping Tips and Best Practices" is the following
>> > recommendation:
>> > "Generating Database Backups from the Secondary
>> > Since the log shipped database is only a small increment of time out
>> > of sync with the primary database, it is a good idea to use it to
>> > generate the full database backups. This would keep the primary
>> > production server free of the potential overhead and contention
>> > incurred by a daily (or scheduled) backup. "
>> > In my experience and from searching other threads in this group this
>> > is actually not true - backing up the log shipped database will not
>> > work, it will fail with the error:
>> > "Database is in warm-standby state (set by executing RESTORE WITH
>> > STANDBY) and cannot be backed up until the entire load sequence is
>> > completed."
>> > Am I missing something or is BOL just being misleading?
>> > thanks,
>> > Peter- Hide quoted text -
>> - Show quoted text -
> Thanks very much Russell (I was beginning to mistrust my command of
> the english language - thought I might need to find a Canadian
> translation of BOL...)
> Peter
>

Backing up secondary DB in log shipping ...

Thursday, March 22, 2012

Backing up a restoring or standby database

Hi,
I would like to backup a secondary log shippping database (in restoring or
standby mode). I need to use the backup as an up to date test database on the
same server but don't have the bandwidth to copy the primary backups over.
I've tried the backup command which results in an error saying that the
restore sequence must be completed first.
I also tried detaching the database with a view to copying the files but
when attempting to attach it again sql server produced another restore
sequence error.
Anyone know if it is possible to do a backup of a log shipping secondary, by
foul means or fair?
Cheers,
Kev.
You'd have to use recovery to be able to do the backup but this'd invalidate
the log-shipping chain. for a test database you might roll your own 'database
shipping' solution which is something a few people on this newsgroup seem to
be using...
HTH,
Paul Ibison
|||Okay, thanks.
Kev.
"Paul Ibison" wrote:

> You'd have to use recovery to be able to do the backup but this'd invalidate
> the log-shipping chain. for a test database you might roll your own 'database
> shipping' solution which is something a few people on this newsgroup seem to
> be using...
> HTH,
> Paul Ibison
>

Friday, February 10, 2012

Autonumbering causing deadlocks.

Gents,

I have come into a system that uses a secondary table to generate (for
want of a better word) Identities.

create table myidents
( name sysname not null, ident int not null)

create procedure getnextident @.table sysname, @.ident int output
as
begin
if not exists (select top 1 1 from myidents where name = @.table)
insert into myidents values (@.table, 0)

update myidents
set @.ident = ident = ident + 1
where name = @.table
end

now, (ignoring for now the use of reserved words) the problem is that
this is called frequently, from other procedures. Trouble is that the
calling procedures call it from within a transaction. We now have a
wickedly hot spot on this table, with frequent deadlocks.

Is there any relatively quick fix for this? Some locking hints or
whatever.

Or do we need to go and recode, moving this kind of thing outside the
transaction (which are all rather too long for my liking), and even
cosidering using identity columns as a replacement?

ThanksIMHO, IDENTITY would be the best approach with the current design. You
might also consider using natural keys instead of surrogate key values.

If your actual myident table has no primary key on name, this will
contribute to blocking/deadlocking. Unless your application always acquires
values in the same sequence, you will be vulnerable to deadlocks unless you
specify a TABLOCKX hint. This is obviously bad for concurrency (especially
for long-running transactions) and should be avoided if possible.

--
Hope this helps.

Dan Guzman
SQL Server MVP

if not exists (select top 1 1 from myidents ROWLOCK, UPDLOCK where name =
@.table)

Hope it will help.

Igor

"WangKhar" <Wangkhar@.yahoo.com> wrote in message
news:bb269444.0401220321.38788fa2@.posting.google.c om...
> Gents,
> I have come into a system that uses a secondary table to generate (for
> want of a better word) Identities.
> eg
> create table myidents
> ( name sysname not null, ident int not null)
> create procedure getnextident @.table sysname, @.ident int output
> as
> begin
> if not exists (select top 1 1 from myidents where name = @.table)
> insert into myidents values (@.table, 0)
> update myidents
> set @.ident = ident = ident + 1
> where name = @.table
> end
> now, (ignoring for now the use of reserved words) the problem is that
> this is called frequently, from other procedures. Trouble is that the
> calling procedures call it from within a transaction. We now have a
> wickedly hot spot on this table, with frequent deadlocks.
> Is there any relatively quick fix for this? Some locking hints or
> whatever.
> Or do we need to go and recode, moving this kind of thing outside the
> transaction (which are all rather too long for my liking), and even
> cosidering using identity columns as a replacement?
> Thanks|||WangKhar (Wangkhar@.yahoo.com) writes:
> create procedure getnextident @.table sysname, @.ident int output
> as
> begin
> if not exists (select top 1 1 from myidents where name = @.table)
> insert into myidents values (@.table, 0)
> update myidents
> set @.ident = ident = ident + 1
> where name = @.table
> end
> now, (ignoring for now the use of reserved words) the problem is that
> this is called frequently, from other procedures. Trouble is that the
> calling procedures call it from within a transaction. We now have a
> wickedly hot spot on this table, with frequent deadlocks.
> Is there any relatively quick fix for this? Some locking hints or
> whatever.

Deadlocks can usually be avoided by:

BEGIN TRANSACTION

SELECT @.ident = ident FROM tbl (UPDLOCK) WHERE name = @.table
UPDATE tbl SET ident = @.ident WHERE name = @.table

COMMIT TRANSACTION

However, if you have more work in the transaction, you will have lot of
blocking and not much concurrency in the system. And if you in some
procedures perform work before you come here, they might be blocking
other processes that aleady have an ident, and now wil block the other
prcoess.

The above is only really meaningful if you have busienss rules that
require consecutive series. Else you should move out the ident-generation
out of the transaction or use IDENTITY instead.

--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Thanks thats pretty much what I thought ...

See if I can convince people that we need to take this action :(

Erland Sommarskog <sommar@.algonet.se> wrote in message news:<Xns94794AA4B719Yazorman@.127.0.0.1>...
> WangKhar (Wangkhar@.yahoo.com) writes:
> > create procedure getnextident @.table sysname, @.ident int output
> > as
> > begin
> > if not exists (select top 1 1 from myidents where name = @.table)
> > insert into myidents values (@.table, 0)
> > update myidents
> > set @.ident = ident = ident + 1
> > where name = @.table
> > end
> > now, (ignoring for now the use of reserved words) the problem is that
> > this is called frequently, from other procedures. Trouble is that the
> > calling procedures call it from within a transaction. We now have a
> > wickedly hot spot on this table, with frequent deadlocks.
> > Is there any relatively quick fix for this? Some locking hints or
> > whatever.
> Deadlocks can usually be avoided by:
> BEGIN TRANSACTION
> SELECT @.ident = ident FROM tbl (UPDLOCK) WHERE name = @.table
> UPDATE tbl SET ident = @.ident WHERE name = @.table
> COMMIT TRANSACTION
> However, if you have more work in the transaction, you will have lot of
> blocking and not much concurrency in the system. And if you in some
> procedures perform work before you come here, they might be blocking
> other processes that aleady have an ident, and now wil block the other
> prcoess.
> The above is only really meaningful if you have busienss rules that
> require consecutive series. Else you should move out the ident-generation
> out of the transaction or use IDENTITY instead.

Tuesday, March 27, 2012

Backing up secondary DB in log shipping ...

Backing up secondary DB in log shipping ...

Backing up secondary DB in log shipping ...

Thursday, March 22, 2012

Backing up a restoring or standby database

Friday, February 10, 2012

Autonumbering causing deadlocks.

Autonumber field

Blog Archive

About Me