[MS SQL 2008]Database repliceren*

[X-DraGoN]

De situatie:
We hebben 2 'grote' SQL clusters draaien op 2 Windows 2008 R2 servers. Daarbij opzich zijn geen problemen.
We hebben SQL cluster 1 en SQL Cluster 2, vanuit de organisatie is gevraagd om een DB die op SQL CLuster 2 staat te repliceren naar SQL Cluster 1 (maw van ACC naar PROD omgeving).
Nu, op SQL kan je een replication aanmaken, daarin kan je een aantal opties meenemen, we hebben alles daarin vrij standaard gehouden.
Nadat je de Publication aanmaakt, moet je natuurlijk ook nog de subscription aanmaken en deze laten verbinden met de publisher. Dat opzich werkt ook altijd zonder probleem, er is wel degelijk een werkende verbinding tussen de twee. Je kan op 4 verschillende manieren SQL replicatie laten verlopen, nl.
1: Via snapshots
2: Via Transaction log
3: Via Transaction log + updatable subscription
4: Via Merge

Ondertussen hebben we alle 4 de mogelijkheden reeds overlopen. Ik zal hier kort neerzetten waarom dat ze elkeen niet goed werkten.

1: We hebben een Full-text index nodig op de gerepliceerde DB en die kan niet meegenomen worden, dus kunnen we van deze manier geen gebruik maken of we moeten elke morgen manueel die full text index gaan aanmaken. (is dat misschien wel ergens aanpasbaar?)
2+3: De transaction log methode loopt altijd eventjes goed maar daarna loopt hij altijd ergens fout en moet ik elke keer opnieuw die snapshot laten lopen en een reinitialise doen waarna het weer 2 à 3 dagen goed loopt.
4: Bij Merge lopen we tegen constraint validation errors aan (bv in tabel G moet B altijd groter zijn als A en bij de merge van de DB klopt dat eventjes niet zodoende hij tegen die constraint validation aanloopt, aangezien deze constraints moeten blijven bestaan, is merge ook geen oplossing.

We hebben ook al gedacht om de full backup van de ACC omgeving elke nacht te kopiëren en in de PROD in te laden, maar dan lopen ook weer tegen die Full text index aan die opnieuw gemaakt moet worden.

Heeft er iemand een werkende setup van 2 replicerende DB's waar hij zogezegd 'nooit' meer naar moet omkijken? Zo ja, hoe heb je dat voor elkaar gekregen?

[Rupie]

geen antwoord op je vraag, maar ik maak wel je titel iets duidelijker

[X-DraGoN]

Rupie schreef op woensdag 15 februari 2012 @ 09:52:
geen antwoord op je vraag, maar ik maak wel je titel iets duidelijker

Thnx

[P_de_B]

1. Je moet de optie 'Copy Full Text Indexes' wel aanzetten voor replicatie, zie bijvoorbeeld http://www.replicationanswers.com/FTI2005.asp (is voor 2005, maar vogens mij moet dit voor 2008 ook werken)

Dat je 2+3 steeds verkeerd loopt lijkt me niet normaal. Heb je goed onderzocht waarom het fout gaat? Welke errors krijg je bijvoorbeeld?

Met betrekking top optie 5 (backup restoren) kun je nog kijken naar How to move, copy, and back up full-text catalog folders and files hierin staat beschreven hoe je de Full Text index kopieert. Als het je echt gaat om iedere ochtend de meest recente productiedatabase op acceptatie te hebben lijkt me dit de meest eenvoudige manier en heb je geen replication nodig.
Je kunt natuurlijk ook scripten dat de FTI na de kopie weer opnieuw opgebouwd wordt, of kost dit te veel tijd?

[Paul]

Maak je ook nog (bijvoorbeeld wekelijks) backups van die database?

Als je de transaction-log methode gebruikt dan houdt MSSQL bij wat de laatste LSN is die je hebt gebackupt, bij de volgende transaction log backup maak je een backup vanaf dat nummer tot aan het laatste.

Als je 2 verschillende backups maakt (1x maintenance plan en 1x log shipping bijvoorbeeld) dan krijg je gaten en gaat je log shipping mis

LS: 1..6
LS: 7..14
LS: 15..53
MP: 54: 73
LS: 74.. Huh, 74 Moord, brand, ik verwacht 54!!!

[X-DraGoN]

@ Paul

We draaien sowieso elke nacht een (full) backup en de transaction logs worden natuurlijk ook elke nacht geback-upt. Mag dat dan niet? Hoe zorg je er dan voor dat je transaction log niet vol loopt op termijn?

@ P_de_B

Ik ga die snapshot publication eens bekijken en zoeken of je die full-text index kan mee kopiëren adv jouw link.
- fouten die we kregen varieerden nogal; soms kreeg hij zogezegd geen verbinding, soms bleef de logread agent maar lopen, ...

[Paul]

Hmm, ik ben niet zo bekend met replication, wel met Log Shipping; ondanks dat je bij replication ook het log gebruikt werkt het blijkbaar toch compleet anders dan Log Shipping.

Kun je achterhalen of 2 en 3 fout gaan na de transaction log backup of al eerder?

[X-DraGoN]

Indien Ik met Snapshot probeer te werken krijg ik het volgende:
Ik ben geen DBA dus daar snap ik eigenlijk niet zoveel van, kan iemand me uitleggen wat het onderstaande precies betekent en wat ik zou moeten doen om het op te lossen?

code:

2012-02-15 09:40:14.755 Initializing
2012-02-15 09:40:15.110 Snapshot will be applied from the alternate folder '\\onzeserver\ANONIEM\backups\fiscdata_trans\unc\BEBSCELLAPPACC$SQLAPPL2008_FISCDATA_SNAPSHOT_PUBLICATION_FISCDATA\20120215103728\'
2012-02-15 09:40:15.198 Agent message code 3729. Cannot DROP FUNCTION 'dbo.WO_CHILD_COUNT' because it is being referenced by object 'WO_CHECK_CHILD_COUNT'.
2012-02-15 09:40:15.555 Category:COMMAND
Source:  Failed Command
Number:  
Message: drop Function [dbo].[WO_CHILD_COUNT]

2012-02-15 09:40:15.558 Category:NULL
Source:  Microsoft SQL Server Native Client 10.0
Number:  3729
Message: Cannot DROP FUNCTION 'dbo.WO_CHILD_COUNT' because it is being referenced by object 'WO_CHECK_CHILD_COUNT'.

fails again

[Paul]

Je hebt een object WO_CHECK_CHILD_COUNT dat nog gebruik maakt van een functie dbo.WO_CHILD_COUNT. Daardoor kan die laatste niet verwijderd worden.

Waarom het functies wil verwijderen, geen idee? Zijn die op ACC verwijderd en wil het datzelfde nu op PROD uitvoeren?

[X-DraGoN]

@ Paul: De DB's zouden gelijk moeten zijn aangezien ik vorige week een backup van ACC naar PROD gezet heb.
Is dat een optie ergens in de replication settings die je hiervoor kan aanpassen?
Dit zijn de opties die ik zou kunnen aanpassen:

[X-DraGoN]

"Action if name in Use": heb ik nu eens proberen aan te passen, maar hij veranderd dat elke keer zelf terug naar "Drop existing object ..." Zelf bij de aanmaak van een volledig nieuwe publication.
Moet ik hierop verder zoeken, kan dit een oorzaak zijn van die eerder geposte fout of kan ik dit gerust negeren en mij focussen op de 'echte' fout?

[Paul]

Ik denk dat je (per ongeluk of expres?) precies de goede optie al highlighted hebt, werken een van de andere 2 opties wel (Truncate of Delete data [filter etc])? Bij het droppen wordt het ook verwijderd, dus dat zou geen probleem moeten

Edit: oh, te laat In http://www.sql-questions....-property-of-article.aspx wordt ook genoemd dat het steeds terug springt maar daar staat zo te zien geen oplossing.

[ Voor 33% gewijzigd door Paul op 15-02-2012 11:14 ]

[X-DraGoN]

@ Paul

Zie mij reply net voor die van jou... ik kan dat blijkbaar niet aanpassen, elke keer als ik dat aanpas en opnieuw daarna ga kijken naar de instelling, staat het terug op "drop existing..." Kan ik ergens een log zien zodat ik eventueel kan zien wat de fout is waarom ik dat niet kan aanpassen?

[EDIT]
Blijkbaar als je daarna gaat kijken bij de individule tables, is die optie wel veranderd, hij veranderd alleen niet als je 'all tables' selecteert.

Ben nu de 4 mogelijkheden eens aan het uittesten.

[EDIT2]
Alle 4 de mogelijkheden hebben exact dezelfde uitwerking, nog steeds die error van een paar posts geleden:

code:

2012-02-15 10:25:27.876 Initializing
2012-02-15 10:25:27.955 Agent message code 3729. Cannot DROP FUNCTION 'dbo.WO_CHILD_COUNT' because it is being referenced by object 'WO_CHECK_CHILD_COUNT'.
2012-02-15 10:25:27.985 Category:COMMAND
Source:  Failed Command
Number:  
Message: drop Function [dbo].[WO_CHILD_COUNT]

2012-02-15 10:25:27.988 Category:NULL
Source:  Microsoft SQL Server Native Client 10.0
Number:  3729
Message: Cannot DROP FUNCTION 'dbo.WO_CHILD_COUNT' because it is being referenced by object 'WO_CHECK_CHILD_COUNT'.

[ Voor 65% gewijzigd door X-DraGoN op 15-02-2012 11:27 . Reden: zie edit ]

[X-DraGoN]

Nu heb ik bij de Snapshot publication de Stored Procedures en de User defined function weg gelaten uit de snapshot en nu past hij die wel succesvol toe:

code:

012-02-15 10:38:08.839 Delivered snapshot from the 'unc\BEBSCELLAPPACC$SQLAPPL2008_FISCDATA_SNAPSHOT_PUBLICATION_FISCDATA\20120215113047\' sub-folder in 141696 milliseconds
************************ STATISTICS SINCE AGENT STARTED ***********************
02-15-2012 11:38:08

Total Run Time (ms) : 142273    Total Work Time  : 141711
Total Num Trans     : 1     Num Trans/Sec    : 0.01
Total Num Cmds      : 681   Num Cmds/Sec     : 4.81
Total Idle Time     : 0 

Writer Thread Stats
  Total Number of Retries   : 0 
  Time Spent on Exec        : 4680 
  Time Spent on Commits (ms): 0     Commits/Sec         : 0.01
  Time to Apply Cmds (ms)   : 141711    Cmds/Sec            : 4.81
  Time Cmd Queue Empty (ms) : 31    Empty Q Waits > 10ms: 2
  Total Time Request Blk(ms): 31 
  P2P Work Time (ms)        : 0     P2P Cmds Skipped    : 0

Reader Thread Stats
  Calls to Retrieve Cmds    : 2 
  Time to Retrieve Cmds (ms): 47    Cmds/Sec            : 14489.36
  Time Cmd Queue Full (ms)  : 141618    Full Q Waits > 10ms : 247
*******************************************************************************

2012-02-15 10:38:08.874 Applied the snapshot to the Subscriber.

Maar natuurlijk werkt nu de Full-Text index nog niet

[P_de_B]

Ik denk toch dat optie 5 de moeite van het onderzoeken waard is. Als ik het goed begrijp wil je iedere morgen een verse kopie van productie op acceptatie? Dan lijkt me een restore met rebuild van de FTI of kopie van de FTI helemaal geen gekke oplossing.

[X-DraGoN]

P_de_B schreef op woensdag 15 februari 2012 @ 11:44:
Ik denk toch dat optie 5 de moeite van het onderzoeken waard is. Als ik het goed begrijp wil je iedere morgen een verse kopie van productie op acceptatie? Dan lijkt me een restore met rebuild van de FTI of kopie van de FTI helemaal geen gekke oplossing.

Dat artikel zegt het volgende:

code:

This article documents several methods that you can use to copy, move, and back up or restore full-text catalog folders and files in certain restrictions:

    The SQL Server versions that you are using are the same.
    Full-text catalog folders and files must be on a local drive.
    Full-text catalog folders and files must retain their original names and folder contents.
    The full-text enabled database identifier and table identifier must be the same on both servers when you move or copy full-text catalogs between servers.

Ik vrees dat het dan niet van toepassing is aangezien ik van server naar server wil kopiëren en de locatie van de drives zijn niet hetzelfde op de beide servers (verschillende LUN's)

[X-DraGoN]

is er misschien een "script manier" om die Full-Text index terug te laten opbouwen, dat zou naturlijk ook een oplossing zijn. De DB is niet zo super groot (2.1 Gb) en de recreation duurt niet zo heel lang, kan een FTI gescript worden en zo ja, kan je me naar de juiste pagina verwijzen? Ik vind daar namelijk niet veel van terug.

[P_de_B]

MSDN: CREATE FULLTEXT INDEX (Transact-SQL)

Dit kun je via een maintenance plan of via de Agent laten uitvoeren.

[X-DraGoN]

Ik heb niet genoeg ervaring met scripten om daar iets van te kunnen maken, dus heb ik een andere weg gekozen en de SQL server profiler opgezet, dan de SQL FTI laten aanmaken en deze code dan te kopiëren.

Code zou als volgt moeten zijn:
------------------------------------------------------------------------

code:

CREATE FULLTEXT INDEX ON [dbo].[WO_VERSIE] KEY INDEX [PK_WO_VERSIE] ON ([milnav-catalog], FILEGROUP [PRIMARY]) WITH (CHANGE_TRACKING AUTO)
go
ALTER FULLTEXT INDEX ON [dbo].[WO_VERSIE] ADD ([TITEL_SEARCH_DE] LANGUAGE [German])
go
ALTER FULLTEXT INDEX ON [dbo].[WO_VERSIE] ADD ([TITEL_SEARCH_EN] LANGUAGE [British English])
go
ALTER FULLTEXT INDEX ON [dbo].[WO_VERSIE] ADD ([TITEL_SEARCH_FR] LANGUAGE [French])
go
ALTER FULLTEXT INDEX ON [dbo].[WO_VERSIE] ADD ([TITEL_SEARCH_NL] LANGUAGE [Dutch])
go
ALTER FULLTEXT INDEX ON [dbo].[WO_VERSIE] ADD ([VERSIE_SEARCH_DE] LANGUAGE [German])
go
ALTER FULLTEXT INDEX ON [dbo].[WO_VERSIE] ADD ([VERSIE_SEARCH_EN] LANGUAGE [British English])
go
ALTER FULLTEXT INDEX ON [dbo].[WO_VERSIE] ADD ([VERSIE_SEARCH_FR] LANGUAGE [French])
go
ALTER FULLTEXT INDEX ON [dbo].[WO_VERSIE] ADD ([VERSIE_SEARCH_NL] LANGUAGE [Dutch])
go
ALTER FULLTEXT INDEX ON [dbo].[WO_VERSIE] ENABLE
go

-------------------------------------------------------------------------

code:

CREATE FULLTEXT INDEX ON [dbo].[DOC_VERSIE_TAAL] KEY INDEX [PK_DOC_VERSIE_TAAL] ON ([milnav-catalog], FILEGROUP [PRIMARY]) WITH (CHANGE_TRACKING AUTO)
go
ALTER FULLTEXT INDEX ON [dbo].[DOC_VERSIE_TAAL] ADD ([INHOUD_SEARCH] TYPE COLUMN [INHOUD_SEARCH_TYPE] LANGUAGE [Neutral])
go
ALTER FULLTEXT INDEX ON [dbo].[DOC_VERSIE_TAAL] ADD ([TITEL_SEARCH_DE] LANGUAGE [Neutral])
go
ALTER FULLTEXT INDEX ON [dbo].[DOC_VERSIE_TAAL] ADD ([TITEL_SEARCH_EN] LANGUAGE [Neutral])
go
ALTER FULLTEXT INDEX ON [dbo].[DOC_VERSIE_TAAL] ADD ([TITEL_SEARCH_FR] LANGUAGE [Neutral])
go
ALTER FULLTEXT INDEX ON [dbo].[DOC_VERSIE_TAAL] ADD ([TITEL_SEARCH_NL] LANGUAGE [Neutral])
go
ALTER FULLTEXT INDEX ON [dbo].[DOC_VERSIE_TAAL] ENABLE
go

[P_de_B]

Dat zou heel goed kunnen. Deze code kun je dan via de SQL Agent uit laten voeren, bijvoorbeeld iedere ochtend om 5 uur.

[X-DraGoN]

Klopt, ik heb deze code nu achter de job van de sync als een volgende step geplakt.
Nu hopen dat het morgen goed gaat, ik hoop voor eens en altijd van die miserie af te zijn!

[X-DraGoN]

Nog eens bedankt allemaal voor de suggesties, ik laat morgen iets weten of het gewerkt heeft...

[X-DraGoN]

Deze morgen is de sync tussen de 2 verschillende SQL servers gelukt, de snapshot is op 2m en 16 seconden toegepast:

code:

2012-02-16 05:32:17.443 Delivered snapshot from the 'unc\BEBSCELLAPPACC$SQLAPPL2008_FISCDATA_SNAPSHOT_PUBLICATION_FISCDATA\20120216060018\' sub-folder in 129777 milliseconds
************************ STATISTICS SINCE AGENT STARTED ***********************
02-16-2012 06:32:17

Total Run Time (ms) : 131291      Total Work Time  : 129918
Total Num Trans     : 1     Num Trans/Sec    : 0.01
Total Num Cmds      : 670               Num Cmds/Sec     : 5.16
Total Idle Time     : 0 

Writer Thread Stats
  Total Number of Retries   : 0 
  Time Spent on Exec        : 12292 
  Time Spent on Commits (ms): 0               Commits/Sec         : 0.01
  Time to Apply Cmds (ms)   : 129918        Cmds/Sec            : 5.16
  Time Cmd Queue Empty (ms) : 31           Empty Q Waits > 10ms: 1
  Total Time Request Blk(ms): 31 
  P2P Work Time (ms)        : 0         P2P Cmds Skipped    : 0

Reader Thread Stats
  Calls to Retrieve Cmds    : 2 
  Time to Retrieve Cmds (ms): 63                Cmds/Sec            : 10634.92
  Time Cmd Queue Full (ms)  : 129839       Full Q Waits > 10ms : 345
*******************************************************************************

2012-02-16 05:32:17.453 Applied the snapshot to the Subscriber.

daarna is de Full Text Index aangemaakt met de volgende ‘opmerkingen’:

code:

Executed as user: domein\user. Warning: Table or indexed view 'dbo.WO_VERSIE' has full-text indexed columns that are of type image, text, or ntext. Full-text change tracking cannot track WRITETEXT or UPDATETEXT operations performed on these columns. [SQLSTATE 01000] (Message 7657)  Warning: Table or indexed view 'dbo.WO_VERSIE' has full-text indexed columns that are of type image, text, or ntext. Full-text change tracking cannot track WRITETEXT or UPDATETEXT operations performed on these columns. [SQLSTATE 01000] (Message 7657)  Warning: Table or indexed view 'dbo.WO_VERSIE' has full-text indexed columns that are of type image, text, or ntext. Full-text change tracking cannot track WRITETEXT or UPDATETEXT operations performed on these columns. [SQLSTATE 01000] (Message 7657)  Warning: Table or indexed view 'dbo.WO_VERSIE' has full-text indexed columns that are of type image, text, or ntext. Full-text change tracking cannot track WRITETEXT or UPDATETEXT operations performed on these columns. [SQLSTATE 01000] (Message 7657)  Warning: Table or indexed view 'dbo.WO_VERSIE' has full-text indexed columns that are of type image, text, or ntext. Full-text change tracking cannot track WRITETEXT or UPDATETEXT operations performed on these columns. [SQLSTATE 01000] (Message 7657)  Warning: Table or indexed view 'dbo.WO_VERSIE' has full-text indexed columns that are of type image, text, or ntext. Full-text change tracking cannot track WRITETEXT or UPDATETEXT operations performed on these columns. [SQLSTATE 01000] (Message 7657)  Warning: Table or indexed view 'dbo.WO_VERSIE' has full-text indexed columns that are of type image, text, or ntext. Full-text change tracking cannot track WRITETEXT or UPDATETEXT operations performed on these columns. [SQLSTATE 01000] (Message 7657)  Warning: Table or indexed view 'dbo.WO_VERSIE' has full-text indexed columns that are of type image, text, or ntext. Full-text change tracking cannot track WRITETEXT or UPDATETEXT operations performed on these columns. [SQLSTATE 01000] (Message 7657)  Warning: Table or indexed view 'dbo.DOC_VERSIE_TAAL' has full-text indexed columns that are of type image, text, or ntext. Full-text change tracking cannot track WRITETEXT or UPDATETEXT operations performed on these columns. [SQLSTATE 01000] (Message 7657)  Warning: Table or indexed view 'dbo.DOC_VERSIE_TAAL' has full-text indexed columns that are of type image, text, or ntext. Full-text change tracking cannot track WRITETEXT or UPDATETEXT operations performed on these columns. [SQLSTATE 01000] (Message 7657)  Warning: Table or indexed view 'dbo.DOC_VERSIE_TAAL' has full-text indexed columns that are of type image, text, or ntext. Full-text change tracking cannot track WRITETEXT or UPDATETEXT operations performed on these columns. [SQLSTATE 01000] (Message 7657)  Warning: Table or indexed view 'dbo.DOC_VERSIE_TAAL' has full-text indexed columns that are of type image, text, or ntext. Full-text change tracking cannot track WRITETEXT or UPDATETEXT operations performed on these columns. [SQLSTATE 01000] (Message 7657)  Warning: Table or indexed view 'dbo.DOC_VERSIE_TAAL' has full-text indexed columns that are of type image, text, or ntext. Full-text change tracking cannot track WRITETEXT or UPDATETEXT operations performed on these columns. [SQLSTATE 01000] (Message 7657).  The step succeeded.

Heeft iemand enig idee of bovenstaande iets is om rekening mee te houden naar de toekomst of kunnen we dat veilig negeren?