PDA

Vollständige Version anzeigen : Wie lange funktioniert Access ????


Sys-Admin
07.02.2001, 14:51
Ich sag erst mal hallo an alle die meinen Beitrag lesen.

Folgende Frage :

Ich bin seit kurzer Zeit Systemadministrator in einem mittelständischen Unternehmen mit 30 PC-Arbeitsplätzen. Wir setzen eine Datenbank (ACCESS 97) ein die mittlerweile eine Größe von knappen 100 MB besitzt und natürlich dadurch tierisch langsam wird.

Jetzt stellt sich mir die Frage wie lange das noch gut geht bzw. ob es irgendwann einen tierisch grossen Knall gibt und nix mehr geht.

Vielleicht kann mir ja jemand darauf eine Antwort geben, der mit so etwas eventuell schon Erfahrung gemacht hat.

Ich bin für alle Antworten dankbar.

Danke Andreas

PS: So ein Forum ist echt ne spitzen Sache muss ich mal loswerden...

MarkusR
07.02.2001, 15:17
Bei der Grösse sollte man vieleicht einmal sehen, ob man mit dem Menü

Extras>Datenbankdienstprogramme>Datenbank komprimieren

das Ding kleiner bekommt. (Dabei werden gelöschte Objekte tatsächlich aus der DB entfernt)

Falls die DB wirklich wegen Daten so groß ist, wäre vieleicht auch ein Umstieg auf Oracle oder SQL-Server sinnvoll. Die Applikation könnte man in Access lassen.

Gruß

Markus

Sys-Admin
07.02.2001, 16:27
Ich sag erst mal danke für die prompte Antwort.

Hm das mit dem SQL-Server hab ich mir auch schon gedacht jedoch meinte unser Dientleister (der den Mist geschrieben hat) dass er die Applikation auch umschreiben müsste da diese ja eigentlich Access selber ist (das is ja der Mist). Also müssten die die Applikation z.B. in C++ oder Delphi schreiben um damit dann auf den SQL-Server zugreiffen zu können.

Oder ist es möglich diese Anwendung so zu belassen wie sie ist (Access) und einfach nur die Daten auf einen SQL-Server zu portieren.

Eigentlich kann ich mir das nicht so ganz vorstellen aber in der EDV ist ja bekanntlich so ziemlich alles möglich.

Vielleicht kannst du mir ja noch ne kurze Antwort zukommen lassen wäre supi.

Ansonsten nochmal danke und ich hoffe es kommen noch ein paar Antworten...

Nockenwelle
07.02.2001, 20:17
Hi,

dein Dienstleiser will anscheinend 'ne Menge Geld an dir verdienen;-)
Natürlich kann man auch auf die SQL, Oder Oracle-DB umsteigen. Das wird euch zwar auch Geld kosten, weil zum Beispiel die Gewährleistung verfällt(Falls ihr sowas im Vertrag habt).
Evtl. muss das Programm ein wenig nachgebessert werden. So wie sich das anhört, zerschießt es bald euer Netzwerk. Da müssen die schon etwas sauberer Programmieren.

Cu

ingrf
07.02.2001, 21:04
Man kann die Sql - Tabellen in Access einbinden und dann mit Access wieter Arbeiten.
Aber um Geschwindigkeitsvorteile zu bekommen sollte man nur die Daten nach Access schaufeln die zur Zeit nötig sind.

Aber richtiges Indizieren bringt unter Access auch schon enormen geschwindigkeitsvorteil.

Aber im Netzbetrieb sollte man sowieso SQL-Server benutzen

MarkusR
08.02.2001, 11:41
Der "Dienstleister" kann die Daten auf den SQL-Server portieren, eine ODBC Datenquelle auf den Workstations einrichten, und mit

- Datei>Tabellen Verknüpfen
- Auswahl bei Dateityp ODBC-Datenquelle
- die o.G. Datenquelle auswählen

die Tabellen verknüpfen.

Für die Migration von Access-SQL Server gibt es glaub ich auch irgend ein Tool (Steht bestimt was in den betreffenden Microsoft Internetseiten).

Ist vieleicht keine Sache von 5 Minuten, aber auf C++ oder Delphi muss euer "Dienstleister" bestimmt nicht. Lass dir keinen Bären/Auftrag aufbinden http://www.microsyskramer.de/ubb/wink.gif

Gruß

Markus

Sys-Admin
08.02.2001, 13:58
Also erst mal vielen Dank für die vielen Antworten !

Ist das wirklich möglich die eigentliche Anwendung in Access zu belassen und nur die Daten auf einen SQL-Server portieren ? Anschliessend einfach aus Access raus auf den SQL-Server zugreiffen ???

Wäre meiner Meinung nach die beste Alternative aber ob das funktioniert.

Naja da muss ich mich eben nochmal ganz konkret schlau machen zu diesem Thema.

Vielleicht kommen ja noch ein paar Vorschläge zu dem Thema was ich doch sehr hoffe.

Cu Sys-Admin

HAFISENIOR
08.02.2001, 19:03
Hallo
wir haben auch einige Datenbanken auf dem Server. Meine Erfahrung: Daten vom Programm trennen, regelmäßig komprimieren und wie im Beitrag vorher schon angesprochen, Felder indizieren. Langsam wird's nur durch Abfragen die z. B. unnötige Felder einschließen u.ä.m.

ingrf
08.02.2001, 19:21
Du kannst mir glauben
Wir benutzen einen SQL - Server
Aber Du mußt bedenken der SQL-Server einzurichten und zu verwalten ist ohne kenntnis nicht so einfach.Man sollte für
den SQL-Server auch Windows NE oder 2000 haben.
Aber dafür ist er gerade wenn mehere auf die Datenbank zugreifen Sicherer und Schneller.
Sollte die 100 MB Datenbank nicht im Netz betrieben werden sollte es keine Problem geben sie mit zufriedenstellender Geschwindigkeit anzuwenden.

Villeicht kannst Du alte Daten in eine andere Datenbank speichern und bei bedarf zuschalten ?

Egon
10.02.2001, 11:32
Es gibt ein kleines Proggi, das auf dem Server als Dienst läuft und täglich oder je nach Zeiteinstellung Wartungsarbeiten an einer Access Datenbank durchführt.

Martin78
12.02.2001, 18:15
Also das mit dem SQL-Server funktioniert auf jeden fall. Bei uns laufen Access-Anwendungen die auf Tabellen per ODBC unter Unix (Informix) und auf AS 400 zugreifen.

Wegen der 100 MB Daten würde ich mir noch keine Gedanken machen. Access 97 läuft bis zu 1 GB zuverlässig (so auch bei uns). Unter Access 2000 geht das (angeblich) sogar bis zu 2 GB. Die nächste Version soll noch mehr schaffen. Natürlich bleibt zu bedenken, dass bei solch einem Datenvolumen die Verarbeitungszeiten entsprechend sind. Dies dürfte sich aber bei einer Serverlösung auch nicht besser darstellen, da ja (meist) noch ein Netzzugriff erfolgt.

Ich hoffe dies Hilft dir noch ein wenig weiter.

Sys-Admin
12.02.2001, 18:37
Also ich glaub die 100 MB sind schon ein Problem und das Problem wird ja nicht kleiner sondern grösser...

Und wenn sich ein Client die 100 MB am Anfang mal zieht lagert er ca. 40-50 MB im Arbeitsspeicher (Laut Task-Manager Win2K bei einem PC mit 128 MB RAM) das heisst eigentlich für mich er braucht immer wieder Daten, da der Rechner die DB ja nicht komplett im Arbeitsspeicher lagert.

Den Rest vom Arbeitsspeicher frisst dann ja auch Win2K (so ca. 60 MB) und damit is schon mal auslagern auf der Platte fällig...

Das wiederum heisst doch er muss bei jeder Anfrage eine Netzwerkconnection aufbauen und sich die für die Anfrage benötigten Daten (falls nicht im RAM) immer wieder holen und das belastet das Netzwerk brutalst wenn 30 Leute immer wieder auf die madige Datenbank zugreiffen.

Bei einer Serverlösung ist zwar die Netzwerkconnection auch vorhanden jedoch liefert doch der Server nur das Ergebnis, welches er aus der Abfrage erhält, die wiederum der Client abgeschickt hat.

Das wiederum würde doch heissen wir bewegen uns nicht mehr im MB Bereich sondern im KB Bereich und das wiederum macht speed.

Oder denke ich da ein bischen verkehrt???

Danke für die Atworten

Cya

Sys-Admin

JR
12.02.2001, 22:09
Wis setzen SQL-Server mit Access als Front-End ein. Hauptgrund war unsere Anbindung der Niederlassungen über ISDN, also eine langsamere Verbindung als das Netzwerk.
SQL-Server hat den Vorteil, daß eine Abfrage bereits auf dem Server ausgewertet wird. Daher werden deutlich weniger Daten über das Netz übertragen, was sich besonders bei langsamen Netzen bemerkbar macht.

Wenn Euer Entwickler keine saubere Trennung zwischen Daten und Formularen vorgenommen hat, ist er kein Profi. Wenn er es gemacht hat, ist die Umlenkung auf eine andere Datenbank einfach. Aber die Einführung des SQL-Servers verlangt ein wenig Know-How.

RP
13.02.2001, 07:37
Bei komplizierten Abfragen wird nicht das Ergebnis von dem SQL-Server an Access geschickt, sondern die ganzen Daten.
Kann also unter Umständen sehr lange dauern.Ich musste einiges seinerzeit umprogrammieren (pass-through ...).
Gruss R.P.

Waldemar
20.03.2001, 11:37
Hallo alle zusammen

Also zu deiner Frage (Sys-Admin).
Ich habe selbst bei versch. Kunden nur reine Access-Anwendungen laufen, aber immer mit Frontend und Backend.

Ich hatte das ähnliche Problem wie du auch, daß die Datenbankpflege vernachlässigt wurde.

Nun setze ich grundsätzlich ein Modul ein, daß automatisch jeden Tag eine SicherungsKopie der Datenbank auf den Server ablegt und diese auch Rep. und Komprimiert.
Somit ist gewährleistet,daß die Datenbank immer minimiert ist.

Man müßte den Aufbau und die Struktur der DB kennen um zu beurteilen ob ein Umstieg auf SQL oder Oracle nötig ist (was ich bei 30 PC-Arbeitsplätze bezweifle).

Soviel zu deinen Dienstleister.

Waldemar

Sascha Trowitzsch
20.03.2001, 12:02
Hi zusammen,

ich muss hier nun doch noch was beisteuern:

1. Eine DB mit 100Mb und 30 Usern auf einem Fileserver unter Access zu betreiben ist schlicht ein Witz. Da kann man optimieren wie man will, es wird nicht nennenswert besser (...es sei den man hat GigaEthernet und einen Mehrprozessorserver mit ein paar Gb RAM).

2. Wenn der 'Dienstleister' irgendeinen Quark von Umprogrammieren auf C++ etc. verzapft hat er entweder keine Ahnung, oder keine Lust, oder keine Zeit, oder er will einen (überflüssigen) Riesenauftrag. In jedem dieser Fälle würde ich mir einen Wechsel zu einem anderen Dienstleister überlegen.

3. Der normale Migrationspfad bei gestiegenen Anforderungen unter Access verläuft zum MSSQL-Server. Man kann von MS halten, was man will, aber es wird am billigsten.
Den SQL-Server könnt ihr auf dem Fileserver installieren.
Für die Datenbank gibt es Upsizing-Tools auf MSSQL, unter Acc2000 ist das schon standardmäßig dabei.
Wenn die Abfragen nicht gar zu komplex sind kann das relativ schnell geschehen.
Zukunftssicherer wäre allerdings, die Datenbank auf ADO umzustellen.

Ich denke in einem mittelständischen Unternehmen müsste die Knete für einen solchen Schritt zusammenzukriegen sein.
Ich denke, alles andere wäre an der falschen Stelle gespart und bringt nur Ärger (..."Knall", aber vom Chef?).

Ciao, Sascha

TGA_Project
20.03.2001, 12:16
und was noch keiner so richtig aufgezeigt hat:

1. Es gibt unter Access meines Wissens nach keine Möglichkeit, Transaktionen zu definieren. Dadurch hohe Fehleranfälligkeit.

2. Gleichzeitige Zugriffe führen in Extremfällen zu Datenfehlern oder ungewünschten Effekten (30 User auf die gleiche MDB ist übrigens ziemlich heftig).

3. Access zieht zuerst alle Daten und wertet dann z.B. Abfragen auf dem lokalen Host aus (extreme Netzlast). WIe oben erwähnt laufen solche Prozesse direkt auf dem meist wesentlich leistungsfähigerem DB-Server ab.

4. Und richtig, einfachster Umstieg ist auf MSSQL, Oracle erweist sich als Know-How-Fresser, wo ihr gleich noch einen Mitarbeiter als Admin für einstellen dürft http://www.microsyskramer.de/ubb/wink.gif

------------------
Entstehende Heimat für Programmierer: www.devsource.de (http://www.devsource.de)

Nockenwelle
20.03.2001, 23:04
Hallo (TGA_Project und Sysadmin),

für TGA_project: es gibt die transaction-Methode, commit sowie rollback. Nur bei meinen kläglichen versuchen, diese einzusetzen ist nie viel Sinnvolles bei rausgekommen. Ich denke, das war aber eher mein eigenes geistiges Prob.

Einige Fragen habe ich noch an Sys-admin:
1. Ist das Programm sehr viel schneller, wenn du
a) alleine übers Netz daran arbeitest
b) um wieviel verbessert gegenüber a) sich das Tempo, wenn du, die DB mal Testweise lokal legst
Mach mal konkrete Zeitvergleiche

2. Hast du dir mal die SQL's angeschaut? Wie mächtig sind die? Greifen die jeweils auf viele Spalten der Tabellen zu? Da kann schon der Hase im Pfeffer liegen.
2a) Welchem Joins fehlt ein Index? Bzw. was hat die DB an Indices??

3. Ist wohl allgemein bekannt: Zugriffe mit 'like' können sehr üble Auswirkungen haben. (Tablescans)

4. Ist wohl weniger bekannt:Zugriffe mit 'or' können sehr üble Auswirkungen haben.(Tablescans)

5. Benutzt ihr kartesiche Produkte, die in der where Clause sich nicht ausschließlich auf die Indicefelder berufen oder mehr als ein Ergebnis liefern können?
(schon das erste ist u. U. tödlich)

6. Benutzt Ihr kombinierte Indices? Bei Großrechnerdatenbanken kann das Wunder wirken, wenn man mehrere Indices anlegt und zwar so, das verschiedene Indices bestimmte Programmabfragen beschleunigen.
Bei Access->geht so:-(
(Ich weiss, es verlangsamt das speichern, aber das ist meist lächerlich im Vergleich zum Suchen, was man meist 20-30 mal häufiger macht).

7. Wieviele Adressdaten habt ihr ca?
Kann es sein, dass die Anwendungsabfragen über mehrere Namensfelder laufen?

8. Benutzt die Anwendung "select count *..."? Besser ist count(Index)

9. Primary-Keys behandelt Access anders als Indices(ohne Dublikate).

Ein Umstieg auf SQL-Server kann sich schon deswegen lohnen, weil der DB-Server einen Optimizer besitzt(meines wissens in den neueren Versionen sogar einen sehr intelligenten). Den muss man allerdings einzusetzen verstehen. Ich hab' hier irgendwo eine Dokumentation(wenn auch nicht für SQL-Server) von einer Firma, die sich speziell mit Geschwindigkeitsoptimierungen von DBn befasst. Da werden Tips gegeben, welche SQL's schade sind und wie das zu ändern ist, Indices, wie man einen DB-Server über Statistiken reinlegen kann, welche Tabellenstruktur man nehmen sollte(mit Beispielen), wie ein Optimizer arbeitet, wann sich ein Optimizer sich mit sich selbst beschäftigt(d.h er brauch 3 Sekunden zum Optimieren der Abfrage, die dann 0,1 Sekunden braucht) etc.

Beispielsweise kann es sehr viel schneller sein, 10 oder 20 Abfragen, die vernünftig über gesetzte Indices laufen, übers Netz zu jagen, als eine, die über einen falschen oder unnötigen Join 1000 DS locked. Ich wollte das Dokument eigentlich nur noch ergänzen(Teilweise den DB-Spezifischen Teil rausnehmen), und für mich mit ein bisschen mehr Leben füllen. Vor allem, besser dokumentieren, wie man über vernünftige Strukturen verhindern kann, dass die Antwortzeiten sich mit zunehmendem Datenbestand ändern(das geht, auch bei Millionen von DS!).

Wenn ich das soweit habe, dass der Ursprung nicht mehr zu erkennen ist, schaue ich mal, dass es irgendwie ins Netz kommt. Kann aber noch'n bisschen dauern.

Cu