Backend Datenbank auf Server regelmäßig komprimieren

Moderator: ModerationP

Re: Backend Datenbank auf Server regelmäßig komprimieren

Beitragvon Bitsqueezer » 11. Sep 2018, 11:55

Hallo,

und neben all den Gründen, die Nouba schon aufgezeigt hat, auch Dinge wie, daß ein einzelner Benutzer durch ungeschicktes Beenden von laufenden Operationen das ganze Backend so kaputtkriegen kann, daß auch sonst niemand mehr damit arbeiten kann. Dann braucht es einen Restore eines hoffentlich gemachten Backups. Solche Dinge sind mit einem DB-Server quasi unmöglich, da selbst bei einem Stromausfall sichergestellt ist, daß sich die DB selbst repariert. Und viele solcher Gründe mehr.

Gruß

Christian
Bitsqueezer
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 6585
Registriert: 21. Jun 2007, 12:17

Re: Backend Datenbank auf Server regelmäßig komprimieren

Beitragvon knobbi38 » 11. Sep 2018, 13:01

Hallo Christian,

normalerweise verabschiedet man sich ganz schnell von Access-Backends bei Mehrbenutzerumgebungen, insbesondere im Unternehmensbereich, weil es absolut keinen Grund mehr dafür gibt, solche Konstrukte zu verwenden.

da wird von einer idealen Welt ausgegangen. Es gibt immer noch durchaus Gründe, eine DB auf Filesharing aufzusetzen und keinen SQL-Server zu verwenden. Man kann den Anwender/Kunden über die Vor- bzw. Nachteile beraten, aber letztendlich entscheidet der Kunde, welcher Technologie er den Vorzug gibt, wobei dabei auch Überlegungen mit einfließen können, die keine technische Grundlage haben.

Access Anwendungen im Mehrbenutzerbetrieb mit einem Backend auf einem Netzwerkshare sind durchaus häufiger anzutreffen, als man eigentlich vermuten könnte. Diese Umstände erfordern dann vielleicht etwas mehr Aufmerksamkeit duch den Programmierer und sind ggf. auch eine Herausforderung.

Gruß Ulrich
knobbi38
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 406
Registriert: 02. Jul 2015, 14:23

Re: Backend Datenbank auf Server regelmäßig komprimieren

Beitragvon Bitsqueezer » 12. Sep 2018, 11:41

Hallo Ulrich,

ich bezweifle nicht, daß es unlogische Gründe wie "das ist aber mein Lieblingstool und ich will das einfach so" und ähnliche irrationale "Gründe" gibt. Wenn ich von "Gründen" rede, dann meine ich logisch nachvollziehbare Gründe, Gründe, bei denen am Ende rauskommt "ja, stimmt, das geht in diesem Fall tatsächlich absolut nicht anders". Vor 20 Jahren gab es Gründe wie extrem hohe Kosten für ein Serverbackend oder ganz einfach keine oder schlechte Netzwerkumgebung (ja, es war durchaus mal üblich, daß User Einzelrechner hatten oder nur per Laplink mit dem PC gegenüber verbunden waren - in solchen Szenarios war sowas "üblich"). Diese Gründe gibt es nicht mehr. "Gründe" wie "mit einem DB-Server-Backend kann ich nicht umgehen und auch sonst keiner hier" sind ebenso scheinheilig, weil Tools wie SSMS es genauso leicht, eher noch leichter machen, mit der DB umzugehen. Das kann jeder, der Access bereits kennt, in ein paar Stunden lernen (alle notwendigen Grundzüge).

Also "Rabääh, wein und heul"-Gründe sind für mich keine Gründe, wenn sich ein Kunde dafür entscheidet, es so zu belassen, ist er halt beratungsresistent und zahlt einen Haufen mehr Geld für Datenverlust, nicht verfügbare DB, blockierte User, langsame Performance und umständliche Programmierung, um das alles irgendwie auszugleichen - uvm. Das ist sein Problem.

Mir ist durchaus bewußt, daß es solche Entscheidungen auch nicht selten gibt, aber eben unter der genannten Kategorie einzuordnen. "Herausforderung" mag es für den Programmierer sein, den Schaden hat der Geldgeber und gerade bei kleinen Unternehmen ggf. auch das ganze Unternehmen.

Daher bleibe ich bei dem Statement: Es gibt keinen einzigen WIRKLICHEN Grund, der FÜR ein Access-Backend spricht.

Gruß

Christian
Bitsqueezer
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 6585
Registriert: 21. Jun 2007, 12:17

Re: Backend Datenbank auf Server regelmäßig komprimieren

Beitragvon Kerstin83 » 12. Sep 2018, 22:59

Es gibt aber einen wirklichen und nachvollziehbaren Grund: Mann kennt nichts anderes. Und in dieser Situation bin ich - leider :(
Ich hasse Leute, die Sätze nicht zuende
Kerstin83
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 1007
Registriert: 03. Aug 2005, 13:29
Wohnort: Zur Zeit im schönen Berlin

Re: Backend Datenbank auf Server regelmäßig komprimieren

Beitragvon Bitsqueezer » 13. Sep 2018, 14:12

Hallo Kerstin,

das ist schon mal gar kein Grund. Du machst doch auch nicht Feuer mit zwei Steinen, obwohl Du genau weißt, daß es Feuerzeuge gibt, nur weil Du sie noch nie verwendet hast. DASS es Feuerzeuge (also DB-Server) gibt, weißt Du ganz sicher. Es ist also an Dir, Dich darüber zu informieren - bevor Du Dir die Finger zwischen zwei Steinen klemmst.

Mal abgesehen davon, daß es dann auch das Problem Deines Auftraggebers ist, der eine solche Lösung im Unternehmensumfeld überhaupt zuläßt.

Gruß

Christian
Bitsqueezer
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 6585
Registriert: 21. Jun 2007, 12:17

Re: Backend Datenbank auf Server regelmäßig komprimieren

Beitragvon mmarkus » 14. Sep 2018, 11:06

Mich würde mal der Unterschied zwischen Access Backend und Server bezüglich Transaktion interessieren.

Wenn die Netzwerkverbindung zu einem Access File während einer Transaktion unterbrochen wird - was passiert dann genau?
So viel ich weiß, bleiben ja die Sperren auf die betroffenen Bereiche in der Access Datei aufrecht.
Um die zu lösen müssten alle Clients die Verbindung trennen und die Datei geschlossen werden - oder was ist die Folge?

Beim Server - müsste der ja von sich aus feststellen, dass der Client weg ist (Timeout oder Netzwerkprotokoll?) und die Transaktion verwerfen.
Ich weiß, der Fall ist sehr unwahrscheinlich - aber technisch möglich.

Damit wäre Access selbst bei Transaktionen noch problematisch.
ms access what else
mmarkus
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 1050
Registriert: 16. Apr 2012, 16:07
Wohnort: Vienna

Re: Backend Datenbank auf Server regelmäßig komprimieren

Beitragvon knobbi38 » 14. Sep 2018, 13:25

Hallo Markus,

kannst man einfach selber mit einer VM simulieren, indem man dort auf eine freigegebene Backend Datei zugreift und währenddessen die Netzerkverbindung kappt.
Nach meinen Erfahrungen reagiert Access sehr "sauer", wenn es Netzwerunterbrechungen zu einer geöffneten DB gibt. Timeouts hin oder her, der Frontend muß dabei meistens neu gestartet werden. Wenn man geschickt programmiert, kann man die dabei auftretenden Fehler zwar minimieren, aber prinzipiell ist die Gefahr für eine Datenkorruption immer gegeben.

Gruß Ulrich
knobbi38
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 406
Registriert: 02. Jul 2015, 14:23

Re: Backend Datenbank auf Server regelmäßig komprimieren

Beitragvon Kerstin83 » 16. Sep 2018, 06:02

ich habe mal geschaut. Meint ihr einen solchen Microsoft SQL-Server:
https://www.microsoft.com/de-de/sql-ser ... 17-pricing

Ist ja preislich nicht ganz ohne. Oder reicht die Expressversion ? Für mehrere Anwender ?
Ich hasse Leute, die Sätze nicht zuende
Kerstin83
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 1007
Registriert: 03. Aug 2005, 13:29
Wohnort: Zur Zeit im schönen Berlin

Re: Backend Datenbank auf Server regelmäßig komprimieren

Beitragvon Nouba » 16. Sep 2018, 08:57

@Kerstin,

ja, die Express-Version dürfte genügen und sich vermutlich am harmonischsten mit Access als FE nutzen lassen. Bitsqueezer kann dazu bestimmt aus dem Nähkästchen plaudern.

Aber auch andere große Datenbank-Hersteller bieten ihre kommerziellen Datenbank-Produkte in freien, i.d.R. um Features gekürzten Versionen an. Ich nenne hier einmal IBM-DB2 Express-C, Oracle Database Express Edition (XE),

Dann gibt es noch einige leistungsstarke Open Source SQL-Server, die keine Einschränkungen im Funktionsumfang haben, deren Lizenzbestimmungen aber einzuhalten sind. Genannt seien hier MySQL, MariaDB, FireBird, PostgreSQL und TimeScale.

Persönlich habe ich mit PostgreSQL als BE sehr gute Erfahrungen gemacht. Mit TimeScale, das auf PostgreSQL aufsetzt, experimentiere ich noch.
Zuletzt geändert von Nouba am 16. Sep 2018, 12:36, insgesamt 1-mal geändert.
mit freundlichen Grüssen Nouba

Wenn beim Lesen eines Beitrags der Eindruck entsteht, dass sich der Fragesteller wenig Mühe gegeben hat, so erhöht das nicht unbedingt die Motivation, eine Antwort zu verfassen.
Nouba
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 17187
Registriert: 13. Mär 2006, 12:55
Wohnort: Berlin

Re: Backend Datenbank auf Server regelmäßig komprimieren

Beitragvon Bitsqueezer » 16. Sep 2018, 12:18

Hallo,

da ein Access-Backend keine aktive Datenbank darstellt, kann es auch keine Transaktionen sichern. Ein DB-Server macht das (stark vereinfacht) so, daß er eine anstehende Transaktionsaufgabe VOR der Ausführung der Aufgabe in einem Log speichert und erst dann die Aufgabe ausführt. Passiert etwas beim Logschreiben, ist noch nichts passiert mit der DB, also kann man den letzten Transaktionslog einfach löschen. Passiert etwas während der eigentlichen Transaktion, zeigt das Logbuch, wie man es wieder rückgängig machen kann, was der DB-Server dann selbsttätig durchführt.

Da bei einem Access-Backend nur das Frontend aktiv mit der Datenbank arbeitet, kann nur das Frontend entscheiden, was zu tun ist, bzw. DAO/ADO. Wenn das FE aber durch den Stromausfall ebenfalls abstürzt, gibt es nichts, was irgendwie retten könnte, was schiefgegangen ist.

Zu SQL Server: Ja, die Express-Version reicht für alle Datenbanken, die bisher mit einem Access-Backend ausgekommen sind, völlig aus, da sie mind. die doppelten Grenzwerte eines Access-Backends enthält (z.B. für die maximale DB-Größe). Nebenbei ist auch schon ein (extra herunterladbare und installierbare, aber ebenso kostenloser) Reporting-Service dabei, der die Fähigkeiten von Access-Reports bei weitem übersteigt und auch unabhängig von einem Access-Frontend Reporte zur Verfügung stellen kann.

Darüber hinaus hat Nouba ja schon aufgezählt, was es sonst noch so an DB-Servern gibt, die ebenfalls frei erhältlich sind. Im Fall der "Großen" wie SQL Server, DB2, Oracle usw. hat man dabei noch den Vorteil, daß man die DB später auf jede weitere Größe/Lizenz skalieren kann, die DB kann also "mitwachsen", wenn man die Gelder am Anfang noch nicht hat oder noch nicht ausgeben will.

Datenbanken wie MySQL sind schon von Haus aus "ausgewachsen" und schon so lange auf dem Markt, daß man sie ebenfalls als stabil und sicher betrachten kann.

Ich persönlich bevorzuge weiterhin SQL Server, weil nach meiner Meinung bei weitem am komfortabelsten und mit sehr vielen Extras ausgestattet, die die meisten Datenbanken von Haus aus nicht liefern, wie den o.g. Reporting Services, oder Analysis Service, Integration Service, Notification Service uvm., ganz zu schweigen von der komfortablen Entwicklungsumgebung, die man bei der Konkurrenz komplett vermißt.

Gruß

Christian
Bitsqueezer
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 6585
Registriert: 21. Jun 2007, 12:17

Re: Backend Datenbank auf Server regelmäßig komprimieren

Beitragvon mmarkus » 16. Sep 2018, 14:50

Bitsqueezer hat geschrieben:Ein DB-Server macht das (stark vereinfacht) so, daß er eine anstehende Transaktionsaufgabe VOR der Ausführung der Aufgabe in einem Log speichert und erst dann die Aufgabe ausführt. Passiert etwas beim Logschreiben, ist noch nichts passiert mit der DB, also kann man den letzten Transaktionslog einfach löschen.


@Christian
Danke für deine Ausführungen.
Also nach jedem Execute werden die notwendigen Aktionen in den Log geschrieben und nach dem Commit dann tatsächlich ausgeführt.
Wenn nun die Verbindung unterbrochen wird, kommt es zu keinen Commit und die Transaktion bleibt offen.

Was bedeutet das für die Praxis - wenn eine Transaktion nicht abgeschlossen wird?

Angenommen es geht um ein Update/Delete. Können dann andere User normal mit den betroffenen Daten arbeiten, oder ist der Zugriff erstmal gesperrt?

Erkennt der Server den Verlust der Verbindung sofort, oder wartet der eine Ewigkeit oder bis zu einem Timeout auf einen Abschluss.

Kann die Transaktion automatisch oder durch irgendwelche Jobs gelöscht werden, oder ist ein händischer Eingriff erforderlich?

Danke Markus
ms access what else
mmarkus
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 1050
Registriert: 16. Apr 2012, 16:07
Wohnort: Vienna

Re: Backend Datenbank auf Server regelmäßig komprimieren

Beitragvon Nouba » 16. Sep 2018, 15:35

In PostgreSQL kann man Timeouts individuell für Transaktionen festlegen (dürfte auf anderen Servern ähnlich sein). Bei Erreichen eines Timeouts muss dann reconnected werden.

Hier eine psql-Session:
Code: Alles auswählen
➜  ~ psql
psql (10.5)
Type "help" for help.

bousn=# alter system set idle_in_transaction_session_timeout to '5s';
ALTER SYSTEM
bousn=# select pg_reload_conf();
pg_reload_conf
----------------
 t
(1 row)

bousn=# begin; -- Transaction starten und 5 Sekunden lang warten
BEGIN
-- zwischenzeitlich status ermitteln
bousn=# SELECT pid, now() - state_change AS inactive_since FROM pg_stat_activity WHERE state = 'idle in transaction';
 pid | inactive_since
-----+----------------
(0 rows)

bousn=# select 4711;
FATAL:  terminating connection due to idle-in-transaction timeout
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.
bousn=#
Zuletzt geändert von Nouba am 17. Sep 2018, 07:29, insgesamt 1-mal geändert.
mit freundlichen Grüssen Nouba

Wenn beim Lesen eines Beitrags der Eindruck entsteht, dass sich der Fragesteller wenig Mühe gegeben hat, so erhöht das nicht unbedingt die Motivation, eine Antwort zu verfassen.
Nouba
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 17187
Registriert: 13. Mär 2006, 12:55
Wohnort: Berlin

Re: Backend Datenbank auf Server regelmäßig komprimieren

Beitragvon mmarkus » 17. Sep 2018, 07:11

@Nouba, danke das klärt meine Fragen.
ms access what else
mmarkus
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 1050
Registriert: 16. Apr 2012, 16:07
Wohnort: Vienna

Re: Backend Datenbank auf Server regelmäßig komprimieren

Beitragvon Bitsqueezer » 17. Sep 2018, 08:44

Hallo Markus,

üblicherweise startet man eine Transaktion nicht vom Frontend aus, sondern das Frontend startet eine Stored Procedure im Backend und die Transaktion wird hier gestartet und beendet. Somit ist man komplett von Abstürzen eines Frontends unabhängig. Hier muß dann also schon beim Server ein Problem auftreten, und wenn kein Commit stattfindet, bleibt hier die Transaktion nicht offen, denn wenn der Server abstürzt und neu bootet, werden alle nicht beendeten Transaktionen aus dem Log gelöscht und damit ist nichts auf der DB passiert, es gibt auch keine inkonsistenten Zustände.

Hat man eine Transaktion vom FE aus gestartet und nicht beendet, wird normalerweise automatisch ein Rollback durchgeführt, sobald die Verbindung geschlossen wird (Vorsicht: Bei Connection Pooling geht es dann um alle Verbindungen des aktuellen Frontends).

Problematisch ist hier vor allem, daß eine offene Transaktion bedeutet, daß weitere Transaktionen des gleichen Frontends unter der gleichen Verbindung als "Nested Transactions" zählen und damit zusätzliche Ressourcen blocken. Ein nicht namentlich bezeichneter Rollback/Commit wirkt sich dann auch auf die übergeordnete Transaktion aus. Ein weiterer Grund, warum man besser eine Stored Procedure einsetzen sollte, da man vor dem Ausgang die Anzahl offener Transaktionen testen und beenden kann.

Tatsächlich gibt es Tutorials, die Transaktionen für Benutzereingaben empfehlen, um ein Undo über mehrere Datensätze verwenden zu können. Sowas ist natürlich absoluter Unsinn, da eine Transaktion so schnell wie möglich beendet werden sollte und nicht auf laaangsame Benutzer (oder solche, die zwischendrin in Urlaub gehen...) warten soll.

Ich glaube, einen Timeout gibt es hier nicht, SQL Server wartet auf das Ende einer Transaktion unendlich, solange die Verbindung besteht. Das weiß ich aber nicht, ich verwende grundsätzlich keine FE-Transaktionen.

Gruß

Christian
Bitsqueezer
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 6585
Registriert: 21. Jun 2007, 12:17

Re: Backend Datenbank auf Server regelmäßig komprimieren

Beitragvon mmarkus » 17. Sep 2018, 09:12

@Christian,
ich nutzte Transaktionen, wenn eine Änderung in einem Formular weitere Änderungen nach sich zieht.

Natürlich könnte man das alles im Backend erledigen.

Ich sehe da aber nicht das große Problem wenn das einige wenige Anweisungen sind, die logischerweise ohne jegliche User Interaktion auskommen,
bzw. man sammelt notwendige Infos vor dem Beginn der Transaktion.
Bei längern andauernden Prozessen sollte das natürlich ausschließlich im Backend geschehen.

So viel ich zwischenzeitlich gesehen habe, nutzt auch der MSSQL Server das festgelegte Timeout der ADO Connection, wenn die Transaction vom Client aus gestartet wird.

Danke jedenfalls für die Infos.
ms access what else
mmarkus
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 1050
Registriert: 16. Apr 2012, 16:07
Wohnort: Vienna

Vorherige

Zurück zu Access Forum (provisorisch)

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 3 Gäste