 | |
#1
 
| |||
| |||
|
SDS best practice query -
05-26-2010
, 08:56 AM
#2
| |||
| |||
|
|
We're working with a customer to set up SDS. *It's going well. *Because it's little-used there's not a lot of user experience about, apart from the IBM documentation and some useful blogs. Can anyone advice about the placement of the SDS_TEMPDBS and SDS_PAGING files in an envrionment with SAN replication. *We assume that, like regular temp dbspaces, we should not replicate the SDS_TEMPDBS, but are less clear about the implications of placement for SDS_PAGING. *If we lose SDS_PAGING on a SDS secondary I guess we lose the secondary ...? Thanks |
thus do not have to be on the shared disk subsystem. Ideally they
would be on a locally attached disk subsystem.
The SDS_PAGEING files are used as a temporary storage for pages which
might need to be flushed to disk in between checkpoints. If we
subsequently need to read that page, we will reload it from the
SDS_PAGING file. When the checkpoint occurs, we are able to reset the
paging file so that we can start writing to it again.
Writes to the paging file might occur because the buffer has gotten
dirty. We invoke the page cleaners to perform LRU writes in that
case. But instead of writing to the chunk, we write to the paging
file. At the checkpoint, we can 'throw away' those pages in the
paging file because we have consistency with the primary. We require
two paging files in order to support non-blocking checkpoints on the
primary. Basically we swap the two paging files at the start of
checkpoint and reset the old paging file at the end of checkpoint.
#3
| |||
| |||
|
|
We're working with a customer to set up SDS. It's going well. Because it's little-used there's not a lot of user experience about, apart from the IBM documentation and some useful blogs. Can anyone advice about the placement of the SDS_TEMPDBS and SDS_PAGING files in an envrionment with SAN replication. We assume that, like regular temp dbspaces, we should not replicate the SDS_TEMPDBS, but are less clear about the implications of placement for SDS_PAGING. If we lose SDS_PAGING on a SDS secondary I guess we lose the secondary ...? Thanks The SDS_TEMPDBS and SDS_PAGING files are local to the instance and thus do not have to be on the shared disk subsystem. Ideally they |
The SDS_PAGEING files are used as a temporary storage for pages which
might need to be flushed to disk in between checkpoints. If we
subsequently need to read that page, we will reload it from the
SDS_PAGING file. When the checkpoint occurs, we are able to reset the
paging file so that we can start writing to it again.
Writes to the paging file might occur because the buffer has gotten
dirty. We invoke the page cleaners to perform LRU writes in that
case. But instead of writing to the chunk, we write to the paging
file. At the checkpoint, we can 'throw away' those pages in the
paging file because we have consistency with the primary. We requ
two paging files in order to support non-blocking checkpoints on the
primary. Basically we swap the two paging files at the start of
Quote:
|
checkpoint and reset the old paging file at the end of checkpoint. |
May I ask a supplementary?
In our config the Primary and SDS Secondary will actually be about 15km
distant, the "shared disk" element will be provided between the sites,
independent of IDS, by Veeritas CFS.
So from a bandwith point of view it would be better to hav the regulat temp
dbspaces also placed locally. But, how would an SDS secondary cope with
this? I guess it will be fine it is does not try to issue an open the the
temorary dbspaces until it is promoted to a Primary?
#4
| |||
| |||
|
|
"mpruet" <mpru... (AT) verizon (DOT) net> wrote in message news:e0c609d9-39d9-4082-b949-6771e3e7f5f7 (AT) u7g2000vbq (DOT) googlegroups.com... On May 26, 8:56 am, "Neil Truby" <neil.tr... (AT) ardenta (DOT) com> wrote: We're working with a customer to set up SDS. It's going well. Because it's little-used there's not a lot of user experience about, apart from the IBM documentation and some useful blogs. Can anyone advice about the placement of the SDS_TEMPDBS and SDS_PAGING files in an envrionment with SAN replication. We assume that, like regular temp dbspaces, we should not replicate the SDS_TEMPDBS, but are less clear about the implications of placement for SDS_PAGING. If we lose SDS_PAGING on a SDS secondary I guess we lose the secondary ...? Thanks The SDS_TEMPDBS and SDS_PAGING files are local to the instance and thus do not have to be on the shared disk subsystem. *Ideally they would be on a locally attached disk subsystem. The SDS_PAGEING files are used as a temporary storage for pages which might need to be flushed to disk in between checkpoints. If we subsequently need to read that page, we will reload it from the SDS_PAGING file. *When the checkpoint occurs, we are able to reset the paging file so that we can start writing to it again. Writes to the paging file might occur because the buffer has gotten dirty. *We invoke the page cleaners to perform LRU writes in that case. *But instead of writing to the chunk, we write to the paging file. *At the checkpoint, we can 'throw away' those pages in the paging file because we have consistency with the primary. *We requ two paging files in order to support non-blocking checkpoints on the primary. *Basically we swap the two paging files at the start of checkpoint and reset the old paging file at the end of checkpoint. Perfect, thanks. May I ask a supplementary? In our config the Primary and SDS Secondary will actually be about 15km distant, the "shared disk" element will be provided between the sites, independent of IDS, by Veeritas CFS. So from a *bandwith point of view it would be better to hav the regulattemp dbspaces also placed locally. *But, how would an SDS secondary cope with this? *I guess it will be fine it is does not try to issue an open the the temorary dbspaces until it is promoted to a Primary? |
"WAS_TEMPDBSPACE". It will not use that dbspace, but will only use
the SDS_TEMPDBS, even if it happens to be promoted to primary.
However, if it is bounced as a primary, then it will try to use the
configured temp dbspaces because it is not coming up as an SDS node.
#5
| |||
| |||
|
|
"mpruet" <mpru... (AT) verizon (DOT) net> wrote in message news:e0c609d9-39d9-4082-b949-6771e3e7f5f7 (AT) u7g2000vbq (DOT) googlegroups.com... On May 26, 8:56 am, "Neil Truby" <neil.tr... (AT) ardenta (DOT) com> wrote: We're working with a customer to set up SDS. It's going well. Because it's little-used there's not a lot of user experience about, apart from the IBM documentation and some useful blogs. Can anyone advice about the placement of the SDS_TEMPDBS and SDS_PAGING files in an envrionment with SAN replication. We assume that, like regular temp dbspaces, we should not replicate the SDS_TEMPDBS, but are less clear about the implications of placement for SDS_PAGING. If we lose SDS_PAGING on a SDS secondary I guess we lose the secondary ...? Thanks The SDS_TEMPDBS and SDS_PAGING files are local to the instance and thus do not have to be on the shared disk subsystem. *Ideally they would be on a locally attached disk subsystem. The SDS_PAGEING files are used as a temporary storage for pages which might need to be flushed to disk in between checkpoints. If we subsequently need to read that page, we will reload it from the SDS_PAGING file. *When the checkpoint occurs, we are able to reset the paging file so that we can start writing to it again. Writes to the paging file might occur because the buffer has gotten dirty. *We invoke the page cleaners to perform LRU writes in that case. *But instead of writing to the chunk, we write to the paging file. *At the checkpoint, we can 'throw away' those pages in the paging file because we have consistency with the primary. *We requ two paging files in order to support non-blocking checkpoints on the primary. *Basically we swap the two paging files at the start of checkpoint and reset the old paging file at the end of checkpoint. Perfect, thanks. May I ask a supplementary? In our config the Primary and SDS Secondary will actually be about 15km distant, the "shared disk" element will be provided between the sites, independent of IDS, by Veeritas CFS. So from a *bandwith point of view it would be better to hav the regulattemp dbspaces also placed locally. *But, how would an SDS secondary cope with this? *I guess it will be fine it is does not try to issue an open the the temorary dbspaces until it is promoted to a Primary? |
"WAS_TEMPDBSPACE".* It will not use that dbspace, but will only use
the SDS_TEMPDBS, even if it happens to be promoted to primary.
However, if it is bounced as a primary, then it will try to use the
configured temp dbspaces because it is not coming up as an SDS node.
_______________________________________________
Informix-list mailing list
Informix-list (AT) iiug (DOT) org
http://www.iiug.org/mailman/listinfo/informix-list
#6
| |||
| |||
|
|
"mpruet" <mpru... (AT) verizon (DOT) net> wrote in message The SDS_PAGEING files are used as a temporary storage for pages which might need to be flushed to disk in between checkpoints. If we subsequently need to read that page, we will reload it from the SDS_PAGING file. When the checkpoint occurs, we are able to reset the paging file so that we can start writing to it again. Writes to the paging file might occur because the buffer has gotten dirty. We invoke the page cleaners to perform LRU writes in that case. But instead of writing to the chunk, we write to the paging file. At the checkpoint, we can 'throw away' those pages in the paging file because we have consistency with the primary. We requ two paging files in order to support non-blocking checkpoints on the primary. Basically we swap the two paging files at the start of checkpoint and reset the old paging file at the end of checkpoint. Perfect, thanks. May I ask a supplementary? In our config the Primary and SDS Secondary will actually be about 15km distant, the "shared disk" element will be provided between the sites, independent of IDS, by Veeritas CFS. So from a bandwith point of view it would be better to hav the regulat temp dbspaces also placed locally. But, how would an SDS secondary cope with this? I guess it will be fine it is does not try to issue an open the the temorary dbspaces until it is promoted to a Primary? When the secondary starts up, it flags any temporary DBSPACE as "WAS_TEMPDBSPACE". It will not use that dbspace, but will only use |
However, if it is bounced as a primary, then it will try to use the
Quote:
|
.configured temp dbspaces because it is not coming up as an SDS node. |
my configuartion it would avoid a lot of unnecessary replication of the temp
dbspaces if they, live the SDS_ ones, could be held locally.
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.