Forum Użytkownikow Subiekt GT
InsERT GT => Subiekt GT => Wątek zaczęty przez: lublinkermi w Luty 12, 2019, 08:26:34
-
Witam, od dłuższego czasu szukałem działającego rozwiązania do MSSQL pod Linuxem. Powód jest oczywisty - wydajność. W Windows system generuje setki procesów, szuka wiatru na dysku etc. etc. Poświęciłem na to trochę czasu, ale się opłaciło. Sprawdzone zostało wszystko poza Biuro GT, ale myślę, że też będzie działać.
Opis instalacji dotyczy dystrybucji CENTOS 7, ale myślę, że na innych będzie też działać.
[INSTALACJA CENTOS 7]
1. Przy instalacji trzeba ustawić: IP komputera na stałe;
2. Nazwa komputera [host w ustawieniach sieci] nie może mieć kropki, ani polskich znaków. Domyślnie instalator przyjmuje nazwę localhost.localdomain. W mojej instalacji zmieniłem to na MSSQLSRV;
3. Przy tworzeniu pierwszego użytkownika należy zaznaczyć opcję 'ADMINISTRATOR';
Po zainstalowaniu systemu i zaakceptowaniu umowy licencyjnej logujemy się i jako root instalujemy repozytoria epel release.
Następnie można wykonać skrypt:
# /bin/bash
yum install system-config-users
yum install -y -q p7zip p7zip-plugins
curl https://packages.microsoft.com/config/rhel/7/mssql-server-2017.repo -o /etc/yum.repos.d/mssql-server-2017.repo
curl https://packages.microsoft.com/config/rhel/7/prod.repo -o /etc/yum.repos.d/msprod.repo
yum -y install mssql-server mssql-tools unixODBC-devel
echo 'export PATH=$PATH:/opt/mssql-tools/bin' > /etc/profile.d/mssql.sh
source /etc/profile.d/mssql.sh
/opt/mssql/bin/mssql-conf setup
mkdir /data
mkdir /mssqldb
mkdir /mssqldb/backup
mkdir /mssqldb/data
chown mssql:mssql /mssqldb -R
chmod 777 /data
/opt/mssql/bin/mssql-conf set filelocation.defaultbackupdir /mssqldb/backup
/opt/mssql/bin/mssql-conf set filelocation.defaultdatadir /mssqldb/data
systemctl stop mssql-server
echo 'Wpisz Polish_CI_AS'
/opt/mssql/bin/mssql-conf set-collation
firewall-cmd --add-port=1433/tcp --permanent
firewall-cmd --permanent --zone=public --add-services=samba
firewall-cmd --permanent --zone=public --add-service=samba
firewall-cmd --reload
systemctl enable smb.service
systemctl enable nmb.service
service smb start
service nmb start
service mssql-server start
useradd mssqldb -G mssql, wheel -m -p mssqldb
echo 'mssqldb ALL=(ALL) ALL' >>/etc/sudoers
Trzeba koniecznie wykonać operację
echo 'Wpisz Polish_CI_AS'
/opt/mssql/bin/mssql-conf set-collation przed podłączeniem jakiejkolwiek bazy - inaczej ani Rachmistrz, ani Rewizor nie zaktualizują się.
Ponadto w instalacji ('gotowiec') plik /opt/mssql/mssql.conf ma wyglądać tak:
[sqlagent]
enabled = false
[EULA]
accepteula = Y
[language]
lcid = 1033
[filelocation]
defaultbackupdir = /mssqldb/backup/
defaultdatadir = /mssqldb/data/
defaultdumpdir = /mssqldb/data/
defaultlogdir = /mssqldb/data/
Ustawienie katalogu tymczasowego dla potrzeb aktualizacji:
Trzeba w katalogu na kliencie utworzyć katalog TEMP:
c:\users\[nazwa_uzytkownika_w_windows]\TEMP
Standardowy archiwizator nie będzie działać, dlatego napisałem swój i jest dostępny pod adresem:
https://drive.google.com/file/d/1CWWwUIFQIrnWoP4uNu8Tk821rP0oew25/view?usp=sharing
Umożliwia on archiwizację "ręczną" jak i automatyczną. Jest napisany do współpracy z Linuxem.
Wymaga użytkownika linuxa, który przez 'sudo' może zmienić atrybuty plików w systemie linux.
W załącznikach instalka mssql servera i plik konfiguracyjny mssql. Oczywiście po zapisaniu na linuxie muszą one mieć atrybuty 777.
Nie gwarantuję, że będzie działać na Waszej instalacji, nie sposób wszystko przewidzieć, ale u mnie na 'świeżo' postawionym systemie zadziałało.
-
U mnie standardowy archiwizator zadziałał.
-
Witam, od dłuższego czasu szukałem działającego rozwiązania do MSSQL pod Linuxem. Powód jest oczywisty - wydajność.
1. Czy rzeczywiście "widać" różnicę w wydajności? Robiłeś jakieś testy?
2. Zasadniczo żeby porównać faktyczną wydajność "gołego" Linuksa z Windowsem należałby użyć do porównania Windows Core, a nie pełnego systemu (który "szuka wiatru na dysku"...). Próbowałeś?
-
"Goły" linux nie jest całkiem goły (nie pisałem o gołym linuxie tylko o świeżej instalacji) - funkcjonalnie odpowiada SQL Serwer 2012, uruchamiany jest w trybie graficznym etc. etc., ma możliwość zdalnego ustawiania wszystkich parametrów systemu. Co do testów... Od tego są odpowiednie instytucje posiadające odpowiednią wiedzę. Mnie wystarczyło posadzenie linuxa z bazami na tym samym komputerze w biurze rachunkowym (120 podmiotów, 10 stanowisk pracy) i odpowiedź pań księgowych, że pracuje się dużo szybciej i nie muszą czekać, szczególnie przy zmianie podmiotu.
Ale nie to jest przedmiotem mojego postu - nie będę się dalej wdawać w dyskusje nie na temat.
Post jest przeznaczony dla ludzi, którzy chcą mieć mssql na linuxie, a nie działa im standardowy archwizator - daję gotowy darmowy program, który tworzy takie archiwum, potrafi je odtworzyć, może przenieść bazę z systemu windows (pod warunkiem, że nie jest skompresowana - rozszerzenie .bak).
Jeśli ktoś chce skorzystać ma tu gotowe, działające, sprawdzone , DARMOWE rozwiązanie. I tyle w tym temacie
-
Witam, od dłuższego czasu szukałem działającego rozwiązania do MSSQL pod Linuxem. Powód jest oczywisty - wydajność.
Ale nie to jest przedmiotem mojego postu - nie będę się dalej wdawać w dyskusje nie na temat.
Sam zaznaczyłeś, że powodem zmian była wydajność, a teraz nie chcesz o tym dyskutować ? :o Poza tym nikt nie chce dyskutować tylko zobaczyć jakikolwiek potwierdzenie tej tezy, gdyż na razie to wygląda dokładnie tak samo jak byś napisał, że przemalowałeś samochód na kolor czerwony z palety Ferrari (kosztowało to czas i pieniądze) i teraz jest szybszy...
Ostatnio optymalizowałem bazę danych u jednego z moich klientów (stary serwer z Windows), czas wykonania zgłaszanej operacji spadł z kilku do kilkunastu sekund do sekundy, specjalnie nie powiedziałem kiedy wprowadziłem zmiany, po wprowadzeniu wycofałem je na kilka dni, później znowu wprowadziłem, po kolejnych kilku dniach spytałem czy zostały zauważone zmiany, a jeśli tak to kiedy - otrzymałem odpowiedź, że nikt nic nie zauważył - takie są subiektywne opinie użytkowników - ja mierzyłem czasy wykonania zapytań...
Natomiast chciałbym skupić się w tym momencie na jednym aspekcie - jaki jest czas konwersji tych 120 baz danych (na takim samym sprzęcie), kiedy bazy danych są umieszczone na na serwerze z linuxem i kiedy znajdują się na serwerze Windows (i naturalnie program jest uruchomiony na serwerze) ?
-
Myślałem, że wątek jest o zwiększeniu wydajności serwera poprzez zmianę wersji systemu... :-)
I naprawdę jestem ciekaw.
Jestem w stanie przyjąć na wiarę, że na tym samym sprzęcie Linux+SQL2017 będzie działał szybciej niż np. Win7+SQL2016. Ale już wcale nie jest takie oczywiste jak się to będzie mieć np. kombinacji Core/Nano+SQL2008R2.
-
Ale co z tego, że będzie wydajniej, jeśli będzie wydajniej o powiedzmy 1% ? Nikt tego w praktyce nie zauważy... Jeśli nie padają żadne, konkretne wartości to nic to do tematu nie wnosi.
-
Jest okazja... właśnie się przymierzam do aktualizacji... Opiszę wyniki.
-
Odpowiednikiem jakiej windowsowej wersji jest linuksowy SQL2017?
Baza Subiekta przeniesiona na Linuksa ze starego sql'a (np. 2008R2, 2012) zostanie przekonwertowana do wersji 2017. Załóżmy, że potem coś się kompletnie posypie i trzeba będzie szybko wrócić do Windows. Downgrade bazy nie jest normalnie "od ręki" możliwy, więc trzeba będzie użyć nowszego sqla. Którego?
-
Pytanie retoryczne ? Takie samego.
-
Pytanie retoryczne ? Takie samego.
Ha! Jakoś wydawało mi się, że nie ma wersji 2017 dla Windows... :-)
-
Pytanie retoryczne ? Takie samego.
Ha! Jakoś wydawało mi się, że nie ma wersji 2017 dla Windows... :-)
Jest już nawet 2019 :)
-
Jest już nawet 2019 :)
Widać nie jestem na bierząco. :-)
A czy nadal „najbardziej właściwą” do użytku jest 2008R2 ze względu na ograniczenia wydajnościowe?
-
Jest już nawet 2019 :)
Widać nie jestem na bierząco. :-)
A czy nadal „najbardziej właściwą” do użytku jest 2008R2 ze względu na ograniczenia wydajnościowe?
Mowa o edycji Express czy Standard ;)? Express od dawien dawna ma miliard ograniczeń wydajnościowych. Bodaj od 2012 zaczęli wprowadzać na Standarda ograniczenia w ilości RAMu i gniazd/rdzeni, które SQL może wykorzystać (16 rdzeni 64GB RAM zdaje się). Potem to podnieśli do 4 gniazd/24 rdzeni i 128GB RAM.
PS. W 2019 jest jedna rzecz, która bardzo mnie ciekawi:
https://www.brentozar.com/archive/2018/11/sql-server-2019-faster-functions/
Będę na dniach ćwiczył sobie na testowej wersji czy to działa tak ładnie jak to opisują.
-
Mowa o edycji Express czy Standard ;)? Express od dawien dawna ma miliard ograniczeń wydajnościowych.
No Express... Daje się, że w 2008R2 było tych ograniczeń mniej niż później. :-)
-
Mowa o edycji Express czy Standard ;)? Express od dawien dawna ma miliard ograniczeń wydajnościowych.
No Express... Daje się, że w 2008R2 było tych ograniczeń mniej niż później. :-)
Raczej odwrotnie było wcześniejsze Expressy miały ograniczenie rozmiaru bazy do 4GB, chyba od 2008R2 jest 10GB. Do 2008R2 jeśli dobrze kojarzę ograniczenie na proca było do jednego CPU z dowolną ilością rdzeni (nie jestem pewien tego) a od 2012 max 1 CPU lub 4 rdzenie.
-
@yemet, to podstawy podstaw, nie zgaduj, zajrzyj to tabelek...
-
@dkozlowski - zajrzałem ale tak na szybko, na pierwsze lepsze w necie.
-
@dkozlowski - zajrzałem ale tak na szybko, na pierwsze lepsze w necie.
Dobrze, źle przeczytałem odpowiedź, mój błąd.
-
No Express... Daje się, że w 2008R2 było tych ograniczeń mniej niż później. :-)
Raczej odwrotnie było wcześniejsze Expressy miały ograniczenie rozmiaru bazy do 4GB, chyba od 2008R2 jest 10GB. Do 2008R2 jeśli dobrze kojarzę ograniczenie na proca było do jednego CPU z dowolną ilością rdzeni (nie jestem pewien tego) a od 2012 max 1 CPU lub 4 rdzenie.
No właśnie. A jako że mam ośmiordzeniowy proc, to stoję przy 2008R2...
-
Z ciekawości uruchomiłem sobie testowy kontener lxd z Ubuntu Server 16.04 i mssql. Może komuś się przyda:
wget -qO- https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
sudo add-apt-repository "$(wget -qO- https://packages.microsoft.com/config/ubuntu/16.04/mssql-server-2017.list)"
sudo apt update
sudo apt install mssql-server
sudo /opt/mssql/bin/mssql-conf setup
sudo systemctl stop mssql-server
sudo /opt/mssql/bin/mssql-conf set-collation
#Podać: Polish_CI_AS
sudo systemctl start mssql-server
I to tyle. Działa z wyjątkiem archiwizacji.
A jak ktoś dodatkowo chce działającą archiwizację:
sudo apt install samba
sudo mkdir /srv/tmp
sudo chown msssql:mssql /srv/tmp
sudo ln -s /srv/tmp /var/opt/mssql/.system/profiles/(nazwa-windowsowego-usera)/tmp
Udostępnić folder /srv/tmp przez Sambę, np. tak:
[tmp]
comment = SQL Tmp Folder
path = /srv/tmp
read only = no
browsable = yes
guest only = yes
public = yes
writeable = yes
force user = mssql
force group = mssql
create mask = 0660
directory mask = 0770
Oczywiście w miarę potrzeb dopasować i zrestartować usługę smb.
Po stronie Windowsa dodać link do folderu roboczego (jako administrator):
mklink /d C:\Users\(nazwa-windowsowego-usera)\tmp \\(adres-linksowego-serwera)\tmp
Wskazać archiwizatorowi folder roboczy C:\Users\(nazwa-windowsowego-usera)\tmp i cieszyć się. :-)
Nie wykluczam, że coś w powyższym pomieszałem, bo to głównie z pamięci jest...
(Eksperymenty fajne, ale i tak zostaję przy serwerze produkcyjnym na Windows...)
-
Acha, konwersja bazy przy aktualizacji Subiekta zdaje się działać bardzo ładnie...
-
offtop: konwersje Subiekta to pikuś, powinieneś zobaczyć ile trwa aktualizacja Navireo jak narobisz sobie własnych kompozycji :)
-
Po długim czasie jako ten który zaczął wątek opisuję wyniki wydajności. Biuro - 135 podmiotów, łącznie bazy zajmują 35 GB. Przebolałem i sprawdziłem wydajność na tym samym komputerze, na tym samym MS SQL Express 2017. Wyniki są następujące:
Windows - aktualizacja zaczęła się w piątek o godz. 18, skończyła się w sobotę o godz. 20
Linux - aktualizacja zaczęła się w piątek o godz. 18 skończyła się w sobotę o 8 rano
Sytuacja jest dokładnie taka sama - wykonałem obraz systemu i na nim "trenowałem" wydajność, stąd ta sama ilość danych.
Nie mniej ważną cechą jest to, że jak w Linuxie ustawie wszystkie parametry to będzie działać, dopóki sam czegoś nie skopię lub skończy się dysk twardy.
W windowsie po paru aktualizacjach przestała działać automatyczna kopia bezpieczeństwa, zostały zablokowane programy sieciowe, został zablokowany serwer Firebird.
Trzeba było paru godzin na odnalezienie i rozwiązanie problemu i dużo odpowiedzi na pytanie, dlaczego nie działa, skoro nikt nic nie ruszał.
Stąd nawet jeśliby nie było wzrostu wydajności to przy linuxie jak postawię serwer i wszystko ustawie to mam spokój święty i anielski.
PS. Archiwizator działa pod Windows i nagrywa kopie na systemie Windows, a nie na Linuxie
-
Jak już wspominałem - żeby porównanie prędkości było sensowne warto by użyć Windows Core Server jako systemu. W dodatku raczej nie będzie problemów z „zapominaniem” konfiguracji... Trudno jest zepsuć Core...
-
Takie moje mniemania:
Taki serwer na Linuksie może w pewnych przypadkach działać szybciej.
Otóż Microsoft w desktopowej Windzie, bodaj od XP SP2 wprowadził sztuczne ograniczenie równoczesnych połączeń TCP do 20, 10 czy nawet 5 (zależnie od wersji Windy i czy Home czy Pro). Jeśli MS SQL nie był postawiony na Windows Server (a często w małych firmach nie jest), tylko na desktopowej Windzie, to może być zauważalne spowolnienie wynikające z tego limitu już przy kilku użytkownikach (przecież połączenia z bazą nie są jedyne). Linux takich sztucznych ograniczeń nie wprowadza. Jeśli ktoś ma ten serwer postawiony na Windzie serwerowej, to pewnie zysku z Linuksa nie zauważy. Do tego są jakieś mikroskopijne zyski ze schedulera procesora (desktopowa Winda preferuje częste przerywanie pracy wątków procka celem np. odpytywania myszki, klawiatury itp. w celu większej responsywności kompa na działanie użytkownika, w Linuksie można to ustawiać i w roli serwerowej przerwy takie są rzadsze i wątki pracują dłużej i są rzadziej przełączane).
Drugą denerwującą rzeczą, było wprowadzenie rok temu w Windows 10 włączania z opóźnieniem usługi MS SQL (tylko tej darmowej), przez co "szybki" użytkownik dostawał komunikat, że nie można się połączyć z bazą danych, a jeszcze bardziej i to naprawdę denerwujące było, to wprowadzenie (też w "trosce o użytkownika") automatycznego wyłączania w desktopowej wersji Windy usługi MS SQL przy dłuższym stanie bezczynności (też tylko w tej darmowej wersji, płatna tak się nie zachowuje, bo można to ustawić). To już naprawdę wk.... było, bo wymagało przerobienia aplikacji, by przy braku połączenia z bazą, próbowały zdalnie uruchomić usługę MS SQL i to działa, ale ze sporym opóźnieniem wynikającym z ponownego startu usługi MS SQL. Niestety starsze aplikacje, które tego nie robią, w takim przypadku się nie połączą, bo użytkownik musi ręcznie uruchomić zatrzymaną usługę MS SQL (ilu zwykłych użytkowników to potrafi?). Mniemam (nie bawiłem się z MS SQL na Linuksie, ale w przyszłym miesiącu zacznę), że na Linuksie takiego wyłączania MS SQL przy bezczynności nie ma, a jak jest, to pewnie, jak to na Linuksie, da się to obejść/wyłączyć.
Trzecią sprawą jest sposób pracy darmowej wersji MS SQL Expressa, która "w trosce o użytkownika" często zrzuca bazę z RAM w celu uwolnienia pamięci i nie da się tego, jak na pełnej wersji wyłączyć (na desktopie ma to sens, gdy jest równocześnie używany do innych zadań, ale MS pewnie bardziej kierował się przy tym "zachętą" dla firm do zakupu płatnej wersji). Nie wiem czy na Linuksie też się tak zachowuje, być może nie.
Podsumowując: moim zdaniem zauważalny zysk będzie jak ktoś MS SQL postawi na Linuksie, zamiast desktopowej wersji Windy, natomiast w porównaniu z wersją serwerową Windy, to "potrzebne będą specjalistyczne pomiary" by zauważyć różnicę.
-
Problem Archiwizatora Inserta wydaje się byc nie do przejścia w przypadku biur rachunkowych i wielu baz. Otóż podpięcie bazy za pomocą Studio Managera, lub innego nieinsertowskiego narzędzia owocuje nie działającym Crystal Reports, a jedynym sposobem w tym momencie jest archiwizacja bazy i dearchiwizacja jej spowrotem archiwizatorem insertowskim, lub Biuro GT. Te zaś nie działają gdy baza siedzi na Linux.
Czy może ma ktoś was pomysł jak:
1. Rozwiązać problem Crystal Reports inaczej niż poprzez arch/dearch by INSERT
2. Obejść problem inaczej. Może tak żeby standardowy archiwizator przyjął linuxowe ścieżki i zadziałał.
3. Czy ktoś zna odpowiedź, co takiego robi derarchiwizator na koniec pracy, że Crystal Report zaczyna poprawnie działać ? Może można zrobić to "ręcznie" ?
Szkoda, że INSERT nie chce zmodernizować swojego archiwizatora, tak żeby brał pod uwagę wariant taki, że baza stoi na Linux.
Nie testowałem jeszcze wyniku dearchiwiacji za pomocą wystawionego tu programu. Zrobię to w tym tygodniu.
Do autora cyt. posta: Czy masz może podobną wersję archiwizatora/dearchiwizatora dla baz osadzonych na Windows ?
Ta masowa archiwizacja wszystkich baz (a mam ich 250) jest bezcenna.
Pozdrawiam.
Witam, od dłuższego czasu szukałem działającego rozwiązania do MSSQL pod Linuxem. Powód jest oczywisty - wydajność. W Windows system generuje setki procesów, szuka wiatru na dysku etc. etc. Poświęciłem na to trochę czasu, ale się opłaciło. Sprawdzone zostało wszystko poza Biuro GT, ale myślę, że też będzie działać.
Opis instalacji dotyczy dystrybucji CENTOS 7, ale myślę, że na innych będzie też działać.
[INSTALACJA CENTOS 7]
1. Przy instalacji trzeba ustawić: IP komputera na stałe;
2. Nazwa komputera [host w ustawieniach sieci] nie może mieć kropki, ani polskich znaków. Domyślnie instalator przyjmuje nazwę localhost.localdomain. W mojej instalacji zmieniłem to na MSSQLSRV;
3. Przy tworzeniu pierwszego użytkownika należy zaznaczyć opcję 'ADMINISTRATOR';
Po zainstalowaniu systemu i zaakceptowaniu umowy licencyjnej logujemy się i jako root instalujemy repozytoria epel release.
Następnie można wykonać skrypt:
# /bin/bash
yum install system-config-users
yum install -y -q p7zip p7zip-plugins
curl https://packages.microsoft.com/config/rhel/7/mssql-server-2017.repo -o /etc/yum.repos.d/mssql-server-2017.repo
curl https://packages.microsoft.com/config/rhel/7/prod.repo -o /etc/yum.repos.d/msprod.repo
yum -y install mssql-server mssql-tools unixODBC-devel
echo 'export PATH=$PATH:/opt/mssql-tools/bin' > /etc/profile.d/mssql.sh
source /etc/profile.d/mssql.sh
/opt/mssql/bin/mssql-conf setup
mkdir /data
mkdir /mssqldb
mkdir /mssqldb/backup
mkdir /mssqldb/data
chown mssql:mssql /mssqldb -R
chmod 777 /data
/opt/mssql/bin/mssql-conf set filelocation.defaultbackupdir /mssqldb/backup
/opt/mssql/bin/mssql-conf set filelocation.defaultdatadir /mssqldb/data
systemctl stop mssql-server
echo 'Wpisz Polish_CI_AS'
/opt/mssql/bin/mssql-conf set-collation
firewall-cmd --add-port=1433/tcp --permanent
firewall-cmd --permanent --zone=public --add-services=samba
firewall-cmd --permanent --zone=public --add-service=samba
firewall-cmd --reload
systemctl enable smb.service
systemctl enable nmb.service
service smb start
service nmb start
service mssql-server start
useradd mssqldb -G mssql, wheel -m -p mssqldb
echo 'mssqldb ALL=(ALL) ALL' >>/etc/sudoers
Trzeba koniecznie wykonać operację
echo 'Wpisz Polish_CI_AS'
/opt/mssql/bin/mssql-conf set-collation przed podłączeniem jakiejkolwiek bazy - inaczej ani Rachmistrz, ani Rewizor nie zaktualizują się.
Ponadto w instalacji ('gotowiec') plik /opt/mssql/mssql.conf ma wyglądać tak:
[sqlagent]
enabled = false
[EULA]
accepteula = Y
[language]
lcid = 1033
[filelocation]
defaultbackupdir = /mssqldb/backup/
defaultdatadir = /mssqldb/data/
defaultdumpdir = /mssqldb/data/
defaultlogdir = /mssqldb/data/
Ustawienie katalogu tymczasowego dla potrzeb aktualizacji:
Trzeba w katalogu na kliencie utworzyć katalog TEMP:
c:\users\[nazwa_uzytkownika_w_windows]\TEMP
Standardowy archiwizator nie będzie działać, dlatego napisałem swój i jest dostępny pod adresem:
https://drive.google.com/file/d/1CWWwUIFQIrnWoP4uNu8Tk821rP0oew25/view?usp=sharing
Umożliwia on archiwizację "ręczną" jak i automatyczną. Jest napisany do współpracy z Linuxem.
Wymaga użytkownika linuxa, który przez 'sudo' może zmienić atrybuty plików w systemie linux.
W załącznikach instalka mssql servera i plik konfiguracyjny mssql. Oczywiście po zapisaniu na linuxie muszą one mieć atrybuty 777.
Nie gwarantuję, że będzie działać na Waszej instalacji, nie sposób wszystko przewidzieć, ale u mnie na 'świeżo' postawionym systemie zadziałało.
-
Co wy się wszyscy czepiacie tego Archiwizatora... U mnie działa. Post 20 w tym wątku.
-
Czy Cristal Reports działa na podmiotach dearchiwizowanych twoim archiwizatorem ? Podłączenie baz za pomocą Studio Managment owocuje nie działającym Cristalem. A wg INSERT jedyną drogą na usunięcie problemu jest zarchiwizowanie i zdearchiwizowanie bazy ich narzędziem. Podobny kłopot jest przy BiuroGT - nie działa masowa dearchiwizacja, czyli problem przy migracji wielu baz (biura rachunkowe) z WIN na Linux. To można obejść podłączając masowo bazy do SQL za pomocą skryptu lub programu SQL_Server_attach_multiple_databases, albo twojego dearchiwizatora, ale Cristal wtedy nie działa.
Czy może macie pomysł jak to obejść?
-
Nie słuchaj bzdur "Insertu" (jakiegoś niedouczonego konsultanta) tylko poczytaj forum, gdzie rozwiązanie było podawane wiele razy... Lub na logikę - sprawdź co robi program i zrób to samo...
-
Świetnie. Z kilkomami aktualizacjami na Centos 7 udało mi się uruchomić bez problemu bazę i śmiga bardzo dobrze po OpenVPN.
Jednak mam jeszcze pytanie. Mam wykupiony VPS z Centos 7 i chciałbym odpalić kilka instancji dla kilku różnych klientów. W jaki sposób to najlepiej rozwiązać ?