ADSM-L

Re: @Sparrman: mirrorwritedb parallel - tried it?

2005-08-01 05:53:33
Subject: Re: @Sparrman: mirrorwritedb parallel - tried it?
From: Maurice van 't Loo <tsm AT COMPARECOMPUTERS DOT NL>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 1 Aug 2005 11:53:24 +0200
Thanks for the clear and complete answer.
I shall try it also over here :-) (53GB DB)

Regards,
Maurice

----- Original Message ----- 
From: "Daniel Sparrman" <Daniel.Sparrman AT EXIST DOT SE>
To: <ADSM-L AT VM.MARIST DOT EDU>
Sent: Monday, August 01, 2005 11:20 AM
Subject: Re: [ADSM-L] @Sparrman: mirrorwritedb parallel - tried it?


No, thats not correct. The pageshadowfile is used to store the database
entry until it has been commited to all database volumes so in that way
you are protected against partial writes. The write to the pageshadow file
is not sequntial, the write is written to the pageshadowfile at the same
time the write it sent to your datbase copies and stored there until a
commit has been recieved from every database copy.

Btw, you cannot even use pageshadowing unless you have enabled parallel
write against the database volumes.

>From the TSM manual (ref:
http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/topic/com.ibm.itsmaixn.doc/anrarf53499.htm):

"Specifies whether database page shadowing is enabled. If database page
shadowing is enabled, Tivoli Storage Manager mirrors every write to a
database page. You can enable shadowing only if database volume mirrors
are written to in parallel (that is, the MIRRORWRITE DB option is set to
PARALLEL). The default is YES. For more information on specifying
mirroring and database page shadowing server options, see " Protecting and
Recovering Your Server" in the Administrator's Guide."

>From the Administrator's Guide; "Protecting and Recovering Your Server"
(ref:
http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/topic/com.ibm.itsmaixn.doc/anragd53701.htm):

"MIRRORWRITE specifies how mirrored volumes are written to. You may issue
MIRRORWRITE LOG or DB, and then specify that write operations for the
database and the recovery log be specified as SEQUENTIAL or PARALLEL:
A PARALLEL specification offers better performance but at the potential
cost of recoverability. Pages are written to all copies at about the same
time. If a system outage results in a partial page write and the outage
affects both mirrored copies, then both copies could be corrupted.
A SEQUENTIAL specification offers improved recoverability but at the cost
of performance. Pages are written to one copy at a time. If a system
outage results in a partial page write, only one copy is affected.
However, because a successful I/O must be completed after the write to the
first copy but before the write to the second copy, performance can be
affected."

"DBPAGESHADOW=YES mirrors the latest batch of pages written to a database.
In this way if an outage occurs that affects both mirrored volumes, the
server can recover pages that have been partially written. If no name is
specified in the DBPAGESHADOWFILE option, a dbpgshdw.bdt file will be
created and used. If the DBPAGESHADOWFILE option specifies a file name,
that file name will be used. "

Best Regards

Daniel Sparrman
-----------------------------------
Daniel Sparrman
Utvecklingschef
Exist i Stockholm AB
Propellervägen 6B
183 62 TÄBY
Växel: 08 - 754 98 00
Mobil: 070 - 399 27 51



Maurice van 't Loo <tsm AT COMPARECOMPUTERS DOT NL>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
2005-08-01 11:01
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
@Sparrman:  mirrorwritedb parallel - tried it?






----- Original Message -----
From: "Daniel Sparrman" <Daniel.Sparrman AT EXIST DOT SE>
To: <ADSM-L AT VM.MARIST DOT EDU>
Sent: Monday, August 01, 2005 9:31 AM
Subject: Re: [ADSM-L] mirrorwritedb parallel - tried it?


*cut*

The security risk is mainly in a scenario were TSM writes to both of the
db volumes and crashes at the same time. This could result in a partial
write = database restore. To avoid this security issue when using parallel
writes, enable pageshadowing with "dbpageshadow yes" and "dbpageshadowfile
FILENAME". The pageshadowfile should preferable be placed on separate
disks from the TSM database volumes.

*cut*

If you use parallel writes and dbpageshadow, aren't you do sequential
writing again?
As far as i know, dbpageshadow is used with hardware-mirror in stead of
TSM-mirror, so there is still a sequential write possible.
So if you use parallel writes for a better performance and use
dbpageshadow,
you still use sequential writes between the real db and the shadow and
lose
the performance bennefit.

Regards,
Maurice

<Prev in Thread] Current Thread [Next in Thread>