Automatyczne przyrostowe kopiowanie wybranych tabel pomiędzy różnymi serwerami DB

0

Dzień dobry,
Na jednym z serwerów (ms) stoi sobie db sql. (ms)
Chciałbym mieć możliwość stałego kopiowania części danych z wybranych tabel na osobny serwer do innej db sql (jeszcze nie wybrana).
Ideałem byłoby przeprowadzać operację raz dziennie w ustalonej z góry porze.
Minimalizacja obciążenia "źródła" jest priorytetem.

... a jestem w temacie zupełnie zielony ...

Mogę prosić o przybliżenie drogi, w jaką powinienem się udać?

3

Brzmi jak prostszy przypadek Replikacji Master Slave (Prostszy bo tylko raz dziennie)

0

Pytanie ile tych danych jest, bo jeżeli nie są to jakieś TB to mozna pokusić się o czyszczenie tabel docelowych i kopiowanie zwykłym skryptem SQL, z wykorzystaniem Linked Servera.
Ja masz tych danych dużo to trzeba by w jakiś sposob rozróżniać co jest do przegrania.
Replikacja jak najbardziej też się sprawdzi.

0

@Panczo

Danych w sumie nie ma zbyt dużo.
Generalnie to wybrane dane do wszelakich analiz i raportów.

Początkowo, Jedna tabela trochę większa, zawierająca wszelkie dane sprzedaży - w zasadzie będą to informacje wybrane z paragonów - jakieś 400 - 800 tyś miesięcznie. W sumie to ona pewnie się rozrośnie z czasem, ale cóż ... tych danych potrzebuję i nigdy nie będzie ich zbyt dużo :). Jak z czasem się z tym zrobi problem, to będę go wtedy rozwiązywał. Coś jednak mi mówi, że z czasem metoda czyszczenia i zbierania całości okaże się ślepą uliczką. Generalnie te akurat dane mogę sobie wybierać na różne sposoby. Jest sobie pole "counter" ewidentnie unikatowe wartości, które mogą się nadać. Są pola daty i czasu utworzenia każdego wpisu (na urządzeniu fiskalnym) też mogą być pomocne. Same numery dokumentów (paragonów) są unikatowe ... od biedy by mogły być. I ogólnie parę innych. Z tym problemem sobie poradzę.
Gorzej, że to mój pierwszy raz i ... nie wiem umiem nawet nazwać problemu, dlatego się pytam. :)

Reszta to kilka tabel pomocniczych, o rząd wielkości lub dwa mniejsze. W nich raczej ruch będzie niewielki. W przyszłości dojdzie tego trochę więcej, ale i ja mam nadzieję mieć wtedy i większą wiedzę i jakieś doświadczenie.

Nabyłem sobie dla nauki i zabawy starusieńkiego dell r710, na którym będą te wybrane dane i w sumie o niego się nie boję. Zasobów do moich celów wystarczy w nadmiarze. Gorzej ze źródłem ... Nie dość, że to mała popierdółka - prawie że desktop, to jeszcze ogólnie mieli te dane na prawo i lewo dla jakiś 100 końcówek.
Dlatego wolałbym zbierać dane w nocy, gdy obciążenie jest już prawie zerowe, po backupach i innych ważniejszych zadaniach.

@KamilAdam

Replikacja M-S
Szukam czytam i analizuję :)
Dziękuję za podpowiedź. Ciekawe do czego dojdę :)

0

Skoro piszesz o urządzeniu fiskalnym to zakładam, że dane się nie zmieniają. Więc mozna ładować przyrostowo do tabel.
Wiele zależy skąd dokąd to będziesz pchał. Bo jeśli replikacja to potrzebujesz 2 SQL Servery. Inne podejście to prosty skrypt, który zapamieta datę ostatniej synchronizacji i warunek where data_utworzenia>@data_ostatniej aktualizacji

Out of Box masz kilka mechanizmów, ktore możesz użyć: https://www.sqlshack.com/techniques-to-bulk-copy-import-and-export-in-sql-server/

0

To jak chcesz to robić po backupie - to może po prostu kopiuj backup i rób restore u siebie na "stanowisku" ;) zawsze jakaś opcja.

A ogólnie - ja stosuje metodę @Panczo - czyszczę codziennie w nocy około 200 tablic i kopiuje wszystkie dane z systemu ERP do nich ponownie. Dla 5 jobów które lecą równolegle całość zabiera około 10 min (jakbym po przesuwał między jobami pewne rzeczy to zszedł bym niżej). Sprawdziłem 1 większą tablice z sfinalizowanymi transakcjami dla 1 oddziału i tablica ma 5,5 kk rekordów i całkiem sporo kolumn to cała operacja zajmuje 1 min. Także może po prostu protestuj najpierw "proste rozwiązania".

0

Jeśli zwykła replikacja na bieżąco (zamiast raz dziennie) nie zda egzaminu, to opcji masz w sumie kilka:

IMO pierwsze i drugie podejście są "najczystsze", bo korzystasz w nich z narzędzi do tego przeznaczonych. W trzecim wariancie to już takie trochę hackowanie i wymyślanie koła na nowo.

0

Piszę o urządzeniu fiskalnym w tym kontekscie, że na serwer "źródło" spływają między innymi dane z POS-ów (nazwijmy je w skrócie urządzeniami fiskalnymi) Samych POSów mamy prawie 70, w ciągu roku zmieni się to do 100 i miejmy nadzieję, będzie się zwiększać dalej. Źródło dodatkowo jest podstawą całości oprogramowania sprzedażowo -produkcyjno - magazynowo ... wszystkim, na czym stoi przedsiębiorstwo, to dodatkowo około 30 osób korzystających z tego cały czas . Noc pomiędzy 2 a 4 rano to czas gdy przedsiębiorstwo śpi i wtedy mogę się wcisnąć bez narażania na problemy ciągłości pracy.
Sam sprzęt źródła, licencje itp jest nasz, ale oprogramowanie to twór autorski i nawet nie myślę o jakimkolwiek dotykaniu się całości. Co do tego urządzenia opcje mam 2

  • backupy są robione miejscowo, przez "nasze zasoby" i tędy mam jakąś drogę, ewentualnie coś, czego szukam właśnie tutaj :)
  • twórca wskazał mi miejsca i organizację zasobów w DB. Może też mi te dane udostępniać sam (opcja ostateczna - z różnych względów, głównie jednak niechęć do wpuszczania go w moje urządzenie)

Do swoich potrzeb (jak już wspomniałem) zakupiłem potwora dell. Na nim mam pełną swobodę i mogę robić co chcę, postawić co chcę i zmieniać jak chcę (ograniczają mnie jedynie finanse i fantazja). Chwilowo ma służyć tylko jako magazyn danych dla BI,później dołożę mu kilka zadań, ale to temat na inny dział.

Co do restore z backupów ... Problemem jest fakt, że twórca softu co jakiś czas uznaje bazę za zbyt dużą i zaczyna sprzątanie. W efekcie najczęściej zmienia DB na nową, stare zaś leżą odłogiem teoretycznie jako archiwalne dane. W praktyce twórca usuwa z nich co chce i jak chce, wedle własnego uznania. Na to sobie nie mogę pozwolić. Muszę mieć wszystko pod ręką, z jak najmniejszym prawdopodobieństwem ingerencji. O samym sprzątaniu DB na źródle wiem z wyprzedzeniem i mógłbym się do niego odpowiednio przygotować. Ewentualne kilka dni przestoju na dostosowanie się do jakiś zmian, nie są specjalnym problemem. Główne dane (z paragonów) są dodatkowo mocno sformalizowane więc tutaj twórca nie ma tak dużego pola do popisów.

Generalnie chcę rozwiązania, które:

  • Zapewni odpowiednie dane w odpowiednim miejscu.
  • Zrobi to w czasie gdy obciążenie źródła będzie najmniejszym z możliwych.
  • Pozwoli mi kolekcjonować dane z jak największego okresu czasu, uwzględniając fakt, że źródło co pewien czas pozbywa się "staroci"
  • Maksymalnie odseparuje dane od twórcy.

Z tego wszystkiego, w mojej (absolutnie bez wiedzy w zakresie) ocenie, przyrostowe zbieranie danych powinno spełnić część wymagań. Gdybym wybierał je po "Count" miałbym przy okazji możliwość przeciwdziałania w razie jakiś "potajemnych zmian". Nie mówię, że to się zdarza, ale ... nie każdemu dajemy klucze do własnego domu.

Dziękuję wszystkim za pomoc i propozycję.
Mam co czytać, sprawdzać i poznawać, więc czas się za to zabrać dogłębnie :)

1 użytkowników online, w tym zalogowanych: 0, gości: 1