SDS best practice query
Question about where to place SDS_TEMPDBS and SDS_PAGING files when a primary and SDS secondary are ~15km apart with shared disk provided by Veritas CFS, and whether losing SDS_PAGING kills the secondary. mpruet (IBM) explained both are local to each instance and need not be on shared/replicated disk — ideally on locally attached disk; SDS_PAGING holds pages flushed between checkpoints (two files allow non-blocking checkpoints) and is reset at checkpoint. He added that an SDS secondary marks configured temp dbspaces WAS_TEMPDBSPACE and uses only SDS_TEMPDBS, even after promotion, though a restart as primary would use the configured temp dbspaces. A follow-up asking about non-journaling filesystems, and Neil's final question on whether temp dbspaces must be on shared disk, went unanswered.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
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
On May 26, 8:56 am, "Neil Truby" <neil.tr...@ardenta.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 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.
"mpruet" <mpruet1@verizon.net> wrote in message news:e0c609d9-39d9-4082-b949-6771e3e7f5f7@u7g2000vbq.googlegroups.com... On May 26, 8:56 am, "Neil Truby" <neil.tr...@ardenta.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 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?
On May 26, 1:01 pm, "Neil Truby" <neil.tr...@ardenta.com> wrote: > "mpruet" <mpru...@verizon.net> wrote in message > > news:e0c609d9-39d9-4082-b949-6771e3e7f5f7@u7g2000vbq.googlegroups.com... > On May 26, 8:56 am, "Neil Truby" <neil.tr...@ardenta.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 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 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.
Have some recommendation to configure the SDS_PAGING and SDS_TEMPDBS over a non jornaling File system? like ext2 to avoid any performance issues ? --- Em qua, 26/5/10, mpruet <mpruet1@verizon.net> escreveu: De: mpruet <mpruet1@verizon.net> Assunto: Re: SDS best practice query Para: informix-list@iiug.org Data: Quarta-feira, 26 de Maio de 2010, 15:13 On May 26, 1:01 pm, "Neil Truby" <neil.tr...@ardenta.com> wrote: > "mpruet" <mpru...@verizon.net> wrote in message > > news:e0c609d9-39d9-4082-b949-6771e3e7f5f7@u7g2000vbq.googlegroups.com... > On May 26, 8:56 am, "Neil Truby" <neil.tr...@ardenta.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 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 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@iiug.org http://www.iiug.org/mailman/listinfo/informix-list
"mpruet" <mpruet1@verizon.net> wrote in message news:76221a2f-0491-40da-9e08-8fb696747ee0@f14g2000vbn.googlegroups.com... On May 26, 1:01 pm, "Neil Truby" <neil.tr...@ardenta.com> wrote: > "mpruet" <mpru...@verizon.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 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. Yes. So is there any need to have the temp dbspaces on the shared disk? In my configuartion it would avoid a lot of unnecessary replication of the temp dbspaces if they, live the SDS_ ones, could be held locally.