Re: SCR and Replay Queue length
- From: "Scott Schnoll [MSFT]" <scschnol@xxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 6 Feb 2008 14:35:19 -0800
So there is a database file there? If you empty out the folder, does Update-SGC (when run from the SCR target computer) succeed?
--
Regards,
Scott Schnoll
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no
rights. Please do not send email directly to this alias. This alias is for
newsgroup purposes only.
"Maverick" <maverick@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:CF6D55C0-137F-4804-B4AE-1403DE5A7BB1@xxxxxxxxxxxxxxxx
If I do an attrib on the temp-seeding database.edb, I get an archive
attribute. Other than that nothing else is set. What's puzzling is that
this worked fine on the first 10 databases. Thanks again for your help.
"Scott Schnoll [MSFT]" wrote:
Are you also able to get the file attributes for the seeding directory using
attrib?
--
Regards,
Scott Schnoll
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no
rights. Please do not send email directly to this alias. This alias is for
newsgroup purposes only.
"Maverick" <maverick@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E2FCDB5C-49A3-49FA-A709-7DFB2A71390D@xxxxxxxxxxxxxxxx
> Hi Scott,
>
> Thanks for getting back to me. I have checked the permissions and
> LocalSystem has full control. The partitions are also formatted as > NTFS.
>
> "Scott Schnoll [MSFT]" wrote:
>
>> The specific error message you are getting internally means that the
>> seeding
>> directory does not exist. What I don't know is why you would get this
>> error
>> when the directory does exist. You might check permissions and make >> sure
>> that LocalSystem has access.
>>
>> Also, to confirm, the D and E partitions are formatted as NTFS, >> correct?
>> -- >> Regards,
>>
>> Scott Schnoll
>> Microsoft Corporation
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights. Please do not send email directly to this alias. This alias is
>> for
>> newsgroup purposes only.
>>
>>
>> "Maverick" <maverick@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> news:90E1D0A6-7C24-4FAC-9BAD-604131DB6B3E@xxxxxxxxxxxxxxxx
>> > Actually, the D: and E: drive are on a partitioned RAID 5 array. I >> > did
>> > a
>> > permon when trying to seed the database and didn't see anything out >> > of
>> > the
>> > ordinary.
>> >
>> >
>> >
>> > "John Fullbright" wrote:
>> >
>> >> "My target mailbox server has a system drive (c:\) and the second
>> >> physical
>> >> > local drive partitioned with D:\ and E:\ for the TX logs and
>> >> > databases.
>> >> > I
>> >> > am
>> >> > not sure if this is the issue or not."
>> >>
>> >> On the destination, You have a single physical DAS spindle >> >> logically
>> >> partitioned into D: and E: for logs and database?
>> >>
>> >> I'd suspect an IO bottleneck is the reason behind the 18K+
>> >> copyqueuelength,
>> >> the divergence, and the failure to seed.
>> >>
>> >>
>> >>
>> >>
>> >> "Maverick" <maverick@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> >> news:5C52F210-F9C3-4D96-B56B-94A9FDC80E51@xxxxxxxxxxxxxxxx
>> >> > One more thing,
>> >> >
>> >> > I have my source mailbox server configured on a SAN with the TX >> >> > logs
>> >> > on
>> >> > the
>> >> > D:\ drive and the databases on a seperate SAN slice named e:\.
>> >> >
>> >> > My target mailbox server has a system drive (c:\) and the second
>> >> > physical
>> >> > local drive partitioned with D:\ and E:\ for the TX logs and
>> >> > databases.
>> >> > I
>> >> > am
>> >> > not sure if this is the issue or not.
>> >> >
>> >> > "Maverick" wrote:
>> >> >
>> >> >> Hi Scott,
>> >> >>
>> >> >> The error message that I recieve when I do an
>> >> >> updatestoragegroupcopy
>> >> >> -identity 'mailserver\storage group1' -standbymachine
>> >> >> backupmailserver:
>> >> >>
>> >> >> "Update-StorageGroupCopy : Seeding failed: Database seeding >> >> >> error:
>> >> >> Continuous Replication seeding was provided a database path that
>> >> >> does
>> >> >> not
>> >> >> identify viable storage"
>> >> >>
>> >> >> When I run a getstoragegroupcopystatus on the storage group that >> >> >> is
>> >> >> failing
>> >> >> to seed the database, I get:
>> >> >>
>> >> >> SummaryCopyStatus : suspended
>> >> >> CopyQueuelength: 18826
>> >> >> Replayqueuelenght: 0
>> >> >> LastLogInspectedLogTime: blank
>> >> >>
>> >> >> I have checked to ensure the replication service is running. >> >> >> The
>> >> >> other
>> >> >> storage group copies are working fine.
>> >> >>
>> >> >> Thanks for your help and great job on the SCR videos on your >> >> >> blog.
>> >> >>
>> >> >> Maverick
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> "Scott Schnoll [MSFT]" wrote:
>> >> >>
>> >> >> > Well, you don't want replay to get too far behind either. >> >> >> > What
>> >> >> > does
>> >> >> > Get-StorageGroupCopyStatus (with the -StandbyMachine option) >> >> >> > show
>> >> >> > for
>> >> >> > the
>> >> >> > storage group? Also, can you verify that the Replication >> >> >> > service
>> >> >> > is
>> >> >> > running
>> >> >> > on the SCR target computer?
>> >> >> >
>> >> >> > When you tried to seed with Update-SGC, what error message did
>> >> >> > you
>> >> >> > get?
>> >> >> > -- >> >> >> > Regards,
>> >> >> >
>> >> >> > Scott Schnoll
>> >> >> > Microsoft Corporation
>> >> >> > This posting is provided "AS IS" with no warranties, and >> >> >> > confers
>> >> >> > no
>> >> >> > rights. Please do not send email directly to this alias. This
>> >> >> > alias
>> >> >> > is
>> >> >> > for
>> >> >> > newsgroup purposes only.
>> >> >> >
>> >> >> >
>> >> >> > "Maverick" <maverick@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in >> >> >> > message
>> >> >> > news:41AE5BA9-3897-4DA2-9481-A6EA4AED93CE@xxxxxxxxxxxxxxxx
>> >> >> > > Hi all,
>> >> >> > >
>> >> >> > > I am running into something interesting with SCR. I have
>> >> >> > > enabled
>> >> >> > > it
>> >> >> > > on
>> >> >> > > about 10 databases without any issues. However, they were
>> >> >> > > mostly
>> >> >> > > small (2
>> >> >> > > gigs or less). I am trying to seed a 4 gig database and it
>> >> >> > > keeps
>> >> >> > > failing
>> >> >> > > to
>> >> >> > > seed when using the suspend-storagegroupcopy/update
>> >> >> > > storagegroupcopy.
>> >> >> > >
>> >> >> > > So, I followed another way of doing it by dismounting the
>> >> >> > > production
>> >> >> > > database and then copying the edb file to the target server. >> >> >> > > I
>> >> >> > > have
>> >> >> > > no
>> >> >> > > path
>> >> >> > > conflicts. After the copying is complete, I remount the
>> >> >> > > production
>> >> >> > > database
>> >> >> > > and do a resume-storagegroupcopy.
>> >> >> > >
>> >> >> > > My problem is that the replay queue length stays at about >> >> >> > > 18000
>> >> >> > > logs
>> >> >> > > and
>> >> >> > > keeps growing. I thought that there was a delay of 50 log
>> >> >> > > files
>> >> >> > > and
>> >> >> > > 24
>> >> >> > > hours
>> >> >> > > before replaying the logs on the target. When I do a
>> >> >> > > get-storagegroupcopystatus on the group, it comes back as
>> >> >> > > healthy
>> >> >> > > and
>> >> >> > > the
>> >> >> > > copy queue length is 0. Should I be worried about the >> >> >> > > replay
>> >> >> > > queue
>> >> >> > > length?
>> >> >> >
>> >> >> >
>> >>
>> >>
>> >>
>>
>>
.
- Follow-Ups:
- Re: SCR and Replay Queue length
- From: Maverick
- Re: SCR and Replay Queue length
- References:
- SCR and Replay Queue length
- From: Maverick
- Re: SCR and Replay Queue length
- From: Scott Schnoll [MSFT]
- Re: SCR and Replay Queue length
- From: Maverick
- Re: SCR and Replay Queue length
- From: Maverick
- Re: SCR and Replay Queue length
- From: John Fullbright
- Re: SCR and Replay Queue length
- From: Maverick
- Re: SCR and Replay Queue length
- From: Scott Schnoll [MSFT]
- Re: SCR and Replay Queue length
- From: Maverick
- Re: SCR and Replay Queue length
- From: Scott Schnoll [MSFT]
- Re: SCR and Replay Queue length
- From: Maverick
- SCR and Replay Queue length
- Prev by Date: Re: Telnet and port 25
- Next by Date: Re: ZW69FB.EXE and GM1167.EXE in TEMP on EX2003 Server
- Previous by thread: Re: SCR and Replay Queue length
- Next by thread: Re: SCR and Replay Queue length
- Index(es):
Relevant Pages
|
Loading