|
|
You're in the
sql server replication
group:Log Shipping in a SQL CLuster
sql server replication:
Yesterday, I did my regular security updates following KB article Q174799. Now my log shipping job is out of synch and it looks like I need to re-create it. What would have caused this given the database was never offline? Did moving the group to the other server cause the transaction logs to get out of order. I woulkd like to know what caused this I can avoid it next time.
Moving it to the other node doesn't affect the database at all. It does
take the SQL Server offline and then start it back up. But it is exactly the same database and there is never a possibility of getting logs out of order. You would have to define what you mean by out of synch? Is it behind? Are things accumulating? Are jobs not started? Can it not see the file share? There is nothing to recreate. You have a job that backs up a database, a job that copies files, and a job that restores a database. Recreating it is going to hand you back exactly what you have right now. -- Mike http://www.solidqualitylearning.com Disclaimer: This communication is an original work and represents my sole views on the subject. It does not represent the views of any other person or entity either by inference or direct reference. [quoted text, click to view] "Scopus69" <Scopus69@nospam.postalias> wrote in message news:8F9D30A1-EF7E-412B-87CB-F5374D3E9B5B@microsoft.com... >I have SQL in a cluster with Log Shipping enabled to a remote DR server. > > Yesterday, I did my regular security updates following KB article Q174799. > Now my log shipping job is out of synch and it looks like I need to > re-create > it. What would have caused this given the database was never offline? > Did > moving the group to the other server cause the transaction logs to get > out > of order. I woulkd like to know what caused this I can avoid it next > time. > Thanks!!
It looks like something I did on the night I did the security updates caused
the file share on the source server directory to be removed. That in turn, caused the copy and load delta to start increasing and the log shipping monitor to say "out of synch" I am not sure why or how the file share was removed. I enabled "sharing" again on the source folder and the values are decreasing. I will see if this will get back into synch. [quoted text, click to view] "Michael Hotek" wrote:
> Moving it to the other node doesn't affect the database at all. It does > take the SQL Server offline and then start it back up. But it is exactly > the same database and there is never a possibility of getting logs out of > order. > > You would have to define what you mean by out of synch? Is it behind? Are > things accumulating? Are jobs not started? Can it not see the file share? > > There is nothing to recreate. You have a job that backs up a database, a > job that copies files, and a job that restores a database. Recreating it is > going to hand you back exactly what you have right now. > > -- > Mike > http://www.solidqualitylearning.com > Disclaimer: This communication is an original work and represents my sole > views on the subject. It does not represent the views of any other person > or entity either by inference or direct reference. > > > "Scopus69" <Scopus69@nospam.postalias> wrote in message > news:8F9D30A1-EF7E-412B-87CB-F5374D3E9B5B@microsoft.com... > >I have SQL in a cluster with Log Shipping enabled to a remote DR server. > > > > Yesterday, I did my regular security updates following KB article Q174799. > > Now my log shipping job is out of synch and it looks like I need to > > re-create > > it. What would have caused this given the database was never offline? > > Did > > moving the group to the other server cause the transaction logs to get > > out > > of order. I woulkd like to know what caused this I can avoid it next > > time. > > Thanks!! > >
Hi All,
Glad to see your sharing knowledge here. :) Scopus, if the problem still occurs, feel free to post in this thread, I'm glad to be of assistance. Best regards, Vincent Xu Microsoft Online Partner Support ====================================================== Get Secure! - www.microsoft.com/security ====================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from this issue. ====================================================== This posting is provided "AS IS" with no warranties,and confers no rights. ====================================================== -------------------- [quoted text, click to view] >>Thread-Topic: Log Shipping in a SQL CLuster
>>thread-index: AcZgS2h2uCdEbr+5ShmSfHjlDqXo0g== >>X-WBNR-Posting-Host: 68.209.108.244 >>From: =?Utf-8?B?U2NvcHVzNjk=?= <Scopus69@nospam.postalias> >>References: <8F9D30A1-EF7E-412B-87CB-F5374D3E9B5B@microsoft.com> <ub29KsBYGHA.4688@TK2MSFTNGP04.phx.gbl> >>Subject: Re: Log Shipping in a SQL CLuster >>Date: Fri, 14 Apr 2006 22:14:01 -0700 >>Lines: 48 >>Message-ID: <2B76C4CB-AB26-4B2E-9217-711234B62A57@microsoft.com> >>MIME-Version: 1.0 >>Content-Type: text/plain; >> charset="Utf-8" >>Content-Transfer-Encoding: 7bit >>X-Newsreader: Microsoft CDO for Windows 2000 >>Content-Class: urn:content-classes:message >>Importance: normal >>Priority: normal >>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 >>Newsgroups: microsoft.public.sqlserver.replication >>Path: TK2MSFTNGXA01.phx.gbl >>Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.sqlserver.replication:70645 >>NNTP-Posting-Host: TK2MSFTNGXA01.phx.gbl 10.40.2.250 >>X-Tomcat-NG: microsoft.public.sqlserver.replication >> >>It looks like something I did on the night I did the security updates caused >>the file share on the source server directory to be removed. That in turn, >>caused the copy and load delta to start increasing and the log shipping >>monitor to say "out of synch" >> >>I am not sure why or how the file share was removed. I enabled "sharing" >>again on the source folder and the values are decreasing. I will see if this >>will get back into synch. >> >>"Michael Hotek" wrote: >> >>> Moving it to the other node doesn't affect the database at all. It does >>> take the SQL Server offline and then start it back up. But it is exactly >>> the same database and there is never a possibility of getting logs out of >>> order. >>> >>> You would have to define what you mean by out of synch? Is it behind? Are >>> things accumulating? Are jobs not started? Can it not see the file share? >>> >>> There is nothing to recreate. You have a job that backs up a database, a >>> job that copies files, and a job that restores a database. Recreating it is >>> going to hand you back exactly what you have right now. >>> >>> -- >>> Mike >>> http://www.solidqualitylearning.com >>> Disclaimer: This communication is an original work and represents my sole >>> views on the subject. It does not represent the views of any other person >>> or entity either by inference or direct reference. >>> >>> >>> "Scopus69" <Scopus69@nospam.postalias> wrote in message >>> news:8F9D30A1-EF7E-412B-87CB-F5374D3E9B5B@microsoft.com... >>> >I have SQL in a cluster with Log Shipping enabled to a remote DR server. >>> > >>> > Yesterday, I did my regular security updates following KB article Q174799. >>> > Now my log shipping job is out of synch and it looks like I need to >>> > re-create >>> > it. What would have caused this given the database was never offline? >>> > Did >>> > moving the group to the other server cause the transaction logs to get >>> > out >>> > of order. I woulkd like to know what caused this I can avoid it next >>> > time. >>> > Thanks!! >>> >>> >>> >>
Vincent,
OK...thanks!! What I have determined is anytime I failover the cluster the directory that is setup as a "share" for the transactions logs is removed. Not the physical directory itself the share properties...what is causing that?? Thanks! [quoted text, click to view] "Vincent Xu [MSFT]" wrote:
> Hi All, > > Glad to see your sharing knowledge here. :) > > Scopus, if the problem still occurs, feel free to post in this thread, I'm > glad to be of assistance. > > > Best regards, > > Vincent Xu > Microsoft Online Partner Support > > ====================================================== > Get Secure! - www.microsoft.com/security > ====================================================== > When responding to posts, please "Reply to Group" via your newsreader so > that others > may learn and benefit from this issue. > ====================================================== > This posting is provided "AS IS" with no warranties,and confers no rights. > ====================================================== > > > > -------------------- > >>Thread-Topic: Log Shipping in a SQL CLuster > >>thread-index: AcZgS2h2uCdEbr+5ShmSfHjlDqXo0g== > >>X-WBNR-Posting-Host: 68.209.108.244 > >>From: =?Utf-8?B?U2NvcHVzNjk=?= <Scopus69@nospam.postalias> > >>References: <8F9D30A1-EF7E-412B-87CB-F5374D3E9B5B@microsoft.com> > <ub29KsBYGHA.4688@TK2MSFTNGP04.phx.gbl> > >>Subject: Re: Log Shipping in a SQL CLuster > >>Date: Fri, 14 Apr 2006 22:14:01 -0700 > >>Lines: 48 > >>Message-ID: <2B76C4CB-AB26-4B2E-9217-711234B62A57@microsoft.com> > >>MIME-Version: 1.0 > >>Content-Type: text/plain; > >> charset="Utf-8" > >>Content-Transfer-Encoding: 7bit > >>X-Newsreader: Microsoft CDO for Windows 2000 > >>Content-Class: urn:content-classes:message > >>Importance: normal > >>Priority: normal > >>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 > >>Newsgroups: microsoft.public.sqlserver.replication > >>Path: TK2MSFTNGXA01.phx.gbl > >>Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.sqlserver.replication:70645 > >>NNTP-Posting-Host: TK2MSFTNGXA01.phx.gbl 10.40.2.250 > >>X-Tomcat-NG: microsoft.public.sqlserver.replication > >> > >>It looks like something I did on the night I did the security updates > caused > >>the file share on the source server directory to be removed. That in > turn, > >>caused the copy and load delta to start increasing and the log shipping > >>monitor to say "out of synch" > >> > >>I am not sure why or how the file share was removed. I enabled "sharing" > >>again on the source folder and the values are decreasing. I will see if > this > >>will get back into synch. > >> > >>"Michael Hotek" wrote: > >> > >>> Moving it to the other node doesn't affect the database at all. It > does > >>> take the SQL Server offline and then start it back up. But it is > exactly > >>> the same database and there is never a possibility of getting logs out > of > >>> order. > >>> > >>> You would have to define what you mean by out of synch? Is it behind? > Are > >>> things accumulating? Are jobs not started? Can it not see the file > share? > >>> > >>> There is nothing to recreate. You have a job that backs up a database, > a > >>> job that copies files, and a job that restores a database. Recreating > it is > >>> going to hand you back exactly what you have right now. > >>> > >>> -- > >>> Mike > >>> http://www.solidqualitylearning.com > >>> Disclaimer: This communication is an original work and represents my > sole > >>> views on the subject. It does not represent the views of any other > person > >>> or entity either by inference or direct reference. > >>> > >>> > >>> "Scopus69" <Scopus69@nospam.postalias> wrote in message > >>> news:8F9D30A1-EF7E-412B-87CB-F5374D3E9B5B@microsoft.com... > >>> >I have SQL in a cluster with Log Shipping enabled to a remote DR > server. > >>> > > >>> > Yesterday, I did my regular security updates following KB article > Q174799. > >>> > Now my log shipping job is out of synch and it looks like I need to > >>> > re-create > >>> > it. What would have caused this given the database was never > offline? > >>> > Did > >>> > moving the group to the other server cause the transaction logs to > get > >>> > out > >>> > of order. I woulkd like to know what caused this I can avoid it next > >>> > time. > >>> > Thanks!! > >>> > >>> > >>> > >> >
Hi,
It appears the following KB article can address your concern. PRB: Cannot Modify Backup Network Share After You Change the Transaction Log Backup Folder http://support.microsoft.com/?id=314570 Let me know if the problem still occurs. Best regards, Vincent Xu Microsoft Online Partner Support ====================================================== Get Secure! - www.microsoft.com/security ====================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from this issue. ====================================================== This posting is provided "AS IS" with no warranties,and confers no rights. ====================================================== -------------------- [quoted text, click to view] >>Thread-Topic: Log Shipping in a SQL CLuster <ub29KsBYGHA.4688@TK2MSFTNGP04.phx.gbl> >>thread-index: AcZiIlSXj5RHKaOcTd6EyiELU7pVkg== >>X-WBNR-Posting-Host: 66.20.1.12 >>From: =?Utf-8?B?U2NvcHVzNjk=?= <Scopus69@nospam.postalias> >>References: <8F9D30A1-EF7E-412B-87CB-F5374D3E9B5B@microsoft.com> <2B76C4CB-AB26-4B2E-9217-711234B62A57@microsoft.com> <rnhW3QcYGHA.888@TK2MSFTNGXA01.phx.gbl> [quoted text, click to view] >>Subject: Re: Log Shipping in a SQL CLuster
>>Date: Mon, 17 Apr 2006 06:25:01 -0700 >>Lines: 127 >>Message-ID: <7534A459-1B6D-4355-91BA-97DDD6E9F1B3@microsoft.com> >>MIME-Version: 1.0 >>Content-Type: text/plain; >> charset="Utf-8" >>Content-Transfer-Encoding: 7bit >>X-Newsreader: Microsoft CDO for Windows 2000 >>Content-Class: urn:content-classes:message >>Importance: normal >>Priority: normal >>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 >>Newsgroups: microsoft.public.sqlserver.replication >>Path: TK2MSFTNGXA01.phx.gbl >>Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.sqlserver.replication:70663 >>NNTP-Posting-Host: TK2MSFTNGXA01.phx.gbl 10.40.2.250 >>X-Tomcat-NG: microsoft.public.sqlserver.replication >> >>Vincent, >> >>OK...thanks!! What I have determined is anytime I failover the cluster the >>directory that is setup as a "share" for the transactions logs is removed. >>Not the physical directory itself the share properties...what is causing >>that?? Thanks! >> >>"Vincent Xu [MSFT]" wrote: >> >>> Hi All, >>> >>> Glad to see your sharing knowledge here. :) >>> >>> Scopus, if the problem still occurs, feel free to post in this thread, I'm >>> glad to be of assistance. >>> >>> >>> Best regards, >>> >>> Vincent Xu >>> Microsoft Online Partner Support >>> >>> ====================================================== >>> Get Secure! - www.microsoft.com/security >>> ====================================================== >>> When responding to posts, please "Reply to Group" via your newsreader so >>> that others >>> may learn and benefit from this issue. >>> ====================================================== >>> This posting is provided "AS IS" with no warranties,and confers no rights. >>> ====================================================== >>> >>> >>> >>> -------------------- >>> >>Thread-Topic: Log Shipping in a SQL CLuster >>> >>thread-index: AcZgS2h2uCdEbr+5ShmSfHjlDqXo0g== >>> >>X-WBNR-Posting-Host: 68.209.108.244 >>> >>From: =?Utf-8?B?U2NvcHVzNjk=?= <Scopus69@nospam.postalias> >>> >>References: <8F9D30A1-EF7E-412B-87CB-F5374D3E9B5B@microsoft.com> >>> <ub29KsBYGHA.4688@TK2MSFTNGP04.phx.gbl> >>> >>Subject: Re: Log Shipping in a SQL CLuster >>> >>Date: Fri, 14 Apr 2006 22:14:01 -0700 >>> >>Lines: 48 >>> >>Message-ID: <2B76C4CB-AB26-4B2E-9217-711234B62A57@microsoft.com> >>> >>MIME-Version: 1.0 >>> >>Content-Type: text/plain; >>> >> charset="Utf-8" >>> >>Content-Transfer-Encoding: 7bit >>> >>X-Newsreader: Microsoft CDO for Windows 2000 >>> >>Content-Class: urn:content-classes:message >>> >>Importance: normal >>> >>Priority: normal >>> >>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 >>> >>Newsgroups: microsoft.public.sqlserver.replication >>> >>Path: TK2MSFTNGXA01.phx.gbl >>> >>Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.sqlserver.replication:70645 >>> >>NNTP-Posting-Host: TK2MSFTNGXA01.phx.gbl 10.40.2.250 >>> >>X-Tomcat-NG: microsoft.public.sqlserver.replication >>> >> >>> >>It looks like something I did on the night I did the security updates >>> caused >>> >>the file share on the source server directory to be removed. That in >>> turn, >>> >>caused the copy and load delta to start increasing and the log shipping >>> >>monitor to say "out of synch" >>> >> >>> >>I am not sure why or how the file share was removed. I enabled "sharing" >>> >>again on the source folder and the values are decreasing. I will see if >>> this >>> >>will get back into synch. >>> >> >>> >>"Michael Hotek" wrote: >>> >> >>> >>> Moving it to the other node doesn't affect the database at all. It >>> does >>> >>> take the SQL Server offline and then start it back up. But it is >>> exactly >>> >>> the same database and there is never a possibility of getting logs out >>> of >>> >>> order. >>> >>> >>> >>> You would have to define what you mean by out of synch? Is it behind? >>> Are >>> >>> things accumulating? Are jobs not started? Can it not see the file >>> share? >>> >>> >>> >>> There is nothing to recreate. You have a job that backs up a database, >>> a >>> >>> job that copies files, and a job that restores a database. Recreating >>> it is >>> >>> going to hand you back exactly what you have right now. >>> >>> >>> >>> -- >>> >>> Mike >>> >>> http://www.solidqualitylearning.com >>> >>> Disclaimer: This communication is an original work and represents my >>> sole >>> >>> views on the subject. It does not represent the views of any other >>> person >>> >>> or entity either by inference or direct reference. >>> >>> >>> >>> >>> >>> "Scopus69" <Scopus69@nospam.postalias> wrote in message >>> >>> news:8F9D30A1-EF7E-412B-87CB-F5374D3E9B5B@microsoft.com... >>> >>> >I have SQL in a cluster with Log Shipping enabled to a remote DR >>> server. >>> >>> > >>> >>> > Yesterday, I did my regular security updates following KB article >>> Q174799. >>> >>> > Now my log shipping job is out of synch and it looks like I need to >>> >>> > re-create >>> >>> > it. What would have caused this given the database was never >>> offline? >>> >>> > Did >>> >>> > moving the group to the other server cause the transaction logs to >>> get >>> >>> > out >>> >>> > of order. I woulkd like to know what caused this I can avoid it next >>> >>> > time. >>> >>> > Thanks!! >>> >>> >>> >>> >>> >>> >>> >> >>> >>> >>
Vincent,
Would this KB Article still apply if the share directory is actually on the EMC array. The share is not local to the server? When the fail over occures the drive is mapped exactly the same during failover. Thanks!! [quoted text, click to view] "Vincent Xu [MSFT]" wrote:
> Hi, > > It appears the following KB article can address your concern. > > PRB: Cannot Modify Backup Network Share After You Change the Transaction > Log Backup Folder > http://support.microsoft.com/?id=314570 > > Let me know if the problem still occurs. > > Best regards, > > Vincent Xu > Microsoft Online Partner Support > > ====================================================== > Get Secure! - www.microsoft.com/security > ====================================================== > When responding to posts, please "Reply to Group" via your newsreader so > that others > may learn and benefit from this issue. > ====================================================== > This posting is provided "AS IS" with no warranties,and confers no rights. > ====================================================== > > > > -------------------- > >>Thread-Topic: Log Shipping in a SQL CLuster > >>thread-index: AcZiIlSXj5RHKaOcTd6EyiELU7pVkg== > >>X-WBNR-Posting-Host: 66.20.1.12 > >>From: =?Utf-8?B?U2NvcHVzNjk=?= <Scopus69@nospam.postalias> > >>References: <8F9D30A1-EF7E-412B-87CB-F5374D3E9B5B@microsoft.com> > <ub29KsBYGHA.4688@TK2MSFTNGP04.phx.gbl> > <2B76C4CB-AB26-4B2E-9217-711234B62A57@microsoft.com> > <rnhW3QcYGHA.888@TK2MSFTNGXA01.phx.gbl> > >>Subject: Re: Log Shipping in a SQL CLuster > >>Date: Mon, 17 Apr 2006 06:25:01 -0700 > >>Lines: 127 > >>Message-ID: <7534A459-1B6D-4355-91BA-97DDD6E9F1B3@microsoft.com> > >>MIME-Version: 1.0 > >>Content-Type: text/plain; > >> charset="Utf-8" > >>Content-Transfer-Encoding: 7bit > >>X-Newsreader: Microsoft CDO for Windows 2000 > >>Content-Class: urn:content-classes:message > >>Importance: normal > >>Priority: normal > >>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 > >>Newsgroups: microsoft.public.sqlserver.replication > >>Path: TK2MSFTNGXA01.phx.gbl > >>Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.sqlserver.replication:70663 > >>NNTP-Posting-Host: TK2MSFTNGXA01.phx.gbl 10.40.2.250 > >>X-Tomcat-NG: microsoft.public.sqlserver.replication > >> > >>Vincent, > >> > >>OK...thanks!! What I have determined is anytime I failover the cluster > the > >>directory that is setup as a "share" for the transactions logs is > removed. > >>Not the physical directory itself the share properties...what is causing > >>that?? Thanks! > >> > >>"Vincent Xu [MSFT]" wrote: > >> > >>> Hi All, > >>> > >>> Glad to see your sharing knowledge here. :) > >>> > >>> Scopus, if the problem still occurs, feel free to post in this thread, > I'm > >>> glad to be of assistance. > >>> > >>> > >>> Best regards, > >>> > >>> Vincent Xu > >>> Microsoft Online Partner Support > >>> > >>> ====================================================== > >>> Get Secure! - www.microsoft.com/security > >>> ====================================================== > >>> When responding to posts, please "Reply to Group" via your newsreader > so > >>> that others > >>> may learn and benefit from this issue. > >>> ====================================================== > >>> This posting is provided "AS IS" with no warranties,and confers no > rights. > >>> ====================================================== > >>> > >>> > >>> > >>> -------------------- > >>> >>Thread-Topic: Log Shipping in a SQL CLuster > >>> >>thread-index: AcZgS2h2uCdEbr+5ShmSfHjlDqXo0g== > >>> >>X-WBNR-Posting-Host: 68.209.108.244 > >>> >>From: =?Utf-8?B?U2NvcHVzNjk=?= <Scopus69@nospam.postalias> > >>> >>References: <8F9D30A1-EF7E-412B-87CB-F5374D3E9B5B@microsoft.com> > >>> <ub29KsBYGHA.4688@TK2MSFTNGP04.phx.gbl> > >>> >>Subject: Re: Log Shipping in a SQL CLuster > >>> >>Date: Fri, 14 Apr 2006 22:14:01 -0700 > >>> >>Lines: 48 > >>> >>Message-ID: <2B76C4CB-AB26-4B2E-9217-711234B62A57@microsoft.com> > >>> >>MIME-Version: 1.0 > >>> >>Content-Type: text/plain; > >>> >> charset="Utf-8" > >>> >>Content-Transfer-Encoding: 7bit > >>> >>X-Newsreader: Microsoft CDO for Windows 2000 > >>> >>Content-Class: urn:content-classes:message > >>> >>Importance: normal > >>> >>Priority: normal > >>> >>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 > >>> >>Newsgroups: microsoft.public.sqlserver.replication > >>> >>Path: TK2MSFTNGXA01.phx.gbl > >>> >>Xref: TK2MSFTNGXA01.phx.gbl > microsoft.public.sqlserver.replication:70645 > >>> >>NNTP-Posting-Host: TK2MSFTNGXA01.phx.gbl 10.40.2.250 > >>> >>X-Tomcat-NG: microsoft.public.sqlserver.replication > >>> >> > >>> >>It looks like something I did on the night I did the security updates > >>> caused > >>> >>the file share on the source server directory to be removed. That in > >>> turn, > >>> >>caused the copy and load delta to start increasing and the log > shipping > >>> >>monitor to say "out of synch" > >>> >> > >>> >>I am not sure why or how the file share was removed. I enabled > "sharing" > >>> >>again on the source folder and the values are decreasing. I will see > if > >>> this > >>> >>will get back into synch. > >>> >> > >>> >>"Michael Hotek" wrote: > >>> >> > >>> >>> Moving it to the other node doesn't affect the database at all. It > >>> does > >>> >>> take the SQL Server offline and then start it back up. But it is > >>> exactly > >>> >>> the same database and there is never a possibility of getting logs > out > >>> of > >>> >>> order. > >>> >>> > >>> >>> You would have to define what you mean by out of synch? Is it > behind? > >>> Are > >>> >>> things accumulating? Are jobs not started? Can it not see the > file > >>> share? > >>> >>> > >>> >>> There is nothing to recreate. You have a job that backs up a > database, > >>> a > >>> >>> job that copies files, and a job that restores a database. > Recreating > >>> it is > >>> >>> going to hand you back exactly what you have right now. > >>> >>> > >>> >>> -- > >>> >>> Mike > >>> >>> http://www.solidqualitylearning.com > >>> >>> Disclaimer: This communication is an original work and represents > my > >>> sole > >>> >>> views on the subject. It does not represent the views of any other > >>> person > >>> >>> or entity either by inference or direct reference. > >>> >>> > >>> >>> > >>> >>> "Scopus69" <Scopus69@nospam.postalias> wrote in message > >>> >>> news:8F9D30A1-EF7E-412B-87CB-F5374D3E9B5B@microsoft.com... > >>> >>> >I have SQL in a cluster with Log Shipping enabled to a remote DR > >>> server. > >>> >>> > > >>> >>> > Yesterday, I did my regular security updates following KB article > >>> Q174799. > >>> >>> > Now my log shipping job is out of synch and it looks like I need > to > >>> >>> > re-create
Hi,
I think there is no reason that it don't apply to disk arry. Let me know if you still have concerns. :) thanks. Best regards, Vincent Xu Microsoft Online Partner Support ====================================================== Get Secure! - www.microsoft.com/security ====================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from this issue. ====================================================== This posting is provided "AS IS" with no warranties,and confers no rights. ====================================================== -------------------- [quoted text, click to view] >>Thread-Topic: Log Shipping in a SQL CLuster <ub29KsBYGHA.4688@TK2MSFTNGP04.phx.gbl> >>thread-index: AcZj84chJRbbV1qhSPGw+hueSMgGuQ== >>X-WBNR-Posting-Host: 66.20.1.12 >>From: =?Utf-8?B?U2NvcHVzNjk=?= <Scopus69@nospam.postalias> >>References: <8F9D30A1-EF7E-412B-87CB-F5374D3E9B5B@microsoft.com> <2B76C4CB-AB26-4B2E-9217-711234B62A57@microsoft.com> <rnhW3QcYGHA.888@TK2MSFTNGXA01.phx.gbl> <7534A459-1B6D-4355-91BA-97DDD6E9F1B3@microsoft.com> <Xo5iCfrYGHA.4224@TK2MSFTNGXA01.phx.gbl> [quoted text, click to view] >>Subject: Re: Log Shipping in a SQL CLuster
>>Date: Wed, 19 Apr 2006 13:55:02 -0700 >>Lines: 211 >>Message-ID: <079EF3C5-CCAD-428F-8EB8-FD277406C717@microsoft.com> >>MIME-Version: 1.0 >>Content-Type: text/plain; >> charset="Utf-8" >>Content-Transfer-Encoding: 7bit >>X-Newsreader: Microsoft CDO for Windows 2000 >>Content-Class: urn:content-classes:message >>Importance: normal >>Priority: normal >>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 >>Newsgroups: microsoft.public.sqlserver.replication >>Path: TK2MSFTNGXA01.phx.gbl >>Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.sqlserver.replication:70763 >>NNTP-Posting-Host: TK2MSFTNGXA01.phx.gbl 10.40.2.250 >>X-Tomcat-NG: microsoft.public.sqlserver.replication >> >>Vincent, >> >>Would this KB Article still apply if the share directory is actually on the >>EMC array. The share is not local to the server? When the fail over occures >>the drive is mapped exactly the same during failover. Thanks!! >> >>"Vincent Xu [MSFT]" wrote: >> >>> Hi, >>> >>> It appears the following KB article can address your concern. >>> >>> PRB: Cannot Modify Backup Network Share After You Change the Transaction >>> Log Backup Folder >>> http://support.microsoft.com/?id=314570 >>> >>> Let me know if the problem still occurs. >>> >>> Best regards, >>> >>> Vincent Xu >>> Microsoft Online Partner Support >>> >>> ====================================================== >>> Get Secure! - www.microsoft.com/security >>> ====================================================== >>> When responding to posts, please "Reply to Group" via your newsreader so >>> that others >>> may learn and benefit from this issue. >>> ====================================================== >>> This posting is provided "AS IS" with no warranties,and confers no rights. >>> ====================================================== >>> >>> >>> >>> -------------------- >>> >>Thread-Topic: Log Shipping in a SQL CLuster >>> >>thread-index: AcZiIlSXj5RHKaOcTd6EyiELU7pVkg== >>> >>X-WBNR-Posting-Host: 66.20.1.12 >>> >>From: =?Utf-8?B?U2NvcHVzNjk=?= <Scopus69@nospam.postalias> >>> >>References: <8F9D30A1-EF7E-412B-87CB-F5374D3E9B5B@microsoft.com> >>> <ub29KsBYGHA.4688@TK2MSFTNGP04.phx.gbl> >>> <2B76C4CB-AB26-4B2E-9217-711234B62A57@microsoft.com> >>> <rnhW3QcYGHA.888@TK2MSFTNGXA01.phx.gbl> >>> >>Subject: Re: Log Shipping in a SQL CLuster >>> >>Date: Mon, 17 Apr 2006 06:25:01 -0700 >>> >>Lines: 127 >>> >>Message-ID: <7534A459-1B6D-4355-91BA-97DDD6E9F1B3@microsoft.com> >>> >>MIME-Version: 1.0 >>> >>Content-Type: text/plain; >>> >> charset="Utf-8" >>> >>Content-Transfer-Encoding: 7bit >>> >>X-Newsreader: Microsoft CDO for Windows 2000 >>> >>Content-Class: urn:content-classes:message >>> >>Importance: normal >>> >>Priority: normal >>> >>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 >>> >>Newsgroups: microsoft.public.sqlserver.replication >>> >>Path: TK2MSFTNGXA01.phx.gbl >>> >>Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.sqlserver.replication:70663 >>> >>NNTP-Posting-Host: TK2MSFTNGXA01.phx.gbl 10.40.2.250 >>> >>X-Tomcat-NG: microsoft.public.sqlserver.replication >>> >> >>> >>Vincent, >>> >> >>> >>OK...thanks!! What I have determined is anytime I failover the cluster >>> the >>> >>directory that is setup as a "share" for the transactions logs is >>> removed. >>> >>Not the physical directory itself the share properties...what is causing >>> >>that?? Thanks! >>> >> >>> >>"Vincent Xu [MSFT]" wrote: >>> >> >>> >>> Hi All, >>> >>> >>> >>> Glad to see your sharing knowledge here. :) >>> >>> >>> >>> Scopus, if the problem still occurs, feel free to post in this thread, >>> I'm >>> >>> glad to be of assistance. >>> >>> >>> >>> >>> >>> Best regards, >>> >>> >>> >>> Vincent Xu >>> >>> Microsoft Online Partner Support >>> >>> >>> >>> ====================================================== >>> >>> Get Secure! - www.microsoft.com/security >>> >>> ====================================================== >>> >>> When responding to posts, please "Reply to Group" via your newsreader >>> so >>> >>> that others >>> >>> may learn and benefit from this issue. >>> >>> ====================================================== >>> >>> This posting is provided "AS IS" with no warranties,and confers no >>> rights. >>> >>> ====================================================== >>> >>> >>> >>> >>> >>> >>> >>> -------------------- >>> >>> >>Thread-Topic: Log Shipping in a SQL CLuster >>> >>> >>thread-index: AcZgS2h2uCdEbr+5ShmSfHjlDqXo0g== >>> >>> >>X-WBNR-Posting-Host: 68.209.108.244 >>> >>> >>From: =?Utf-8?B?U2NvcHVzNjk=?= <Scopus69@nospam.postalias> >>> >>> >>References: <8F9D30A1-EF7E-412B-87CB-F5374D3E9B5B@microsoft.com> >>> >>> <ub29KsBYGHA.4688@TK2MSFTNGP04.phx.gbl> >>> >>> >>Subject: Re: Log Shipping in a SQL CLuster >>> >>> >>Date: Fri, 14 Apr 2006 22:14:01 -0700 >>> >>> >>Lines: 48 >>> >>> >>Message-ID: <2B76C4CB-AB26-4B2E-9217-711234B62A57@microsoft.com> >>> >>> >>MIME-Version: 1.0 >>> >>> >>Content-Type: text/plain; >>> >>> >> charset="Utf-8" >>> >>> >>Content-Transfer-Encoding: 7bit >>> >>> >>X-Newsreader: Microsoft CDO for Windows 2000 >>> >>> >>Content-Class: urn:content-classes:message >>> >>> >>Importance: normal >>> >>> >>Priority: normal >>> >>> >>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 >>> >>> >>Newsgroups: microsoft.public.sqlserver.replication >>> >>> >>Path: TK2MSFTNGXA01.phx.gbl >>> >>> >>Xref: TK2MSFTNGXA01.phx.gbl >>> microsoft.public.sqlserver.replication:70645 >>> >>> >>NNTP-Posting-Host: TK2MSFTNGXA01.phx.gbl 10.40.2.250 >>> >>> >>X-Tomcat-NG: microsoft.public.sqlserver.replication
Don't see what you're looking for? Try a search.
|
April 2003
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |