Προσπάθησα να υλοποίήσω μια λύση  log Shipping μεταξύ ενός SQL Server 2005 (ServerA),DatabaseA και ενός SQLSERVER 2005 (ServerB),DatabaseB

κατά τη ρύθμιση των παραμέτρων  του secondary server που γίνεται από το SSManagement Studio του primary,στο tab <restore transaction log> έχει τις επιλογές (Database state when restoring backups) :  NORecovery και STANDBy. Επιλέγω NORECOVERY (στην άλλη δοκιμή που έκανα δοκίμασαα και standby αλλά δεν είχα αποτελέσματα).

Παίρνω backup της DatabaseA , το κάνω restore στην DatabaseB, ρυθμίζω κατάλληλα τα δικαιώματα στους shared folders και ξεκινάει η διαδικασία του shipping

Η job που παίρνει backup την DatabaseA και το τοποθετεί στον shared folder λειτουργεί κανονικά

Η Job του ServerB που κάνει το copy στον folder του secondary λειτουργεί επίσης επιτυχώς.

Όμως η Job που κάνει το restore βγάζει το ακόλουθο σφάλμα 

 The restore operation cannot proceed because the secondary database 'SecondaryDB' is not in NORECOVERY/STANDBY mode.(Microsoft.SqlServer.Management.LogShipping)

Για ποιό λόγο προβάλει αυτό το σφάλμα και πώς θα μπορούσα να το ξεπεράσω?

Επίσης, ποιός είναι ο ρόλος των επιλογών  NORecovery και STANDBy ? Ίσχύουν μόνο κατά τη διάρκεια του Restore και ποιά η διαφορά τους (γνωρίζω τη διαφορά τους στην T_SQL Restore αλλά πώς θα συνεχίσει να λειτουργεί η βάση μετά το restore job αν μόνο αυτές είναι οι επιλογές)? Όσο δεν εκτελείται το restore job η βάση στον secondary είναι διαθέσιμη ή λόγω των επιλογών αυτών μένει πάντοτε κλειδωμένη?

 

Ευχαριστώ Πολύ

Τελικά δοκίμασα ξανά επιλέγοντας να ρυθμίσω τον primary ως εξής:

1. Φτιάξε ενα backup της βάσης στον primary και στη συνέχεια φτιάξε κάνε restore το backup αυτο στον secondary

2. STAND BY mode στον secondary (επειδή θέλω να βλέπω αν η βάση έχει συγχρονιστεί) και επέλεξα να βγάζει εκτός τους χρήστες κατά τη διάρκεια του RESTORE.

Το backup της primary γίνεται σωστά και  η δημιουργία της secondary επίσης , η οποία μάλιστα εμφανίζεται στο SS Management Studio γκρίζα (δηλ.και γράφει STAND BY/Read only)

Ξεκινά το backup του t-log και γίνεται σωστά

Ξεκινά η αντιγραφή του t-log στον folder του secondary και γίνεται επίσης σωστα

Όταν ξεκινά το restore, βρίσκει ποιο file πρέπει να κάνει restore και βγάζει το μήνυμα

Error: Could not apply log backup file '\\secServer\SharedFolderSecondary\PrimaryDB_20060915071600.trn' to secondary database 'SecondaryDB'.(Microsoft.SqlServer.Management.LogShipping) ***<nl/>2006-09-15 10:18:28.44 *** Error: During startup of warm standby database 'SecondaryDB' (database ID 11)its standby file ('\\secServer\SharedFolderSecondary\SecondaryDB_20060915071828.tuf') was inaccessible to the RESTORE statement. The operating system error was '5(error not found)'. Diagnose the operating system error<c/> correct the problem<c/> and retry startup.<nl/>RESTORE LOG is terminating abnormally

Γιατί εμφανίζει συνεχώς αυτό το σφάλμα?

Επιπλέον η secondaryDB πλέον πάει να είναι σε STAND BY MODE και όταν πάω να την ανοίξω εμφανίζει

It is in the middle of a restore.

και κελιδώνει χωρίς να μπορεί να χρησιμοποιήσει κανείς (παύει να είναι γκρίζα και γίνεται κίτρινη αλλά inaccessible)

Ευχαριστώ

Απ'ότι κατάλαβα, έβγαλες άκρη σχετικά με το STANDBY και το NORECOVERY οπότε πάμε παρακάτω.

Δοκίμασε να υλοποιήσεις το σενάριο κάνοντας log-shipping σε διαφορετικά instances που να είναι στο ίδιο φυσικό μηχάνημα ώστε να εξασφαλίσεις ότι δεν εμπλέκονται παράγοντες σχετικά με network availability/security. Δεν μου φαίνετια ότι φταίει αυτό αλλά είναι καλύτερα να ξεκινήσεις με ένα τέτοιο prototype.

Επίσης, πρόσεξε ώστε να μην εκτελούνται άλλα tlog backups πέρα από αυτά που χρειάζονται για να παίζει το log shipping γιατί τα άσχετα tlog backups "κλέβουν" tlog entries. Μπορεί να έχει ξεμείνει κανένα job ή κανένα maintenance plan.

---

Vir prudens non contra ventum mingit

Eyxaristo poli gia tin apantisi,

ithela na se rotiso kai kati akoma.

An thelo to backup, to copy kai to restore na ginontai sixna , prepei na oriso to antistoixo schedule gia to kathena (p.x. 5 lepta).

Omws distixws to backup-job den dinei tin option na diagrafo palia backups kai akoma xeirotera to copy-job elegxei ola ta arxeia tou primary folder (akoma ki ayta pou exei antigrapsei se proigoumenes ekteleseis) kai otan ftasei se ayta pou den exei antigrapsei, tote kanei tin antigrafi ston secondary folder. To apotelesma einai i copy-process meta apo misi ora na kathisterei kai to restore-job vriskei kapoia locked arxeia opote prospathontas na ta kanei restore apotigxanei (vgazei error 5 tou leitourgikou)

Koitaksa to copy-job gia na to tropopooiso kai vrika tin eksis entoli sto step1

"C:\Program Files\Microsoft SQL Server\90\Tools\Binn\sqllogship.exe" -Copy 920A4CA9-D981-4BBD-9FBD-C897989378E9 -server MyServerName

Tha mporouses na mou doseis perissoteres plirofories gia tous "periergous" autous arithmous?

Tha xes na proteineis kati gia to parapano provlima?

Efxaristo

Σε ότι αφορά τo log-shipping, δεν έχει νόημα να κάνεις database backup ή differential backup γιατί αυτό που ενδιαφέρει το server ως διαδικασία είναι να κάνει replicate τα δεδομένα από τη μία βάση στην άλλη μέσω των πληροφοριών που γράφονται στο transaction log. Ουσιαστικά, χρειάζεσαι ένα full backup απλά για να ξεκινήσεις στον target server ένα πρόσφατο version της βάσης και κατόπιν να γίνουν apply πάνω σε αυτό όλα τα transaction log backup.

Οι περίεργοι αυτοί αριθμοί είναι GUIDS, δηλαδή 32bit ακολουθίες που έχουν το χαρακτηριστικό ότι είναι μοναδικές, δηλαδή δεν υπάρχει περίπτωση να αναπαραχθεί η ίδια ακολουθία σε αυτόν ή άλλον υπολογιστή. To sqllogship.exe είναι ο agent που κάνει τη δουλειά και μέσω των GUIDs αναγνωρίζει πιο αρχείο θα χρησιμοποιήσει.

---

Vir prudens non contra ventum mingit

Σ ευχαριστώ ξανά,

το προβλημα εντοπίστηκε στο εξής:

Είχα βάλει να τρέχουν κάθε 5 λεπτά το backup job στον primary , το copy - job που τρέχει στον secondary και το restore job που τρέχει στον secondary.

Όμως το copy job έκανε για να ολοκληρώσει μια εκτέλεσή του παραπάνω από πέντε λεπτά ( μεα αποτέλεσμα να τρέχει συνέχεια). Έτσι, ενώ αυτό έτρεχε, παράλληλα προσπαθούσε κάποια στιγμή να τρέξει και το resotre-job με αποτέλεσμα να βρίσκει κάποιο από τα logs κλειδωμένο (το αντέγραφε η copy job εκείνη την ώρα) και τελικά το restore γινίοταν fail. Με προβλημάτισε το εξής: Η βάση είναι πολύ μικρή σε μέγεθος ακόμη και ουσιαστικά το log γεμίζει από τα test data που της δίνω. Εντούτοις το copy job κάνει πολύ ώρα (αν λάβουμε υπόψιν το μέγεθος και τον αριθμό των αρχείων) για να ολοκληρωθεί.

Έχεις να προτείνεις κάποια λύση? Αυτό που σκέφτηκα είναι απλά να ανοίξω λίγο το schedule (δηλ. όχι κάθε 5 λεπτά αλλά κάθε 40) και επιπλέον το copy και το restore να ξεκινάνε σε διαφορετικές στιγμές. Επίσης να διαγράφω συχνά τα backup και τα copied t-log files (...όχι και τόσο καλό...). Το πρόβλημα που γεννά η υλοποίηση αυτή είναι ότι θα είμαι 40 λεπτά πίσω από την πραγματική βάση. Σκέφτεσαι κάτι καλύτερο???

Και ένα τελευταίο: τί γίνεται στην περίπτωση που για κάποιο λόγο κάποιο t-log δεν αντιγραφεί χαθεί (π.χ. δεν αντιγραφεί σωστά, διαγραφεί για κάποιο λόγο?) Από το σημείο αυτό και μετέπειται το restore job θα σκάει συνέχεια γιατί θα κοιτάζει τα LSN των t-log και θα βλέπει ότι του λείπει κάποιο από αυτά? Δηλαδή μετά πρέπει να στηθεί ξανά?

Και αν θέλω κάποια στιγμή λόγω του maintenance plan να πάρω full backup αυτό θα πρέπει να γίνεται μόνο με COPY_ONLY? Δηλαδή η βάση μου από τη στιγμή που μπαίνει στο log-shipping δεν μπορεί να παρθεί κανονικό backup διότι θα πειραχτεί το t-log και θα χαλάσει το log shipping? :(

Πάντως το μέγεθος του t-log μετά από 10 μέρες νομίζω ότι θα αυξηθεί πολύ και θα χρειαστεί DBCC SHRINKFILE, Ελπίζω αυτό να μην δημιουργήσει πρόβλημα

 

Ευχαριστώ και συγνώμη για το φόρτο των ερωτήσεων 

Kai kati akomi:

An thelo stin primary vasi na paro full backup, tote afto tha spasei to Log-Shipping? Diladi otan exo log-shipping den mporo na pairno tin primary vasi kanena full backup? (den enow me COPY_ONLY)

Pantws to restore process, eksakoloythei kai mou vgazei error

Error: Could not apply log backup file '\\secServer\SharedFolderSecondary\PrimaryDB_20060918071600.trn' to secondary database 'SecondaryDB'.(Microsoft.SqlServer.Management.LogShipping) ***<nl/>2006-09-18 10:18:28.44 *** Error: During startup of warm standby database 'SecondaryDB' (database ID 11)its standby file ('\\secServer\SharedFolderSecondary\SecondaryDB_20060918071828.tuf') was inaccessible to the RESTORE statement. The operating system error was '5(error not found)'. Diagnose the operating system error<c/> correct the problem<c/> and retry startup.<nl/>RESTORE LOG is terminating abnormally

Tin proti fora pou paei na kanei restore kai den vriskei kanena log file to restore sinexizei (ara den einai thema rights) kai leei oti den vrike file na kanei restore kai termatizei epitixws.

Tin epomeni pou vriskei file, vgazei to parapano error! Exeis idea ti mporei na einai?

 

Το full backup δεν σπάει το log shipping.

Δεν μπορώ να υποθέσω για ποιόν λόγο σου εμφανίζει αυτό το μήνυμα ωστόσο μπορείς να κάνεις χειροκίνητο troubleshooting αν αποθηκεύσεις το αποτέλεσμα του Wizard σε T-SQL script αρχείο (γίνεται στο τελευταίο βήμα του wizard) και τρέξεις τα βήματα ένα-ένα να δεις που χτυπάει. Επίσης, δοκίμασε να δεις τι γίνεται αν έχεις ήδη προετοιμάσει τον target server και στο tab "Initialize Secondary Database" να επιλέξεις "Νο, the secondary database is initialized".

Ως προς την ταχύτητα των jobs, ο γενικός κανόνας είναι να χρησιμοποιούμε διαφορετικό physical drive για κάθε δουλειά ώστε να μην έχουμε bottleneck. Αλλού η βάση, αλλού τα backups, αλλού τα shared folders.

---

Vir prudens non contra ventum mingit

S eyxaristo poli gia ti voitheia sou. To full kai to differential backup den to thelo gia to sigxronismo alla gia to maintenance plan mou (sto opoio den tha vazo kanena t-log fisika h' an vazo tha ta apothikeuo sto shared folder). Mporo afova na pairno full kai differential backup sinexws tin primary vasi xoris na to apothikeuo ston shared? (nomizo oti ta LSNs den epireazontai apo ta differential, full, kano lathos?)

Thanks

 

Χμμμ... Βλέπω ότι στο προηγούμενο post μου έκανα λάθος σε αυτά που έγραψα. Το διόρθωσα για να μην πάρω κανέναν στο λαιμό μου. Ανακεφαλαιώνοντας, το log shipping δεν επηρεάζεται από τα ενδιάμεσα full και differential backups.

---

Vir prudens non contra ventum mingit

Thank you very much!!!