Forum Użytkownikow Subiekt GT
InsERT GT => Subiekt GT => Wątek zaczęty przez: PajDziku w Kwiecień 15, 2016, 14:08:15
-
Witam,
w dniu jutrzejszym planujemy przejść z darmowej wersji na wersję płatną (głównie ze względu ograniczeń SQL Expressa).
To jak przejść przez proces samej aktualizacji oprogramowania do zarządzania bazą pewnie gdzieś znajdę w internecie, jednak moje pytanie dotyczy, czy po takiej migracji, wymagane są jakieś dodatkowe działania na bazie? Mam tutaj na myśli, hmm, nie wiem jakieś indeksowanie, itp, tak aby nie było komplikacji w przyszłości. Ewentualnie, czy trzeba coś skonfigurować dodatkowo po instalacji płatnej wersji?
Z góry dzięki za odpowiedzi.
-
Nie trzeba nic robić z bazą.
-
Na taką odpowiedź liczyłem :D
Dzięki wielkie!
-
w dniu jutrzejszym planujemy przejść z darmowej wersji na wersję płatną (głównie ze względu ograniczeń SQL Expressa).
Jakie to ograniczenia, w czerwcu zeszłego roku baza danych miała rozmiar nieco ponad 2GB ? W czym Ci pomogło przejście na pełnego SQL'a, może podzielisz się przynajmniej wybranymi wynikami testów ?
-
Jakie to ograniczenia, w czerwcu zeszłego roku baza danych miała rozmiar nieco ponad 2GB ? W czym Ci pomogło przejście na pełnego SQL'a
Wydajnościowo pewnie wcale przy tak małej bazie i tak mało obciążonej. Ale na pełnej można skonfigurować automatyczne robienie backupów (można to obejść zewnętrznym softem) oraz można po awarii (jeśli model recovery to nie simple) po logu przywracać do dowolnego momentu przed awarią. W darmowej wersji jest dostępny tylko ostatni backup (i to bez kompresji, o ile pamiętam). To duża różnica.
-
Jakie to ograniczenia, w czerwcu zeszłego roku baza danych miała rozmiar nieco ponad 2GB ? W czym Ci pomogło przejście na pełnego SQL'a
Wydajnościowo pewnie wcale przy tak małej bazie i tak mało obciążonej. Ale na pełnej można skonfigurować automatyczne robienie backupów (można to obejść zewnętrznym softem) oraz można po awarii (jeśli model recovery to nie simple) po logu przywracać do dowolnego momentu przed awarią. W darmowej wersji jest dostępny tylko ostatni backup (i to bez kompresji, o ile pamiętam). To duża różnica.
ciągnąc temat backupów, czy znacie soft , który pozwoli mi na automatyczną archiwizację 200 baz danych ( nie mam na myśli biura gt oczywiście), ważne żeby nie trzeba było podpinac za każdym razem do listy archiwizowanych nowo utworzonej bazy tylko żeby automatycznie dopisywała się do listy itp. ( każda baza archiwizowana w oddzielnym pliku , nie tak jak w biurze gt
-
Jakie to ograniczenia, w czerwcu zeszłego roku baza danych miała rozmiar nieco ponad 2GB ? W czym Ci pomogło przejście na pełnego SQL'a
Wydajnościowo pewnie wcale przy tak małej bazie i tak mało obciążonej. Ale na pełnej można skonfigurować automatyczne robienie backupów (można to obejść zewnętrznym softem) oraz można po awarii (jeśli model recovery to nie simple) po logu przywracać do dowolnego momentu przed awarią. W darmowej wersji jest dostępny tylko ostatni backup (i to bez kompresji, o ile pamiętam). To duża różnica.
ciągnąc temat backupów, czy znacie soft , który pozwoli mi na automatyczną archiwizację 200 baz danych ( nie mam na myśli biura gt oczywiście), ważne żeby nie trzeba było podpinac za każdym razem do listy archiwizowanych nowo utworzonej bazy tylko żeby automatycznie dopisywała się do listy itp. ( każda baza archiwizowana w oddzielnym pliku , nie tak jak w biurze gt
Niedawno miałem taką prośbę w biurze rachunkowym, to rozwiązałem to za pomocą osql i procedury xp_cmdshell. Dodatkowy soft nie jest potrzebny.
-
Chris, dzieki za info, przedzwonię w przyszłym miesiącu jak się trochę ogarnę po kampanii PITowej
-
Gdzieś na forum jest skrypt, którego używam do backupu wszystkich baz.
-
Można w Archiwizatorze zrobić harmonogram dla każdego podmiotu osobno, tyle, że na początku trzeba się trochę naklikać.
-
w dniu jutrzejszym planujemy przejść z darmowej wersji na wersję płatną (głównie ze względu ograniczeń SQL Expressa).
Jakie to ograniczenia, w czerwcu zeszłego roku baza danych miała rozmiar nieco ponad 2GB ? W czym Ci pomogło przejście na pełnego SQL'a, może podzielisz się przynajmniej wybranymi wynikami testów ?
A takie, że zużycie ramu przy połączonych na raz ok. 15-20 użytkowników, jest maksimum 1,5Gb (w naszym przypadku, w dokumentacji sql expressa jest, że 1Gb). Wersja standard eliminuje to ograniczenie. Poza tym, osoba, która implementowała w tej firmie, jakieś 8 lat temu subiekta, podpowiedziała mi, że jest też nieformalne ograniczenie ilości jednoczesnych połączeń do (strzelam tutaj, bo nie pamiętam dokładnie) 10, każda kolejna osoba połączona do bazy będzie miała opóźnienia (nie wiem czy tyczy się to mechanizmu subiekta z wersją sql expressa, czy samego sql express).
-
To się tyczy systemu operacyjnego. Home - 5, Prof - 10 itd, choć to też nie tak do końca jednoznaczne.
-
w dniu jutrzejszym planujemy przejść z darmowej wersji na wersję płatną (głównie ze względu ograniczeń SQL Expressa).
Jakie to ograniczenia, w czerwcu zeszłego roku baza danych miała rozmiar nieco ponad 2GB ? W czym Ci pomogło przejście na pełnego SQL'a, może podzielisz się przynajmniej wybranymi wynikami testów ?
A takie, że zużycie ramu przy połączonych na raz ok. 15-20 użytkowników, jest maksimum 1,5Gb (w naszym przypadku, w dokumentacji sql expressa jest, że 1Gb). Wersja standard eliminuje to ograniczenie.
Liczba użytkowników NIE przekłada się bezpośrednio na wykorzystanie pamięci RAM... To przede wszystkim zależy od wykonywanych operacji i ich optymalizacji... Nie odpowiedziałeś też na najważniejsze pytanie - jak to wpłynęło na pracę w programie ? Czy efekty są warte poniesienia takich kosztów ?
Poza tym, osoba, która implementowała w tej firmie, jakieś 8 lat temu subiekta, podpowiedziała mi, że jest też nieformalne ograniczenie ilości jednoczesnych połączeń do (strzelam tutaj, bo nie pamiętam dokładnie) 10, każda kolejna osoba połączona do bazy będzie miała opóźnienia (nie wiem czy tyczy się to mechanizmu subiekta z wersją sql expressa, czy samego sql express).
Czyli od 8 lat podejmujesz decyzje na podstawie takich bzdur :o Tego typu ograniczenie miało MSDE 2000, ale od SQL'a 2005 (od około 11 lat) już go nie ma... Polecam jak najszybciej zrewidować swoją wiedzę we wszystkich istotnych kwestiach.
-
jak to wpłynęło na pracę w programie ? Czy efekty są warte poniesienia takich kosztów ?
Nie odpowiem Ci na to pytanie, gdyż wstrzymaliśmy się z instalacją wyższej wersji SQL (Standard runtime -insertu), gdyż obawiamy się, że po instalacji Standarda, po "puszczeniu" ograniczeń SQLa Expressa, sama usługa SQL, mogłaby zająć całą pamięć RAM (4GB DDR2 800Mhz - tak wiem, archaiczny sprzęt i planujemy już wymianę, po wymianie sprzętu, zostanie tam zainstalowany nowy SQL), nie wspominając już, że serwer obsługuje również inne funkcje, jak obsługę terminali.
8 lat podejmujesz decyzje na podstawie takich bzdur :o
Nie pisałem nic na temat podejmowania decyzji, tym bardziej od takiego okresu, gdyż pracuje w obecnej firmie o wiele wiele krócej.
Co do wiadomości, które uzyskałem odbieram je z dystansem - mam zdecydowanie mniejsze doświadczenie w bazach SQL (specjalizuję się w zupełnie czym innym), dlatego też w niektórych kwestiach piszę tutaj na forum.
Naczytałem się również wielu postów na tym forum (większość z nich z Twoim udziałem - mam tutaj na myśli dkozlowski), że baza insertu jest mocno niezoptymalizowana i poszczególne elementy trzeba osobno optymalizować, tak więc widzę, że bez wiedzy eksperckiej w tym temacie (spowolnienie pracy) SQL się tutaj nie obejdzie. Mam jedynie prośbę, aby zerknąć do pliku z wynikami zapytania sql, które udostępnił użytkownik właśni dkozlowski - ListTableInBase.sql i komentarz do nich. Z góry dzięki.
-
Nie odpowiem Ci na to pytanie, gdyż wstrzymaliśmy się z instalacją wyższej wersji SQL (Standard runtime -insertu), gdyż obawiamy się, że po instalacji Standarda, po "puszczeniu" ograniczeń SQLa Expressa, sama usługa SQL, mogłaby zająć całą pamięć RAM (4GB DDR2 800Mhz - tak wiem, archaiczny sprzęt i planujemy już wymianę, po wymianie sprzętu, zostanie tam zainstalowany nowy SQL)
Czyli podjęliście decyzję w oparciu o własną niewiedzę, zakładając że co jak co, ale ci którzy doradzają nie mogą mieć racji.
Brzmi rozsądnie ;)
A ilość pamięci RAM jaką może zająć serwer SQL to parametr, który się po prostu ustawia.
Można przydzielić "ile da rady", ale równie dobrze może to być 1,8GB albo 2.7GB
-
jak to wpłynęło na pracę w programie ? Czy efekty są warte poniesienia takich kosztów ?
Nie odpowiem Ci na to pytanie, gdyż wstrzymaliśmy się z instalacją wyższej wersji SQL (Standard runtime -insertu), gdyż obawiamy się, że po instalacji Standarda, po "puszczeniu" ograniczeń SQLa Expressa, sama usługa SQL, mogłaby zająć całą pamięć RAM (4GB DDR2 800Mhz - tak wiem, archaiczny sprzęt i planujemy już wymianę, po wymianie sprzętu, zostanie tam zainstalowany nowy SQL), nie wspominając już, że serwer obsługuje również inne funkcje, jak obsługę terminali.
Czyli nie posłuchaliście mojej rady i zdecydowaliście o zakupie bez przeprowadzenia wcześniejszych testów ?
Poza tym obawy kompletnie nie są uzasadnione - bez problemu można ograniczyć ilość pamięci RAM wykorzystywaną przez serwer SQL.
8 lat podejmujesz decyzje na podstawie takich bzdur :o
Nie pisałem nic na temat podejmowania decyzji, tym bardziej od takiego okresu, gdyż pracuje w obecnej firmie o wiele wiele krócej.
Co do wiadomości, które uzyskałem odbieram je z dystansem - mam zdecydowanie mniejsze doświadczenie w bazach SQL (specjalizuję się w zupełnie czym innym), dlatego też w niektórych kwestiach piszę tutaj na forum.
W takim razie na jakiej podstawie została podjęta decyzja o zakupie pełnej wersji serwera SQL ?
Naczytałem się również wielu postów na tym forum (większość z nich z Twoim udziałem - mam tutaj na myśli dkozlowski), że baza insertu jest mocno niezoptymalizowana i poszczególne elementy trzeba osobno optymalizować, tak więc widzę, że bez wiedzy eksperckiej w tym temacie (spowolnienie pracy) SQL się tutaj nie obejdzie. Mam jedynie prośbę, aby zerknąć do pliku z wynikami zapytania sql, które udostępnił użytkownik właśni dkozlowski - ListTableInBase.sql i komentarz do nich. Z góry dzięki.
Gdzie te dane ?
-
Czyli podjęliście decyzję w oparciu o własną niewiedzę, zakładając że co jak co, ale ci którzy doradzają nie mogą mieć racji.
Brzmi rozsądnie ;)
Nie pisałem tego wątku, aby się wykłucać, jednak nie napisałem nigdzie, że ci którzy doradzają nie mogą mieć racji, poza tym, decyzja o zakupie SQL w wersji standard, nie była podjęta tylko i wyłącznie w zakresie tego problemu.
Tak na marginesie, słyszeliście może o informacji, aby SQL Express przestał być bezpłatną wersją? Podobną Insert w aktualizacjach jeszcze w tym roku, będzie informował użytkowników, iż pracują na wersji Express i wymagane jest w przyszłości przejście na Standard? - taką informację uzyskałem od przedstawiciela jednej z firm współpracujących z insertem.
Gdzie te dane
W załączniku wiadmości - dołączyłem je minute po wysłaniu posta, zapomniałem przy pierwszej wysyłce.
-
Spoko, nie ma mowy o sporach.
Tak sobie kpię tylko troszkę ;)
-
Czyli podjęliście decyzję w oparciu o własną niewiedzę, zakładając że co jak co, ale ci którzy doradzają nie mogą mieć racji.
Brzmi rozsądnie ;)
Nie pisałem tego wątku, aby się wykłucać, jednak nie napisałem nigdzie, że ci którzy doradzają nie mogą mieć racji, poza tym, decyzja o zakupie SQL w wersji standard, nie była podjęta tylko i wyłącznie w zakresie tego problemu.
Czy masz świadomość, że runtime dla GT może pracować tylko z GT, NIE może pracować z innymi programami ?
Tak na marginesie, słyszeliście może o informacji, aby SQL Express przestał być bezpłatną wersją? Podobną Insert w aktualizacjach jeszcze w tym roku, będzie informował użytkowników, iż pracują na wersji Express i wymagane jest w przyszłości przejście na Standard? - taką informację uzyskałem od przedstawiciela jednej z firm współpracujących z insertem.
Zdecydowanie musiałeś coś źle zrozumieć... Dzieje się wprost przeciwnie, Microsoft daje coraz więcej za darmo i mało tego będzie można go uruchamiać na linuksach.
Gdzie te dane
W załączniku wiadmości - dołączyłem je minute po wysłaniu posta, zapomniałem przy pierwszej wysyłce.
Danych nie ma jeszcze jakoś specjalnie dużo, ale również duże znaczenie co ilość, a czasami większe ma ich układ. Zmieńcie najpierw sprzęt na "normalny" i dopiero wtedy wróć do tematu.
-
Czy masz świadomość, że runtime dla GT może pracować tylko z GT, NIE może pracować z innymi programami ?
GT? A nie całościowo dla insertu, o ile się nie mylę Nexo można na nim uruchomić?.. Ale tak, zdaję sobie z tego sprawę.
Tak na marginesie, słyszeliście może o informacji, aby SQL Express przestał być bezpłatną wersją? Podobną Insert w aktualizacjach jeszcze w tym roku, będzie informował użytkowników, iż pracują na wersji Express i wymagane jest w przyszłości przejście na Standard? - taką informację uzyskałem od przedstawiciela jednej z firm współpracujących z insertem.
Zdecydowanie musiałeś coś źle zrozumieć... Dzieje się wprost przeciwnie, Microsoft daje coraz więcej za darmo i mało tego będzie można go uruchamiać na linuksach.
Na 100% usłyszałem tak jak napisałem, tak więc dostałem błędną informację. Dzięki za sprostowanie.
Danych nie ma jeszcze jakoś specjalnie dużo, ale również duże znaczenie co ilość, a czasami większe ma ich układ. Zmieńcie najpierw sprzęt na "normalny" i dopiero wtedy wróć do tematu.
Tak też zrobimy. Dzięki wszystkim za cenne uwagi i pomoc w temacie. Dam znać o wynikach po modernizacji sprzętu.
-
Czy masz świadomość, że runtime dla GT może pracować tylko z GT, NIE może pracować z innymi programami ?
GT? A nie całościowo dla insertu, o ile się nie mylę Nexo można na nim uruchomić?.. Ale tak, zdaję sobie z tego sprawę.
Tak, nie byłem precyzyjny, nexo będzie można uruchomić, ale nie "cały InsERT".
-
ponieważ dyskusja jest bezsensu, zapytam czy podobał się wam ostatni odcinek Wikingów, oni chyba mieli runtime pod Paryżem w ostatnim odcinku ? :P
-
ponieważ dyskusja jest bezsensu, zapytam czy podobał się wam ostatni odcinek Wikingów, oni chyba mieli runtime pod Paryżem w ostatnim odcinku ? :P
Przyznam szczerze, że nie oglądałem żadnego odcinka Wikingów, za to pamiętam, że w filmie Forest Gump był runtime, a w zasadzie dużo run, a mało time.