Netzwerkperformance erhöhen

[Bernie110]

Hallo zusammen,

ich hab eine Accessdatenbank auf unserem Firmenserver.
Auf diese DB greifen ca 20-30 Mitarbeiter zu.

Ich hab 2 Tabellen mit wahnsinnig vielen DS .

DT_Erfassung = 95000 DS
ERFASSUNG_COLLI = 234 000 DS

und die DB wird immer langsamer.

Mit wenigeren DS war die DB echt schnell...

jetzt kam mir die Idee diese 2 Tabellen zug für zug zuentleeren,.
Von diesen in Tbl DT_Erfassung = 95000 DS werden aktuell vll ca 10000 benötigt.

Ich stell mir das so vor.
ich erstell die gleiche Tabelle mit den gleichen Felderen..(alles ist gleich )
Beispiel
DT_ERFASSUNG ( aktuelle Datensätze )
DT_ERFASSUNG_SAVE  ( abgeschlossenen DS ) Diese schaut man sich nicht mehr so oft an und werden kaum benötigt.

Wird ein DS abgeschlossen..also d.h. er wird nicht mehr benötigt wird er von DT_ERFASSUNG einfach in die
neue Tabelle DT_ERFASSUNG_SAVE kopiert und in DT_Erfassung gelöscht.

(oder  vielleicht  komplett nach Monaten übertragen .... oder so ähnlich.)

Sollte eigentlich technisch möglich sein... auch wenn ich nicht genau weiss wie....

Nun zu meiner eigentlichen Frage.. macht das überhaupt Sinn ? bzw. wird es zur Performancesteigerung beitragen ?

danke für eure Antworten.


Lg Bernie

PS .. ich frag lieber mal nach, bevor ich mich mal wieder in etwas verrenne :-)

[MzKlMu]

Hallo,
hast Du die DB schon mal komprimiert/rerariert (Access Dienstprogramm)?

Sind alle relevanten Felder (zum Suchen, für Where etc.) indiziert?

Indizierungen sind für die Performance der DB von entscheidender Bedeutung.
Außerdem spielt natürlich das Netzwerk selbst auch eine Rolle.

[Bernie110]

Hi,

ja alles schon versucht. Wenn ich nicht fast jeden Abend komprimiere / repariere, dann geht fast nix mehr. 

Bringt denn meine Idee etwas ?

Lg Bernie

[database]

Hallo,

natürlich kannst du eine Archiv-DB anlegen und die nicht mehr gebrauchten DS dorthin transferieren.
Wenn die DB mit weniger DS besser gelaufen ist, wird sich durch die 'Verschiebung' von Datensätzen wieder
eine Besserung der Performnance bemerkbar machen.

Allerdings darfst du nicht ausßer Acht lassen, dass Primärschlüssel, die in der Original-DB als AutoWert geführt werden in der Archiv-DB
einen anderen Wert bekommen, wenn dort die Primärschlüssel auch als Autowerte deklariert werden!
Somit müsstest du in den Archivtabellen die 'alten' Schlüsselfelder als LongInteger führen, um die Originalschlüssel zu erhalten.

Zum Hinweis von Klaus bezgl Netzwerk möchte ich noch hinzufügen, dass die Anzahl von 20-30 Benutzer auch nicht gerade performancesteigernd wirkt
insbesondere dann, wenn die Anzahl von Leuten gleichzeitig zum Backend (ein solches wird es hoffentlich geben  ) verbunden sind.

Bei dieser Anzahl von Benutzern würde ich persönlich schon daran denken das Backend auf einen DB-Server zu verlegen.

[Bernie110]

Hallo Data,

danke für deine Antwort.

ja es gibt ein FE/BE

Bezgl. des Primärschlüssels.. ja das war mir schon klar. Den möchte ich natürlich erhalten ;-)

Wäre es dann vll doch eher sinnvoll ich leg mehre Tabellen kopieen an ?

Also es gibt 3 Abteilungen die mit der DB arbeiten.. eine davon liesst nur die erfassten DATEN..also reine information
Diese Abteilung kann nichts an den Daten ändern. Nur filtern...

Gibt es hierfür eventuell eine geignete Idee..

Ich habs so umgesetzt.. Die haben ein eigenes FE .. im Prinzip fast das Gleiche wie die beiden Anderen Abteilungen haben,.. nur können die eben keine DATEN ändern. Eben nur Filter..

Lg Bernie

[bahasu]

Hi,

vielleicht hilft:
http://dbwiki.net/wiki/Access_Performance-Tipps

Bei war es mal sehr hilfreich gewesen, einen persistenten record zu nutzen.
http://www.access-o-mania.de/forum/index.php?topic=16578.msg95420;topicseen#msg95420

Harald

[ebs17]

Wenn ich nicht fast jeden Abend komprimiere / repariere, dann geht fast nix mehr.

Da klingelt doch ein Glöckchen. Bei einfachen lesenden Zugriffen sollte das gar nicht nötig sein, bei einfach anfügenden Zugriffen eher selten. Bei massiven Datenumschichtungen ist dann ein öfteres Komprimieren notwendig.
Was wird da wirklich gemacht?

und die DB wird immer langsamer

Wobei genau?

Bezüglich Filtern: Man kann filtern wie ein Anfänger oder Filtern wie ein Profi, Stichwort Indexnutzung.
Indexnutzung heißt dabei benötigten Index haben + Index auch verwenden.
Wie sieht es da bei Euch aus?

MfGA
ebs

[Wurliwurm]

Indexe helfen, den Netzwerk-Traffic zu reduzieren. Bei einer solchen Useranzahl ist ein
reines Jet-System aber überfordert und deshalb die Migration auf ein
Datenbanksystem die einzige wirklich Lösung.

www.vb123.com/SA200208_mg.pdf

Client/Server, .NET, and ODBC

Mike Gunderloy

(...)

Look at it this way: As far as Jet is
concerned, there isn't really much difference between
an MDB on the client and an MDB on the server. To
Jet's way of thinking, a server is just a big hard drive
that's sort of slow at delivering information. And,
because Jet has an intimate knowledge of the Access
file format, it can use search strategies other than
simply reading all the records in a table to find a
particular record.

Consider a query like this one:

SELECT * FROM [Order Details] WHERE OrderID = 10704

With an index on the OrderID field, Jet doesn't
have to read every row of the table to locate the desired
records. Instead, it can read the OrderID index and use
that index to locate the correct records in the file. Then
Jet needs only read those pages from the file that
contain the desired information.

(...)

So is that why most experienced developers
recommend moving the SQL Server for networked
databases? Not really. With today's network speeds,
it's not often that the download of a single index is
going to make a difference that's visible to the end
user. Normally, it's not the speed but the number of
simultaneous users that dictates a move to a client/
server database. This, too, is a consequence between
the processing schemes used by a file/server database
and a client/server database.

When you have five or 10 (or 50) clients sharing
a single file/server database, you have that many
programs actually modifying the shared file. The
different copies of Jet don't talk to each other, so they
have to communicate by locking sectors on the server,
and they all have to do their job perfectly. Turn off a
computer, or kick out a network cable, and you can
leave things in an inconsistent state for everyone.

In contrast, it doesn't matter whether a client/
server database has one client or 100, the disk file is
only being read and modified by a single program: the
database server manager. The database server manager
can act as a traffic cop and gatekeeper for all of the
clients. The manager has complete knowledge about
the database file because it's the only application
modifying the file. Turn off your computer and the
server will notice and release any locks that it was
holding on your behalf. The result is that client/server
databases are inherently more robust than multi-user
file-server databases. (...)

[Bernie110]

Hallo Zusammen,

ersteinmal danke für eure Antworten.

Ich hab die Tabellen der DB jetzt auch einen SQL Server Exportiert.
Natürlich ersteinmal nur eine TEST-Version..
Da ich jetzt nicht die gleichen Bedingungen schaffen kann ( also alle User greifen darauf zu ) mal die Frage
ob sich  dann die Performance verbessern wird ?

Könnte dies  meine Probleme beheben ?

Lg Bernie