11 odpovědí na toto téma

[Kreten8]

Mám databázi na disku d: nicméně pokud spustím VACUUM databáze, tak se něco o velikosti databáze ukládá kamsi na disk C: - nepodařilo se mi najít kde tento soubor vzniká - všechny adresáře měly pořád stejnou velikost, pouze ubývalo volné místo na disku. Přišel jsem na to náhodou, když se mi c: trochu víc zaplnilo nějakým balastem a VACUUM skončilo s chybou, že nemá volné místo. Teď si chci pořídit nový SSD disk a tak bych rád tento vytvářený soubor přesměroval na jiný disk, aby se mi ten SSD disk zbytečně neopotřebovával. Hledal jsem i na stránkách SQLite, ale nikde se mi nepodařilo nic najít.

Takže mám dvě otázky:

1. co a kde to vzniká na tom disku c: při provádění VACUUM databáze

2. jak to přesměrovat na jiný disk (pokud to nelze žádným parametrem přesměrovat, tak když budu znát odpověď na první otázku, tak mohu danou složku namapovat na jiný disk)

 

Předem děkuji za případné rady od odborníků na SQLite.

[HaLuMa]

Vsechny docasne soubory si Sqlite dela v TEMP adresari, takze zalezi na tom, kam ti ukazuji promenne systemu TMP nebo TEMP.

[MaFa]

Pokud si hodis databazi primo na ten SSD, tak zadny VACUUM nemusis resit. Mam to tak udelany a je to vyrazne rychlejsi nez z disku. Opotrebovani SSD se normalni uzivatel opravdu bat nemusi. SSD snese nekolik tisic prepsani, takze i kdyby jsi prepsal cely SSD kazdy den, tak ti par let vydrzi.

[Arne1]

Pokud si hodis databazi primo na ten SSD, tak zadny VACUUM nemusis resit. Mam to tak udelany a je to vyrazne rychlejsi nez z disku. Opotrebovani SSD se normalni uzivatel opravdu bat nemusi. SSD snese nekolik tisic prepsani, takze i kdyby jsi prepsal cely SSD kazdy den, tak ti par let vydrzi.

Jeden z důvodů, proč jsem si pořizoval SSD :-)
Ale mám tam jiný problém - a sice že mi část drahého SSD prostoru zbytečně zabírají bezpečnostní kopie archivních databází. Tady bych uvítal, kdyby se dalo nastavit aby se u vyjmenovaných databází nedělala bezpečnostní kopie (tedy nejlépe další parametr v "Přidružené nastavení") ale do toho se HaLuMovi nechce.

Tento příspěvek byl upraven od Arne1: 21 říjen 2014 - 18:36

[Arne1]

Pokud si hodis databazi primo na ten SSD, tak zadny VACUUM nemusis resit.

Téhle formulaci moc nerozumím - VACUUM dělám proto, abych fyzicky zlikvidoval smazané záznamy. Jde to ještě nějak jinak ?

[ProKesTom]

 SSD snese nekolik tisic prepsani, takze i kdyby jsi prepsal cely SSD kazdy den, tak ti par let vydrzi.

cca 10 tisíc. To u těch pomalejších, trvanlivějších. Ale podstatné je, že do některých míst (záleží na typu filesystému) se zapisuje při zápisu jakéhokoli souboru. Takže k tomu, aby byl disk nefunkční, rozhodně zdaleka nemusíš přepisovat denně celý disk.

[Arne1]

cca 10 tisíc. To u těch pomalejších, trvanlivějších. Ale podstatné je, že do některých míst (záleží na typu filesystému) se zapisuje při zápisu jakéhokoli souboru. Takže k tomu, aby byl disk nefunkční, rozhodně zdaleka nemusíš přepisovat denně celý disk.

No ale k zabránění tohoto jevu by SSD měl mít algoritmy které ten počet zápisů vyrovnávají.

[HaLuMa]

cca 10 tisíc. To u těch pomalejších, trvanlivějších. Ale podstatné je, že do některých míst (záleží na typu filesystému) se zapisuje při zápisu jakéhokoli souboru. Takže k tomu, aby byl disk nefunkční, rozhodně zdaleka nemusíš přepisovat denně celý disk.

 

Coz je uplne jedno, protoze dneska kazde SSD ma WearLeveling. To je tam prave proto, aby tebou popsany problem neexistoval. I kdyz budes dokolecka prepisovat jen jeden blok, Wearleveling zpusobi, ze ten jeden blok bude postupne mapovan na jine fyzicke bunky a cela pamet se tak opotrebovavala rovnomerne.

 

Dneska uz tim oplyvaji treba SD karty, nebo i treba ty interni flashpameti v Garminech.

[HaLuMa]

Téhle formulaci moc nerozumím - VACUUM dělám proto, abych fyzicky zlikvidoval smazané záznamy. Jde to ještě nějak jinak ?

 

To mas jednoduche, kvuli tomu to vubec nedelej! Hodi se to jen ve trech pripadech:

1. potrebujes defragmentovt databazi
2. potrebujes opravit mirne nakopnutou databazi
3. smazal jsi z databaze opravdu mnoho dat a potrebujes z praktickeho hlediska smrsknout databazovy soubor.

Pri bezne cinnosti zadne misto uvolnovat nemusis. Smazane kusy byly v databazovem souboru oznaceny jako volne, a jakmile bude neco chtit do databaze pridat nova data, zapise se to do tech existujicich volnych bloku. Vyuziti stavajiciho mista je rychlejsi, nez zvetsovani velikosti souboru. Krom toho, ze to zvetsovani velikosti souboru se malokdy povede udelat tak, aby nevznikala fragmentace.

[HaLuMa]

Pro predstavu: SSD, ktere uz tri roky (cisteho provozniho casu!) nijak nesetrim, bydli na nem TEMP i SWAP, zpracovavam na nem data... tak ten se stacil prepsat 47x. Odhadovanou zivotnost mi to ukazuje do roku 2021.

 

Takze - lidi, neblaznete!

[Arne1]

To mas jednoduche, kvuli tomu to vubec nedelej! Hodi se to jen ve trech pripadech:

• 
  
• potrebujes defragmentovt databazi
• potrebujes opravit mirne nakopnutou databazi
• smazal jsi z databaze opravdu mnoho dat a potrebujes z praktickeho hlediska smrsknout databazovy soubor.

Pri bezne cinnosti zadne misto uvolnovat nemusis. Smazane kusy byly v databazovem souboru oznaceny jako volne, a jakmile bude neco chtit do databaze pridat nova data, zapise se to do tech existujicich volnych bloku. Vyuziti stavajiciho mista je rychlejsi, nez zvetsovani velikosti souboru. Krom toho, ze to zvetsovani velikosti souboru se malokdy povede udelat tak, aby nevznikala fragmentace.

Tomu se ani neprotivím... Já dělám VACUUM pouze na přenosové databázi do aDrake, protože mi to připadá jednodušší než ji pokaždé smazat a vytvářet znovu. A pak na archívech když z nich něco významného odmažu.

[Kreten8]

Takže díky Halumovi za odpověď, že za to mohou proměnné TMP či TEMP. Jejich přesměrování na jiný disk zafunguje. Nicméně jak jsem si ověřil praktickým pokusem je rychlejší mít TMP na jiném disku než je komprimovaná databáze, než když TMP ukazuje na stejný disk. Takže nebudu řešit zbytečné opotřebení disku C: kam defaultně ukazuje TMP. Pohrával jsem si totiž i s myšlenkou, že když se vytvoří tmp soubor na stejném disku, že by jeho přejmenování mohlo být rychlejší, když bude na stejném disku, než když se musí přesouvat z disku jiného.