Forum Użytkownikow Subiekt GT
InsERT GT => Subiekt GT => Wątek zaczęty przez: wawa69 w Marzec 21, 2014, 09:59:42
-
Czy warto wymienić zwykły dysk na dysk SSD żeby przyspieszyć działanie Subiekta?Czy akurat przy tym programie nie będzie to miało większego znaczenia.Program zaczyna już spowalniać i zaczyna już mnie to denerwować,że muszę czekać po kilka sekund aż się jakieś okienko zamknie lub otworzy.
Jeszcze jedno pytanie.Jak działa funkcja "blokada okresu".Czy zablokowane dane są bezpowrotnie usuwane?Jeżeli nie,to czy można usunąć całkowicie dokumenty (archiwalne ponad 5 lat) typu KW,KP,faktury,wz,pz itp.
-
Słowo blokada w swoim znaczeniu różni się od pojęcia usuwanie.
A w GT wykonuje się funkcje raczej w znaczeniu słownikowym.
Co do usuwania - zapisy w bazie stanowią jedną całość powiązaną chronologicznie. W zwiazku z tym nie ma możliwości usunięcia wcześniejszych danych. Oczywiście trzeba to rozpatrywać w pewnym kontekście, bo np. rok obrotowy, pomimo że jest kawałkiem całości, sam w sobie stanowi odrębną całość, ale jesli występują między latami powiązania rozrachunkowe, to też nie da się usunąć. A tym bardziej w Subiekcie, gdzie mamy ciągłość ruchu magazynowego.
Zablokowanie okresu nie przyspiesza pracy, bo nie zmniejsza bazy. Służy, zgodnie z nazwą, zablokowaniu pewnego okresu, aby w nim nie grzebać.
W szybkości obsługi Subiekta ważna jest przede wszystkim baza - czyli sql i jego wersje, zwiazane z jego wymaganiami parametry sprzętowe (RAM) i przy duzej ilości danych szybkość odczytu i zapisu na dysk, i tu się kłania SSD. Ale jako uzupelnienie poprzednich, a nie jako remedium na wszystko. Jest jeszcze coś takiego jak optymalizacja bazy danych, ale to już zadanie dla mających dużą wiedzę o GT i sql.
-
Dziękuję za odpowiedź.Nawet jeżeli nie była zbyt optymistyczna.Co do blokady okresu to właśnie to przeczuwałem,ale byłem pewien,że dysk SSD znacznie przyspieszy działanie Subiekta (bazy sql) w oparciu o już istniejącą konfigurację laptopa (Win7, I5 2,4GHz,6GB Ram).Czytałem kiedyś,że dyski SSD mają wpływ na większą wydajność ale nie we wszystkich programach,stąd moje pytanie.
-
Teoretycznie tak, ale warto prawdzić w praktyce. Tyle, że jeszcze jest to dosyć kosztowne. Mowa o SSD.
-
Ostatnio wymieniliśmy komputer serwer na nowy z procesorem Xeon7, pamięć 8 GB z Windows 7 Pro i dyskiem SSD, bo mieliśmy podobne problemy (działał coraz wolniej, zawieszał się Subiekt, baza ok. 1 GB). Jest duża różnica, Subiekt pracuje dużo szybciej, nie zawiesza się, Pracownice są zadowolone.
Myślę, że warto wymienić, ale to zależy od finansów firmy.
Pozdrawiam
-
A jaka wersja SQL?
Bo baza 1 GB to nie jest duża, taki średniak.
-
Chyba się zdecyduję.Pracuję z Subiektem po 9 godzin dziennie przez 6 dni w tygodniu i poprawa jakości pracy jest dla mnie bezcenna.
Nie wiem czy to do mnie pytanie ale ja mam wersję chyba SQL Server Express Edition (64-bit) (10.50.1600.1 (RTM) Taką mam inform.w programie serwisowym.
-
Poprzednio był SQL 2005, teraz jest SQL 2008 R2, Subiekt + Rewizor 1.34 HF2.
Pracują trzy komputery przez 10-11 godzin dziennie.
-
Chyba się zdecyduję.Pracuję z Subiektem po 9 godzin dziennie przez 6 dni w tygodniu i poprawa jakości pracy jest dla mnie bezcenna.
Nie wiem czy to do mnie pytanie ale ja mam wersję chyba SQL Server Express Edition (64-bit) (10.50.1600.1 (RTM) Taką mam inform.w programie serwisowym.
Tp jest 2008 R2 czyli ok.
-
Program zaczyna już spowalniać i zaczyna już mnie to denerwować, że muszę czekać po kilka sekund aż się jakieś okienko zamknie lub otworzy.
Chyba się zdecyduję. Pracuję z Subiektem po 9 godzin dziennie przez 6 dni w tygodniu i poprawa jakości pracy jest dla mnie bezcenna.
Jeśli mocno nie przebarwiłeś swojej wypowiedzi to takie czasy odpowiedzi programu są tragicznie długie (pomijam dokumenty z setkami/tysiącami pozycji i zestawienia) i powinieneś poszukać przyczyn i rozwiązań rok, dwa lata temu, może nawet wcześniej. W takiej sytuacji nie posiadanie jeszcze dysku SSD i stwierdzenie, że poprawa jakości pracy jest dla Ciebie bezcenna jest według mnie sprzecznością.
Jeśli program rzeczywiście działa tak wolno jak opisujesz na takim dość mocnym sprzęcie to sam szybszy dysk może niewiele zmienić w tej sytuacji. Mogą to być już problemy wydajnościowe, których nie da się obejść mocniejszym sprzętem. Polecam poszukać moich wypowiedzi na forum odnośnie optymalizacji bazy danych, powinny być również przykładowe wyniki optymalizacji, gdzie wszystkie takie prace wykonywałem na szybkim sprzęcie z szybkim dyskiem SSD jako jeden jedyny użytkownik i prędkość działania programu na otrzymanych bazach danych była nie do zaakceptowania.
Tak czy inaczej polecam wymianę dysku na SSD dla każdego kto intensywnie wykorzystuje komputer, osobiście nie wyobrażam już sobie inaczej pracować. Dzisiejsze "domowe" dyski już przy pojemnościach 120 GB osiągają transfery bliskie możliwościom SATA III i kosztują już tylko około 300 zł brutto. Oczywiście dyski SSD "serwerowe" to już inny temat.
-
Witam. Zastanawiam się nad wymianą dysków talerzowych na SSD w serwerze, który pracuję 24H/365
Czy możecie mi polecić konkretne modele dysków SSD do serwera ? Mam już 3 serwer i zawsze pracowały tam dyski talerzowe, zastanawiam się jak z awaryjnością dysków SSD ? Są różne opinie, w większości słyszę głosy, że talerzowe są bardziej odporne i mniej problemowe.
We wszystkich innych komputerach prócz serwera mam zainstalowane dyski SSD i wszystko hula, ale one nie pracują na okrągło.
Pozdrawiam Michał
-
@mike81
Na swoim przykładzie: ~6 lat bezawaryjnej pracy na dyskach Intela w RAID 10. Grunt to wstawić dyski przeznaczone do pracy w serwerach a nie najtańsze konsumenckie i zapewnić odpowiednią ilość wolnego miejsca na przyrost danych - wydajność SSDków spada gdy są zapchane. W tym samym serwerze mam jeszcze 2 talerze, z których jeden uległ awarii gdzieś po 2 latach i poszedł na gwarancję.
YMMV
-
Są specjalne dyski SSD do pracy ciągłej. Oczywiście odpowiednio droższe... :-(
Ale jakich byś nie kupili, to i tak pamiętaj, że muszą być przynajmniej dwa. Odzyskiwanie danych z padniętych dysków SSD jest bez porównania trudniejsze (czyt. droższe) niż z HDD i success-rate znacznie niższy, więc nie ma co oszczędzać na radzie... :-)
-
Odzyskiwanie danych z padniętych dysków SSD jest bez porównania trudniejsze
I dlatego robi się backupy baz i całego OS, niezależnie od tego czy dyski są w RAIDzie czy nie. Bo robisz backupy, prawda @mike81? :)
-
Odzyskiwanie danych z padniętych dysków SSD jest bez porównania trudniejsze
I dlatego robi się backupy baz i całego OS, niezależnie od tego czy dyski są w RAIDzie czy nie. Bo robisz backupy, prawda @mike81? :)
Hej. tak robię backup codziennie
-
@mike81
Na swoim przykładzie: ~6 lat bezawaryjnej pracy na dyskach Intela w RAID 10. Grunt to wstawić dyski przeznaczone do pracy w serwerach a nie najtańsze konsumenckie i zapewnić odpowiednią ilość wolnego miejsca na przyrost danych - wydajność SSDków spada gdy są zapchane. W tym samym serwerze mam jeszcze 2 talerze, z których jeden uległ awarii gdzieś po 2 latach i poszedł na gwarancję.
YMMV
A co myślicie o dysku ?
Intel DC S4510 Series 480GB (SSDSC2KB480G801)
Dysk SSD o pojemności 480GB, format 2,5cala, zapis - 490MB/s
dziwne, że wersja 240GB ma zapis połowę niższy. Jakaś alternatywa ? Z góry dzięki
-
@mike81
Na swoim przykładzie: ~6 lat bezawaryjnej pracy na dyskach Intela w RAID 10. Grunt to wstawić dyski przeznaczone do pracy w serwerach a nie najtańsze konsumenckie i zapewnić odpowiednią ilość wolnego miejsca na przyrost danych - wydajność SSDków spada gdy są zapchane. W tym samym serwerze mam jeszcze 2 talerze, z których jeden uległ awarii gdzieś po 2 latach i poszedł na gwarancję.
YMMV
A co myślicie o dysku ?
Intel DC S4510 Series 480GB (SSDSC2KB480G801)
Dysk SSD o pojemności 480GB, format 2,5cala, zapis - 490MB/s
dziwne, że wersja 240GB ma zapis połowę niższy. Jakaś alternatywa ? Z góry dzięki
-
dziwne, że wersja 240GB ma zapis połowę niższy.
Bo ma więcej kości a to znaczy, że zapisuje część danych na jednym zestawie kości, resztę na drugim. Taki wewnętrzny RAID0 :)
-
@mike81
Na swoim przykładzie: ~6 lat bezawaryjnej pracy na dyskach Intela w RAID 10. Grunt to wstawić dyski przeznaczone do pracy w serwerach a nie najtańsze konsumenckie i zapewnić odpowiednią ilość wolnego miejsca na przyrost danych - wydajność SSDków spada gdy są zapchane. W tym samym serwerze mam jeszcze 2 talerze, z których jeden uległ awarii gdzieś po 2 latach i poszedł na gwarancję.
YMMV
Nie wiem dlaczego nie potrafię odpowiedź na forum, bo mnie wylogowuję :)
A więc muszę cytować, który dysk byś wybrał :
Intel DC S4510 Series 480GB (SSDSC2KB480G801)
Samsung 860 PRO 512GB 2,5" (MZ-76P512B/EU)
-
Podepnę się pod temat. Kupiłem dysk SSD na początku roku i jakoś mi zeszło, żeby przenieść na niego dane. W sumie to nawet nie podłączyłem pod kompa :)
Na chwilę obecną mam kompa Win10; i7; 3,4GHz; 16GB i dwa dyski:
1 dysk SSD "C" z systemem i SQL Server 2014 SP2 + kilka podstawowych programów.
2 dysk HDD "D" i tu mam bazę danych Subiekta + reszta plików "prywatnych"
Zakupiony dysk SSD chcę podpiąć jako 3 i przenieść tam dane z subiekta.
1. Czy jest sens instalować nowy SQL na tym trzecim dysku, czy pozostawić tak jak jest i przenieść tylko bazę z 2 HDD na 3 dysk SSD?
2. Przenosząc bazę rozumiem, że mam skopiować tylko te dwa pliki zaznaczone strzałką w załączniku (z tego obecnie korzysta program) - odłączyć w programie serwisowym i podłączyć wskazując pliki w nowej lokalizacji. Czy to by było wszystko?
3. Wracając do załącznika - kopia 2 i 3 zostały odłączone w programie serwisowym i ich w nim nie widać. Czy mogę bez obaw z poziomu foldera usunąć te 2 kopie (4 pliki)?
4. Czy Subiekt korzysta z jakiś plików powyżej "Socha.mdf" (załącznik)
-
Podepnę się pod temat. Kupiłem dysk SSD na początku roku i jakoś mi zeszło, żeby przenieść na niego dane. W sumie to nawet nie podłączyłem pod kompa :)
Na chwilę obecną mam kompa Win10; i7; 3,4GHz; 16GB i dwa dyski:
1 dysk SSD "C" z systemem i SQL Server 2014 SP2 + kilka podstawowych programów.
2 dysk HDD "D" i tu mam bazę danych Subiekta + reszta plików "prywatnych"
Zakupiony dysk SSD chcę podpiąć jako 3 i przenieść tam dane z subiekta.
1. Czy jest sens instalować nowy SQL na tym trzecim dysku, czy pozostawić tak jak jest i przenieść tylko bazę z 2 HDD na 3 dysk SSD?
2. Przenosząc bazę rozumiem, że mam skopiować tylko te dwa pliki zaznaczone strzałką w załączniku (z tego obecnie korzysta program) - odłączyć w programie serwisowym i podłączyć wskazując pliki w nowej lokalizacji. Czy to by było wszystko?
3. Wracając do załącznika - kopia 2 i 3 zostały odłączone w programie serwisowym i ich w nim nie widać. Czy mogę bez obaw z poziomu foldera usunąć te 2 kopie (4 pliki)?
4. Czy Subiekt korzysta z jakiś plików powyżej "Socha.mdf" (załącznik)
Najszybciej zrobisz to archiwizatorem:
https://www.insert.com.pl/dla_uzytkownikow/e-pomoc_techniczna/2289%2Cjak-przeniesc-dane-na-inny-komputer-w-insert-gt.html
dzięki czemu zapewnisz jednolitość plików, np wzorców.
-
Nie wiem skąd ten powracający pomysł z odłączaniem i podłączaniem, ale to niezalecana metoda.
Znacznie lepszą jest archiwizacja i dearchiwizacja.
-
Po prostu czytając forum natknąłem się na kilka takich tematów i w nich właśnie znalazłem takie rozwiązanie.
OK, skoro mam to zrobić przez archiwizację to mam zrobione archiwum (dwa pliki .i01 i .iar). SQL Mam zostawić tak jak jest na dysku C.
W pomocy jak przenieść dane jest info: "Utworzyć na dysku C: dwa nowe foldery (jest to podyktowane zabezpieczeniami i uprawnieniami systemu Windows)" - Czy w moim przypadku mam utworzyć to samo na docelowym dysku "E" zamiast na dysku "C"?
Czy dobrze to robię:
1. Na moim dysku "E" tworzę dwa foldery (co z zabezpieczeniami i uprawnieniami?)
2. Do jednego kopiuję oba pliki archiwum, a drugi pozostawiam pusty
3. Robię Dearchiwizuj i wskazuje plik archiwum z dysku "E"
4. Podaję nową nazwę podmiotu
-
Procedura ok.
Uprawnienia zazwyczaj trzeba nadać kiedy foldery są na dsyku systemowym (zazwyczaj c)
Tego drugiego folderu można użyć jako roboczego w procesie dearchiwizacji.
-
Chyba nie do końca dobrze to zadziałało, ale robiłem wszystko według tej instrukcji.
Dearchiwizacja przebiegła poprawnie. Została utworzona nowa baza, ale lokalizacja nadal jest ta sama co była :-[
-
Lokalizacja bazy?
Nic dziwnego.
Przecież w archiwizatorze się tego nie określa w ogóle. Tam podaje się tylko lokalizację archiwum i folder tymczasowy.
Archiwizator odtwarza bazę w domyślnym folderze baz dla serwera SQL, który określiliśmy w czasie instalacji serwera SQL.
-
Przecież pytałem o przeniesienie bazy do innej lokalizacji.
OK, w takim razie ponawiam pytanie - Jak przenieść bazę danych na inny dysk?
-
Przecież pytałem o przeniesienie bazy do innej lokalizacji.
OK, w takim razie ponawiam pytanie - Jak przenieść bazę danych na inny dysk?
Przecież @candy wyjaśnił:
Archiwizator odtwarza bazę w domyślnym folderze baz dla serwera SQL, który określiliśmy w czasie instalacji serwera SQL.
Należy ponownie zainstalować serwer SQL...
-
Nie pozostaje nic innego jak przeinstalowanie Sql.
Pytałem wcześniej jak przenieść dane i odniosłem się do kilku wątków na forum gdzie polecali odłączenie, przeniesienie i podłączenie bazy danych http://forumsubiekta.pl/subiekt/zmiana-lokalizacji-na-dysku-bazy-danych/ lub http://forumsubiekta.pl/subiekt/przeniesienie-bazy-danych-na-inny-dysk-w-tym-samym-komputerze/15/. Tutaj zostałem pokierowany, że to niezalecana operacja
Nie wiem skąd ten powracający pomysł z odłączaniem i podłączaniem, ale to niezalecana metoda.
Znacznie lepszą jest archiwizacja i dearchiwizacja.
Trochę mnie to zdziwiło, że archiwizacja przeniesie mi bazę na inny dysk, więc dopytałem jeszcze raz wskazując wszystkie kroki i tu zostało potwierdzone
Procedura ok.
-
Nie pozostaje nic innego jak przeinstalowanie Sql.
Pytałem wcześniej jak przenieść dane i odniosłem się do kilku wątków na forum gdzie polecali odłączenie, przeniesienie i podłączenie bazy danych http://forumsubiekta.pl/subiekt/zmiana-lokalizacji-na-dysku-bazy-danych/ lub http://forumsubiekta.pl/subiekt/przeniesienie-bazy-danych-na-inny-dysk-w-tym-samym-komputerze/15/. Tutaj zostałem pokierowany, że to niezalecana operacja
Nie wiem skąd ten powracający pomysł z odłączaniem i podłączaniem, ale to niezalecana metoda.
Znacznie lepszą jest archiwizacja i dearchiwizacja.
Trochę mnie to zdziwiło, że archiwizacja przeniesie mi bazę na inny dysk, więc dopytałem jeszcze raz wskazując wszystkie kroki i tu zostało potwierdzone
Procedura ok.
Akurat ja źle zrozumiałem Twoje pytanie i niestety archiwizacja nie przeniesie na inny dysk, jedyne poprawne rozwiązanie (działające również podczas konwersji) to przeinstalowanie SQL-a. W Twoim przypadku metoda odłączenia i podłączenia jest najprostszym, działającym rozwiązaniem. Przeniesiona baza będzie tam już zawsze.
-
OK, dzięki @Chris czyli rozumiem, że mimo wszystko lepiej przeinstalować Sql na nowo, niż iść na skróty z odłączeniem bazy i mieć z tym później problemy