Optimální zpracování velkého objemu dat   zodpovězená otázka

VB.NET

Zdravím,

chtěl bych poprosit o radu. Píši desktopovou aplikaci, která bude zpracovávat velký objem dat ve spolupráci s MS SQL Serverem. Konkrétně jde o program pro zálohování dat vybraných tabulek z SQL serveru. Kromě zálohy by program měl umožnit také obnovu dat těchto tabulek ze souborů zálohy.

Pokud k tomuto účelu použiji dataset, který naplním daty z SQL serveru a následně např. serializuju do nějakého binárního souboru na disku, je vše bez problémů. Problém nastane v okamžiku, kdy z SQL serveru načtu tabulku s větším množstvím dat (řádově stovky tisíc). V tento okamžik může dojít k situaci, že se data jednoduše do paměti nevlezou a program generuje vyjímku Out of memory exception.

Je mi jasné, že toto není optimální a hlavně nehospodárné řešení.

Je nějaký způsob, jak data z SQL do datasetu načítat po blocích a současně je "strkat" do binárního souboru, aniž by přetekla paměť?

Na místě by zřejmě bylo použití SqlDataReaderu. Je možné jeho stream nějak ihned serializovat do souboru?

A pokud bych uvažoval o opětovném načtení souboru ze zálohy, je možné toto provádět i opačně, tedy postupně číst soubor a zapisovat jeho obsah na SQL Server?

Budu vděčný za jakékoliv náměty.

Děkuji

nahlásit spamnahlásit spam -1 / 1 odpovědětodpovědět

Zkuste juknout na SQLDMO.BulkCopy, to by mohlo podstatným způsobem řešit Váš problém. Nebo cokoli jiného, co umí export přímo do souborů, ve smyslu

http://www.simple-talk.com/sql/database-...

Skutečně totiž nikdy nevíte, jak velké ty tabulky budou.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Nosíte zbytečně dříví do lesa. Na to už existuje nespočet aplikací, například oficiální SQL Server Management Studio (zdarma). Silně pochybuji, že byste napsal něco lepšího.

nahlásit spamnahlásit spam 1 / 1 odpovědětodpovědět

Děkuji za odpovědi.

V žádném případě nechci tvořit něco lepšího než je Management Studio. Jde o to mít po ruce jednoduchou aplikaci, která umožní okamžité zálohování dat vybraných tabulek s možností jejich pozdější obnovy.

S aplikací MSSQL pracuji již přes 10 let a z praxe vím, že takováto utilitka se často hodí. Vlastně již roky používám něco podobného napsaného ve Visual FoxPro. Zde je stažení dat z SQL do DBF souboru hračkou a to i pro tabulky čítající řádově miliony záznamů. O vše se stará VFP, která tabulku "stránkuje" a přetečení paměti tedy nehrozí.

Doba ale postoupila a já chtěl něco podobného napsat také v .NETu a narazil jsem na výše uvedenou skutečnost.

Mimochodem, mohu se zeptat, jak v Management Studiu jednoduše provedu zálohu dat vybrané tabulky? Napadá mne spuštění příkazu SELECT a v okně Result pak výsledek uložit (exportovat) do CSV. Jak bych ale měl postupovat při jednoduché obnově dat z takto vytvořeného souboru?

Děkuji

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Jednoduchá aplikace, která umí to co potřebujete, je Management Studio. Netvrďte tu, že s MSSQL děláte přes 10 let, když neznáte takovouto základní funkci. Vaše znalosti končí zřejmě u stoletého FoxPro, které se dnes už vůbec nepoužívá. SELECT a export do CSV? To snad nemůžete myslet vážně. Nainstalujte si Management Studio a chvíli si v něm hrajte, nebudu vám zde popisovat takové základní věci (vše je klikací a ovládané pomocí GUI, žádné SQL). Do psaní nějaké zálohovací aplikace se nepouštějte, jednak je tu Management Studio, které to umí a jednak byste nadělal víc škody než užitku.

nahlásit spamnahlásit spam 1 / 1 odpovědětodpovědět

Psal jsem, že používám Visual FoxPro a ne FoxPro. I když uznávám, i VFP je z dnešního pohledu již za horizontem. Právě z toho důvodu bych rád tohle napsal v .NETu.

SQL server skutečně používám již léta (již od verze 6.5). Vězte, že psaní skriptů v T-SQL je prakticky můj denní chleba. Záměrně jsem se chtěl vyhnout nástrojům jeko SSIS (dříve DTS) nebo provádění zálohy a obnovy celé databáze v Management studiu.

Možná jste měl na mysli vygenerování skriptu tabulky včetně přislušných příkazů INSERT, což v praxi není příliš použitelné při velkém objemu dat.

Jinou možnost, jak jednoduše z Management studia vytvořit zálohu vybrané tabulky, která by byla jednoduše obnovitelná mne opravdu nenapadá, ale rád si nechám poradit.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Základní otázka je: Budete dělat vždy zálohu z PC, na kterém ten server běží? Pokud ano, tak tam utility typu BCP prostě vždy budou a můžete je zavolat (z kódu, z uložené procedury na serveru a tak dále).

Pokud budete ale chtít zálohovat tu tabulku odkudkoliv, pouze prostředky .NETu z aplikace, která bude dejme tomu na jiném stroji a bude mít přístup k serveru řekněme pouze přes TCP/IP, tak na to budete muset jít jinak. Váš původní návrh byl v podstatě cesta správným směrem, pouze bych v případě velikých tabulek si nejprve velikost tabulky zjistil, a pak bych to načítal prostě po částech a "nějak" "někam" ukládal.

Generování INSERT příkazů je i při velkém objemu dat překvapivě použitelné. Vždyť můžete načítat řádek po řádku a výsledek ukládat do souboru (souborů). Budou veliké, ale dají se zazipovat.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Mělo by jít o univerzální prostředek, který by měl být schopen data zálohovat odkudkoliv přes TCP/IP s otevřeným portem 1433 (SQL Server) bez ohledu na verzi MS SQL (je jasné, že SQL server bude muset mít povoleno vzdálené přihlašování).

Skriptování je skutečně použitelné, ale co například, když bude tabulka obsahovat binární data, ve kterých budou uloženy např. obrázky atd?.

Mám něco podobného již vytvořeno, ale na bázi XML, což není pro zálohování zrovna ideální (vzhledem k velikosti výsledného souboru). Načítání z SQL řeším pomocí SqlDataReaderu a jeho hodnoty ihned ukládám pomocí XMLTextWriteru do souboru. Při obnově dat zase XMLTextReaderem načítám obsah XML souboru a řádek po řádku jej cpu na server.

Toto řešení je sice funkční, ale výkon celé aplikace není zrovna vysoký (zejména u obnovy dat).

Proto jsem se chtěl zeptat, jestli není nějaké jiné, vhodnější řešení, které by umožnilo efektivní stažení velkého balíku dat do samostatného souboru, aniž by se zbytečně plýtvalo systémovými prostředky (např. s využitím nějakého bufferování).

Děkuji mnohokrát.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Použijte buď bulk copy, anebo DataReader místo DataSetu. DataSet si vše načte to paměti, což je velmi neefektivní pro tohle použití. DataReader naopak umožňuje data zpracovávat průběžně.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Ano, již jsem tak učinil.

Děkuji Všem za odpovědí.

Myslím, že tímto může být vlákno považováno za uzavřené.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Ne, měl jsem na mysli klasické nástroje v Management Studiu pro zálohování a obnovení databáze, ne žádné skriptování, které je neefektivní. Už se prosím probuďte a začněte používat to Management Studio, lepší řešení prostě neuděláte. Zatím jste neuvedl jediný důvod proč Management Studio nepoužívat.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Tak tedy jeden důvod z mnoha...

Jak obnovíte zálohu databáze provedenou z MSSQL2008 na starší verzi (např. MSSQL2005) ?

A proč obnovovat zálohu provedenou novější verzí SQL serveru na starší verzi?

Tak například proto, že zákazník přechází z jiného informačního systému na nový a je potřeba nahrát převedená data v datových strukturách nového IS.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

To je naprosto nesmyslná věc, která se nikdy nedělá. Pokud chci zálohovat celou databázi, zálohuji vždy konkrétní verzi. Pokud mi jde o data, v Management Studiu se vytvoří skript pro jejich vytvoření (kompatibilní se všemi verzemi). Jak jednoduché.

Nesnažte se aplikovat archaické postupy snad ještě z dob DOSu (všelijaké plácání s DBF a export do CSV) na nejnovější databázové systémy.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Mohu se tedy zeptat, zda jste někdy převáděl data z různých účetních modulů nebo IS? A pokud ano, v jaké formě Vám byla data k převodu předána?

Nesnažte se mi prosím namluvit, že Vám někdo dal data k převodu ve formě zálohy SQL serveru.

Mluvím z letité zkušenosti nejen s tuzemskými IS, ale hlavně s těmi zahraničními.

Pracuji ve firmě, která vyvíjí a dodává vlastní informační systém již 15 let ne desítkám, ale stovkám velkých firem v tuzemsku i v zahraničí a s Vámi aplikovaným postupem jsem se doposud nesetkal.

nahlásit spamnahlásit spam -1 / 1 odpovědětodpovědět

Pletete dohromady dvě různé věci: Zálohování a obnovování databáze (například pro případ výpadku) a import libovolných dat do existující databáze. Pro tyto dvě věci jsou odlišné postupy.

nahlásit spamnahlásit spam -1 / 1 odpovědětodpovědět

Ano uznávám, že jsem se možná chybně vyjádřil. Asi je to tím, že mám zažitý způsob práce s daty s aplikací, kterou už léta používáme (samozřejmě kromě klasické serverové zálohy, která je spouštěna naplánovanými joby). Tou je myšlena rychlá archivace jednotlivých tabulek z SQL do souborů DBF.

Nám se skutečně v praxi tento postup velice osvědčil a nutno podotknout, že mnohdy nejednu firmu zachráníl před celkovou ztrátou dat, ke které došlo vinou pádu serveru a hlavně "lajdáctví" ze strany správce síťě, který nebyl schopen serverové zálohy zrcadlit nebo nahrát na jiné disky.

Díky tomu, že uživatelé měli možnost spouštět tuto zálohu na svém PC přímo z IS a archivovat ji na svém disku, bylo možné data obnovit.

Já se s Vámi v žádném případě nechci dohadovat o tom, zda je či není lepší použít pro zálohu a obnovu databáze nástrojů v Management studiu, respektive příkaz Backup Database a Restore Database (myšleno pro případ selhání hardwaru).

V tomto případě máte určitě pravdu, protože takováto záloha obsahuje kromě vlastních dat i ostatní serverové objekty (pohledy, funkce, uložené procedury, databázové uživatele,...) a je to tudíž komplexní záležitost.

Měl jsem na mysli spíše servisní případy, kdy je nutno nějakým způsobem upravovat část dat jejich extrakcí nebo již vzpomínaný převod dat při přechodu z jiného IS.

Vím, že i pro tento případ jsou k dispozici nástroje jako SSIS.

Celá diskuze ale nabrala poněkud jiný směr.

I tak děkuji za Vaše odpovědi.

nahlásit spamnahlásit spam 2 / 2 odpovědětodpovědět
                       
Nadpis:
Antispam: Komu se občas házejí perly?
Příspěvek bude publikován pod identitou   anonym.
  • Administrátoři si vyhrazují právo komentáře upravovat či mazat bez udání důvodu.
    Mazány budou zejména komentáře obsahující vulgarity nebo porušující pravidla publikování.
  • Pokud nejste zaregistrováni, Vaše IP adresa bude zveřejněna. Pokud s tímto nesouhlasíte, příspěvek neodesílejte.

přihlásit pomocí externího účtu

přihlásit pomocí jména a hesla

Uživatel:
Heslo:

zapomenuté heslo

 

založit nový uživatelský účet

zaregistrujte se

 
zavřít

Nahlásit spam

Opravdu chcete tento příspěvek nahlásit pro porušování pravidel fóra?

Nahlásit Zrušit

Chyba

zavřít

feedback