Αποτυχία κλειδώματος του πίνακα ενεργών χρηστών. Συμφόρηση βάσης δεδομένων αρχείων - πώς να αποφύγετε (από πρόσφατη εμπειρία). Εκτελέστηκε μεγάλος αριθμός επεμβάσεων

Κόστος 8,1 για 5 χρήστες.
Χρησιμοποιούμε τυπική λογιστική.
Λειτουργούν κυρίως μέσω του τερματικού σταθμού, μερικές φορές χωρίς αυτό.
Επιλογή βάσης δεδομένων - αρχείο
Σφάλματα που παρατηρήθηκαν από όσους βρίσκονται στο τερματικό



κάτι σαν αυτό. Έψαξα στο δίκτυο, το Yandex - γενικά, όλα είναι κάπως ασαφή.
Βρέθηκαν βασικές συστάσεις:
1) Ξεφόρτωση/Φόρτωση της βάσης δεδομένων - με την έννοια της δημιουργίας μιας νέας από τον διαμορφωτή
2) εκτελέστε το \Program Files\1cv81\bin\chdbfl.exe - έλεγχος της φυσικής ακεραιότητας της βάσης δεδομένων
3) Δοκιμάστε και διορθώστε τη βάση πληροφοριών
4) ενημέρωση στην πιο πρόσφατη έκδοση 8.1

Ξέρει κανείς κάτι πιο συγκεκριμένο;

13.5.2010, 10:05

Το μόνο που χρειάζεστε έχει ήδη προταθεί σε εσάς. Υπάρχουν φυσικά σφάλματα στα μέσα;
Δεν νομίζω ότι κάποιος μπορεί να είναι πιο συγκεκριμένος.

13.5.2010, 10:56

Αυτό λοιπόν... αν το θεωρήσουμε χωρίς να λάβουμε υπόψη το 1C, αλλά γενικά, τότε βλακωδώς κάποιος από δύο μέρη προσπαθεί να μπλοκάρει ένα τραπέζι, το πρώτο πετυχαίνει και τα υπόλοιπα στέλνονται. Κοιτάξτε ποιες λειτουργίες/συναλλαγές/επεξεργασίες (ή όπως αλλιώς το αποκαλούν στο 1C) εκτελούνται αυτή τη στιγμή. Ίσως το ζήτημα να μην είναι η πλατφόρμα, αλλά οι λανθασμένα γραμμένες διαμορφώσεις ή ο τρόπος με τον οποίο λειτουργούν αυτές οι διαμορφώσεις στα δεδομένα σας.

ΥΣΤΕΡΟΓΡΑΦΟ. Και οι βάσεις δεδομένων αρχείων σε λειτουργία πολλών χρηστών είναι μια παραμόρφωση.

13.5.2010, 10:58

Αν και ποιος διάολος ξέρει πώς φτιάχνεται η βάση δεδομένων στο 1C-v, μπορεί κάλλιστα να υπάρχει κάποιο πρόβλημα κάπου στη βάση δεδομένων και κάθε είδους επισκευές θα βοηθήσουν.

13.5.2010, 11:06

Ναι, μου φαίνεται ότι το οκτάγωνο είναι σαν πλατφόρμα - είναι ακόμα υγρό. Κάπου έγραψαν ότι έλεγχος και διόρθωση πρέπει να γίνεται ΠΕΡΙΟΔΙΚΑ

13.5.2010, 11:10


απίθανος. Για τους οκτώ, ένας νέος διακομιστής αγοράστηκε με άδεια χρήσης Windows


Η ουσία είναι ότι κάποιος κλειδώνει το τραπέζι, οι υπόλοιποι περιμένουν μέχρι το τάιμ άουτ.
Το γιατί δεν έχουν χρόνο είναι μεγάλο ερώτημα. Ρίξτε μια ματιά στα φυσικά μέσα, μπορεί να είναι ανόητο. Syslog, MHDD. Και όλες εκείνες οι ενέργειες που αναγράφονται στην πρώτη ανάρτηση είναι υποχρεωτικές.

ΥΣΤΕΡΟΓΡΑΦΟ. Καινούργιο δεν σημαίνει ότι λειτουργεί 100%.

13.5.2010, 11:38

Όλα όσα χρειάζεστε σας έχουν ήδη προταθεί, δοκιμάστε τα πρώτα


οπότε ναι, πρέπει να περιμένουμε μέχρι το βράδυ.
Δεν υπήρχε ελπίδα να ακούσω κάτι νέο

Μην λέτε θαύματα. Υπάρχουν πολλά προβλήματα εκεί, αλλά δεν είναι αυτά.


που είναι τα θαύματα; Δεν καταλαβαίνω, κάποιος θα ισχυριστεί ότι το 8.1 είναι μια δροσερή, άψογη πλατφόρμα;

έγραψε ότι ο έλεγχος και η διόρθωση πρέπει να γίνονται ΠΕΡΙΟΔΙΚΑ


Φαίνεται ότι έχουμε μια τέτοια περίπτωση.
Μια έρευνα μεμονωμένων χρηστών (για να μην ξαπλώνουν μαζί) έδειξε ότι αυτή η κατάσταση φαίνεται να συμβαίνει ΜΟΝΟ μεταξύ των χρηστών που εργάζονται στο τερματικό. Και όσοι δεν περνούν από το τερματικό που
Windows Server 2003 R2 Standart 64, είτε δεν θυμούνται αυτήν την κατάσταση είτε απλά δεν τους πέρασε από το μυαλό.
Επιπλέον, δύο ιδιαίτερα παρατηρητικοί παρατήρησαν ότι πριν από 1,5-2 μήνες το φαινόμενο αυτό παρατηρούνταν ΠΟΛΥ λιγότερο συχνά

13.5.2010, 12:42

Γεννημένος δολοφόνος, Υπάρχει κάποιο πρόγραμμα προστασίας από ιούς εγκατεστημένο στον διακομιστή; Εάν ναι, δοκιμάστε να το απενεργοποιήσετε ή να προσθέσετε τη βάση δεδομένων σε εξαιρέσεις

13.5.2010, 13:14

Υπάρχει κάποιο antivirus εγκατεστημένο στον διακομιστή;


Λοιπόν, θα πρέπει να ρίξω μια ματιά. Αυτός είναι ένας διακομιστής εχθρού
Τα smart-ass francs πήραν μια από τις βάσεις δεδομένων μας για συντήρηση, ασφάλισαν τον διακομιστή τους και φαίνεται να επιβλέπουν την εργασία μας
Παρέχονταν πρόσβαση στον διακομιστή τους, αλλά σε απογυμνωμένη έκδοση.
Θα ρίξω μια ματιά.

Δεν φαίνεται να υπάρχει antivirus...

13.5.2010, 13:23

Δεν καταλαβαίνω, κάποιος θα ισχυριστεί ότι το 8.1 είναι μια δροσερή, άψογη πλατφόρμα;
ω καλά. Το 7.7 είναι ακόμα χάλια κατά τόπους, αλλά περίπου 8 ήρθε η ώρα να γράψουμε θρύλους για τις δυσλειτουργίες του



Πόσο μεγάλη είναι η βάση δεδομένων και πόσοι χρήστες;

Προσθέστε το. Δώστε ένα συγκεκριμένο παράδειγμα.
Πόσο μεγάλη είναι η βάση δεδομένων και πόσοι χρήστες;


Έκανα μια δοκιμή το βράδυ και το διόρθωσα. Πριν από αυτό, το 1cv8.1CD ήταν 2 GB, τώρα είναι 1,5 GB.
Υπάρχουν 5 χρήστες, καθώς και η ίδια η άδεια.
Όσον αφορά τους θρύλους για δυσλειτουργίες, υπήρχε μία περίπτωση. Τώρα, εάν πάρετε το 7.7 και απλώς αντιγράψετε 1 βάση δεδομένων μέσω Total σε άλλη τοποθεσία - ένα αντίγραφο χωρίς προβλήματα.
Μόλις προσπάθησα να κάνω το ίδιο πράγμα με μια οκταπλή βάση δεδομένων, αντέγραψα τον κατάλογο της βάσης δεδομένων σε άλλη τοποθεσία,
καταχωρήθηκε, άνοιξε και τις δύο βάσεις δεδομένων ταυτόχρονα, η μία προοριζόταν για παραμορφώσεις.
Σημείωσα πολλά έγγραφα για διαγραφή στο αντίγραφο, άλλαξα στο παράθυρο με την πραγματική βάση δεδομένων και δεν πίστευα στα μάτια μου: τα ίδια έγγραφα επισημάνθηκαν για διαγραφή και εκεί


Το Ash stump, 1C έχει μια απάντηση σε όλα: δημιουργήστε ένα καθημερινό αντίγραφο της βάσης δεδομένων.
Ναι, αλλά αυτή είναι μια κακή απάντηση

ΜΜΜαρίνα

Γεννημένος δολοφόνος,

Γεια σου φίλε...


Μύθος!
Έτσι γεννιούνται οι θρύλοι...

Γεια σου φίλε...


Γεια σου φίλε. Έτσι παρασύρθηκες

Και τότε τα εικονίδια στην επιφάνεια εργασίας σίγησαν


Μύθος!
Έτσι γεννιούνται οι θρύλοι...


Το είδα. Δεν ήταν αστείο για μένα να κάνω διάκριση μεταξύ δημοσιευμένων και μη δημοσιευμένων εγγράφων μετά την αφαίρεση του σήματος διαγραφής, όλα γίνονται μη αναρτημένα.

Δεν θυμάμαι ποια πλατφόρμα υπήρχε τότε.

προσπαθήστε να κάνετε το ίδιο. Ίσως το καταφέρεις κι εσύ

Έτσι γεννιούνται οι θρύλοι...


Θα πω περισσότερα: όταν ξεμαρκάρισα με μη αυτόματο τρόπο μερικά έγγραφα για διαγραφή,
Το ίδιο συνέβη και στην πραγματική βάση δεδομένων. Δεν είχα χρόνο τότε να καταγράψω με κάποιο τρόπο αυτή την αίσθηση.
Οπότε τα έβαλα όλα όπως ήταν και δεν το ξανάκανα.

εξαλείφοντας τα κενά στη γνώση υπολογιστών...
Πραγματικά πιστεύω ότι είμαι απελπισμένη...


Το συγκεκριμένο θέμα δεν είναι καθόλου για σένα, αγαπητέ (γ)
γενικα ολα ειναι κατανοητα
κάντε έναν φίλο geek υπολογιστή, προαιρετικά)))

Σημείωσα πολλά έγγραφα για διαγραφή στο αντίγραφο, άλλαξα στο παράθυρο με την πραγματική βάση δεδομένων και δεν πίστευα στα μάτια μου: τα ίδια έγγραφα επισημάνθηκαν για διαγραφή και εκεί shok.gif



Δεν έχω αντιγράψει ποτέ μια βάση δεδομένων αρχείων με μια 8η
Δεν ήταν σε καμία περίπτωση αίσθηση.

Μπορεί να μην το πιστεύεις, αλλά ΕΓΙΝΕ.


Γεγονός είναι ότι συνεργάστηκα πολύ στενά με το 8 για αρκετά χρόνια. Μόλις δεν αντιγράφηκαν. Οπότε δεν μπορώ να το πιστέψω
Αλλά μπορώ να υποθέσω ότι όταν ένας άνθρωπος είναι υπερβολικά κουρασμένος, πολλά είναι δυνατά. Το ξέρω από τον εαυτό μου.

Μην ανησυχείτε, η βάση δεδομένων αρχείων μπορεί εύκολα να αντιγραφεί και να αυξηθεί με οποιονδήποτε άλλο τρόπο. Δεν πρέπει να υπάρχουν σφάλματα.

14.5.2010, 10:52

14.5.2010, 11:28

Έχω μια εικασία: Έχω καταχωρήσει την ίδια βάση δεδομένων δύο φορές όταν σταθμεύσα.



8 προτείνει την αντικατάσταση

14.5.2010, 11:31

όχι... 7.7, όταν προσπαθώ να το κάνω αυτό, είναι ανόητα σιωπηλός και δεν προσθέτει τη βάση δεδομένων στη λίστα (απλώς δεν αντιδρά καθόλου)
8 προτείνει την αντικατάσταση


Ίσως απλά έχασα με ένα ποντίκι και εκτόξευσα το ίδιο... Θαύματα δεν γίνονται

14.5.2010, 11:47

Ίσως απλά έχασα το σημάδι με το ποντίκι μου και ξεκίνησα το ίδιο...


Θα προσπαθήσω να φτιάξω κάτι παρόμοιο στο σπίτι. Θα ξαναγράψω αργότερα.
Συνήθως, πριν από οποιαδήποτε επικίνδυνη ενέργεια, στο 1C (7.7. ή 8) κάνω κλικ στο ερωτηματικό (εκεί φαίνεται η διαδρομή προς τη βάση δεδομένων).

Τότε ο κόσμος γέλασε με τον μύθο μου τόσο ομόφωνα που άρχισα να αμφιβάλλω.
Αν και υπάρχουν περισσότερες δυσλειτουργίες στα οκτώ παρά στα επτά.

Ω, τι ηλίθιο σφάλμα, δεν ήμουν ο μόνος που το είδα αυτό.
Γενικά, κορόιδευαν μια 8η βάση σε έναν πελάτη όταν ακόμα δούλευα στο franchise.
Μια μέρα ένα άτομο, μια άλλη - τη δεύτερη, την τρίτη πήγα. Τους ρώτησα - έκαναν εφεδρικό αντίγραφο πριν από τα exploits; Σε απάντηση - γελάνε σαν άλογα, σκόραραν με λίγα λόγια, μόνο που πήραν τη βάση σε αυτό το αυτοκίνητο

14.5.2010, 12:35


- γελάνε σαν τα άλογα, το σκόραραν πιο κοντό, μόνο που πήραν τη βάση τοπικά,
και είχα την ευκαιρία να τη γαμήσω από το δίχτυ. Ακολουθώντας το παράδειγμα του προηγούμενου Tavarischi, αποφάσισα να μην δημιουργήσω αντίγραφο ασφαλείας,
Ήταν νέος και ηλίθιος - υπήρχε πολλή επίδειξη.
Γενικά, έκανα αλλαγές στο conf, αποθηκεύω το conf, κατά την αποθήκευση του conf, έγινε κάποιο ατύχημα και έπεσε η βάση δεδομένων, το βράδυ. Αποπληξία. Το πρωί, 3 ειδικοί, μεταξύ των οποίων και εγώ, πήγαμε εκεί.
Το ατύχημα ήταν ότι ο αριθμός έκδοσης αποκόπηκε από τη βάση δεδομένων, δηλ. στη διαμόρφωση, όταν κάνατε κλικ στην ερώτηση, ήταν κενή και το όνομα του ίδιου του conf έλειπε. και όταν μπήκα στη βάση δεδομένων, δεν ήταν ορατό τίποτα, συμπεριλαμβανομένης της διεπαφής. πέταξε μακριά, ήταν αδύνατο να εισαγάγετε τα αρχεία καταγραφής εγγράφων.
Επιλύσαμε το πρόβλημα ενημερώνοντας τη σκοτωμένη βάση δεδομένων με ένα σχετικά νέο αρχείο ρυθμίσεων, όλα λύθηκαν.
Όλα έχουν ξαναγεννηθεί.
Αυτό είναι ένα παράδειγμα ενός πραγματικού θρύλου. 3 άτομα δεν πρέπει να κάνουν λάθος ταυτόχρονα

14.5.2010, 13:53

κατά την αποθήκευση του conf, συνέβη κάποιο είδος ατυχήματος και η βάση δεδομένων έπεσε


Λοιπόν, αν ήταν πρόβλημα υλικού, τότε τίποτα δεν προκαλεί έκπληξη.
Αλλά αν εντοπίσατε ένα σφάλμα που εμφανίζεται σταθερά μετά την εκτέλεση συγκεκριμένων ενεργειών, τότε είναι μια διαφορετική ιστορία.

14.5.2010, 14:39

Λοιπόν, αν ήταν πρόβλημα υλικού, τότε τίποτα δεν προκαλεί έκπληξη


Λοιπόν, τι έγινε. Το σίδερο, το πλέγμα ή η πλατφόρμα δεν είναι τόσο σημαντικά τώρα.
Μου φαίνεται ότι το λογισμικό δεν πρέπει να συμπεριφέρεται τόσο μαγευτικά
Αυτό είναι το ίδιο με το να κυκλοφορείς τα Vista και να παραδέχεσαι ότι είναι χάλια. Κάπως γρήγορα πήδηξαν από το 8,0 στο 8,1
ΥΣΤΕΡΟΓΡΑΦΟ. Καταλαβαίνω την έννοια της λέξης bug, σας ευχαριστώ για την ανησυχία σας)))

14.5.2010, 19:37


Ας πούμε, εάν, κατά την κύλιση των service pack ή κάτι σημαντικό στα Vista, παρουσιαστεί ένα παρόμοιο «σφάλμα», τότε είναι πιθανό το σύστημα, ακόμη και αν εκκινήσει, να λειτουργεί εξαιρετικά ασταθές.
Ή, ας πούμε, τη στιγμή της λήψης ινσουλίνης, γίνεται σεισμός, τότε ο διαβητικός μπορεί να πεθάνει, γιατί. η σύριγγα κύλησε κάτω από τον καναπέ ενώ κουνήθηκε.

14.5.2010, 22:32

Born Killer, Υπάρχει κάποιο antivirus εγκατεστημένο στον διακομιστή; Εάν ναι, δοκιμάστε να το απενεργοποιήσετε ή να προσθέσετε τη βάση δεδομένων σε εξαιρέσεις


Πώς μπορεί ένα πρόγραμμα προστασίας από ιούς να επηρεάσει τις κλειδαριές τραπεζιών; Η βάση 8.x είναι ένα αρχείο.

Σημείωσα πολλά έγγραφα για διαγραφή στο αντίγραφο, άλλαξα στο παράθυρο με την πραγματική βάση δεδομένων και δεν πίστευα στα μάτια μου: τα ίδια έγγραφα επισημάνθηκαν για διαγραφή και εκεί shok.gif
Γενικά, δεν μου άρεσε αυτό το γαμημένο κορυφές, από τότε έχω κάνει μόνο ένα αντίγραφο της βάσης δεδομένων μέσω της αποστολής/φόρτωσης.
Πώς σας φαίνεται αυτός ο θλιβερός θρύλος, κύριε;
Τι θα γινόταν αν παρασυρόμουν και έκανα πιο σοβαρά πράγματα στο αντίγραφο (για παράδειγμα, διαγραμμένα έγγραφα με σήμανση για διαγραφή) και κατά κάποιο ασαφές τρόπο, οι ίδιες ενέργειες πραγματοποιήθηκαν στην κύρια βάση δεδομένων;


Όχι, αυτό δεν μπορεί να είναι, θαύματα δεν γίνονται. Πιθανότατα έχετε συνδεθεί στην ίδια βάση δεδομένων... Στο 8, μπορείτε να συνδεθείτε στη βάση δεδομένων 2 φορές με το ίδιο όνομα χωρίς κανένα πρόβλημα.

Κατά καιρούς εμφανίζονταν προβλήματα κατά τη διεξαγωγή/καταγραφή εγγράφων με σφάλμα της φόρμας
"Διένεξη κλειδώματος κατά τη συναλλαγή: Δεν ήταν δυνατό το κλείδωμα του πίνακα "_DOCUMENT158"


Επομένως, το πρώτο πράγμα που πρέπει να κάνετε είναι να προσδιορίσετε σε ποιο έγγραφο μεταδεδομένων αντιστοιχεί ο πίνακας "_DOCUMENT158". Για το σκοπό αυτό υπάρχει μια μέθοδος καθολικού περιβάλλοντος "GetDatabaseStorageStructure". Με αυτόν τον τρόπο θα καταλάβετε τουλάχιστον ποιο ακριβώς έγγραφο είναι "buggy".

Στη συνέχεια, πρέπει να καταλάβετε αν κάποιος άλλαξε τη μονάδα αγωγιμότητας σε αυτό και να χτυπήσει το κεφάλι εάν την άλλαξε σε ένα μέρος. Πιθανότατα, τα σύνολα εγγραφών καταχωρητών γράφονται ρητά χρησιμοποιώντας τη μέθοδο Write αντί να επιτρέπεται στην πλατφόρμα να το κάνει σωστά. Και η σειρά τους είναι μπερδεμένη...
Δεν υπάρχουν αδιέξοδα;

Γενικά, 5 άτομα δεν πρέπει να διατηρούνται σε λειτουργία αρχείου. Μπορείτε να πάρετε ένα δωρεάν subd, να αγοράσετε μόνο ένα κλειδί για τον διακομιστή συμπλέγματος και αυτό είναι. Ή είναι πολύ ακριβό για το γραφείο;
Δεν θυμάμαι αν το τεχνολογικό αρχείο καταγραφής μπορεί να τραβηχτεί σε λειτουργία αρχείου ή όχι.....

14.5.2010, 22:53

=========================================================
http://odines.ru/thread1386.html - αυτό είναι το νήμα σας;

Δηλαδή η συναλλαγή δεν περνάει ούτε όταν δουλεύει ένας χρήστης;; Τότε το πρόβλημα μάλλον δεν είναι στον στραβά κώδικα κατά την εγγραφή κινήσεων. Επειδή δεν μπορεί να υπάρχουν κλειδαριές σε λειτουργία ενός χρήστη. Η εγγραφή γίνεται διαδοχικά.

Τότε φαίνεται ότι το πρόβλημα έγκειται στις παραβιάσεις στη δομή της ίδιας της βάσης δεδομένων.
Είναι καλύτερα να εκτελέσετε πρώτα τη δοκιμή και τη διόρθωση της βάσης δεδομένων με ενεργοποιημένη τη σημαία "Αναδιάρθρωση πινάκων βάσης πληροφοριών".
Το ανέβασμα στο dt και μετά το φόρτωμα έχει επίσης νόημα...
Το chdbfl.exe είναι απίθανο να βοηθήσει σε αυτήν την περίπτωση... αν και φυσικά αξίζει να το δοκιμάσετε αν όλα τα άλλα δεν βοηθούν.

Gee - μόλις τώρα κοίταξα την ημερομηνία των δημοσιεύσεων στο νήμα http://odines.ru/thread1386.html Και η ανάπτυξη τυπικών σε μια νέα ελεγχόμενη λειτουργία δεν είναι μακριά.
Και η διαφορά μεταξύ 8.2 και 8.1 είναι πολύ μεγαλύτερη από ό,τι μεταξύ 8.1 και 7.7, ειδικά για τους προγραμματιστές, ο εγκέφαλός τους πρέπει να ανακατασκευαστεί πλήρως για να αναπτυχθεί για έναν "ελεγχόμενο" τρόπο λειτουργίας

Στα συστήματα πολλών χρηστών, η σωστή οργάνωση της δομής και η τοποθέτηση κλειδαριών παίζει σημαντικό ρόλο. Εάν δεν υπάρχει, οι χρήστες θα πρέπει συχνά να αντιμετωπίσουν σφάλματα που προκαλούνται από τον ανταγωνισμό για ορισμένους πόρους του συστήματος. Αλλά υπάρχει ένα πρόβλημα διένεξης κλειδαριάς που είναι γνωστό σε πολλούς χρήστες. Γιατί συμβαίνει μια διένεξη κλειδώματος 1C και πώς να την επιλύσετε;

Διένεξη κλειδαριάς στο 1C 8.3 και η σημασία της

Για τους περισσότερους χρήστες, ένα μήνυμα σχετικά με μια διένεξη κλειδώματος 1C σημαίνει μόνο ένα σφάλμα που τους εμποδίζει να κάνουν τη δουλειά τους. Θέλουν να απαλλαγούν από αυτό το πρόβλημα όσο το δυνατόν γρηγορότερα και να πολιορκούν το τμήμα πληροφορικής με παράπονα ότι «το 1C δεν λειτουργεί».

Αλλά για τους διαχειριστές συστήματος και τους προγραμματιστές, ένα τέτοιο μήνυμα υποδεικνύει ότι ενδέχεται να υπάρχουν προβλήματα στη δομή διαμόρφωσης. Προτού προσπαθήσετε να ευχαριστήσετε τους χρήστες και να αφαιρέσετε τα μπλοκαρίσματα, πρέπει να αναλύσετε την κατάσταση και να κατανοήσετε τον λόγο για το μήνυμα σφάλματος.

Λόγοι αποκλεισμού σφαλμάτων στο 1C

Η δοκιμαστική δοκιμή φορτίου δείχνει ότι ο διακομιστής 1C μπορεί να αντέξει την παράλληλη λειτουργία περισσότερων από πέντε χιλιάδων χρηστών. Αλλά οι ιδανικές συνθήκες για τέτοια πειράματα είναι αδύνατες στις καθημερινές συνθήκες των μεγάλων και μεσαίων επιχειρήσεων. Για να επιτύχετε παρόμοια απόδοση και λειτουργία χωρίς σφάλματα, η διαμόρφωση πρέπει να είναι ιδανικά σχεδιασμένη και προσαρμοσμένη στις συγκεκριμένες επιχειρηματικές διαδικασίες της επιχείρησης.

Εάν δεν λάβουμε ιδανικές επιλογές, τότε συμβαίνουν διενέξεις κλειδώματος 1C για τους ακόλουθους λόγους:

Ταυτόχρονη εργασία χρηστών με μεγάλο όγκο δεδομένων.Αυτή η βασική αιτία υπαγορεύεται από τους εσωτερικούς μηχανισμούς του 1C. Περιλαμβάνουν την απαγόρευση αλλαγών σε δεδομένα που εμπλέκονται σε μια συναλλαγή που εκκινείται για λογαριασμό άλλου χρήστη.

Λάθη και παραλείψεις στη διαμόρφωση.Η δομή των τυπικών λύσεων από την εταιρεία 1C λαμβάνει υπόψη συστάσεις για τη μεγιστοποίηση της παραγωγικότητας. Ωστόσο, οι προγραμματιστές τρίτων δεν τηρούν πάντα υψηλά πρότυπα και τα ακόλουθα ελαττώματα μπορούν συχνά να βρεθούν στον κώδικά τους:

  • Μη βέλτιστα ερωτήματα.
  • Αίτημα για υπόλοιπα στην αρχή των ενεργειών.
  • Παρανόηση του σκοπού των αντικειμένων διαμόρφωσης και η εσφαλμένη χρήση τους.
  • Πλεονασμός κλειδαριών που είναι ενσωματωμένες στο σύστημα ή έχουν αναπτυχθεί επιπλέον.

Πώς να διορθώσετε μια διένεξη κλειδαριάς στο 1C 8.3

Το μήνυμα συστήματος "σύγκρουση κλειδώματος κατά την εκτέλεση μιας συναλλαγής 1C 8.3" δεν χαρακτηρίζει τη διαμόρφωση ως εσφαλμένα σχεδιασμένη. Αν όμως αυτά τα σήματα αγνοηθούν, τότε υπάρχει πιθανότητα να δημιουργηθούν μεγάλα προβλήματα την πιο κρίσιμη στιγμή, για παράδειγμα, κατά την υποβολή τριμηνιαίων ή ετήσιων εκθέσεων. Στην καλύτερη περίπτωση, ένα νωθρό σύστημα και δυσαρεστημένοι χρήστες. Στη χειρότερη περίπτωση, τα δεδομένα εξόδου είναι εσφαλμένα, γεγονός που μπορεί να οδηγήσει σε κυρώσεις από τις ρυθμιστικές αρχές.

Η λύση στο πρόβλημα των διενέξεων κλειδώματος στο 1C 8.3 μπορεί να είναι η μεταφορά της διαμόρφωσης σε μια διαχειριζόμενη (μη αυτόματη) λειτουργία διαχείρισης κλειδαριάς. Εφαρμόζεται στην έκδοση 8.1, ο μηχανισμός στα χέρια των ικανών ειδικών επιλύει το πρόβλημα των συγκρούσεων κλειδώματος κατά τη διάρκεια μιας συναλλαγής στο 1C.


Αξίζει όμως να έχετε κατά νου ότι αυτή η ενέργεια θα μειώσει το επίπεδο προστασίας των δεδομένων από αλλαγές ενώ διαβάζονται από άλλους χρήστες. Επομένως, εάν δεν είστε έτοιμοι να ελέγξετε ανεξάρτητα όλες τις κλειδαριές στο σύστημα, μην βιαστείτε να αλλάξετε τις ρυθμίσεις διαμόρφωσης.

Γρήγορη λύση στη διένεξη κλειδώματος 1C

Στο έργο ενός διαχειριστή ή προγραμματιστή, μπορεί να προκύψει μια κατάσταση όταν δεν υπάρχει χρόνος για να ελέγξετε ένα σφάλμα και να αναζητήσετε τις βασικές αιτίες του προβλήματος. Για παράδειγμα, είναι απαραίτητο να υποβάλετε μια αναφορά ή να υποβάλετε δεδομένα μέχρι ένα ορισμένο χρονικό διάστημα, αλλά τα σφάλματα αποκλεισμού 1C το αποτρέπουν.

Υπάρχουν δύο τρόποι για γρήγορη επίλυση του προβλήματος:

  • Βρείτε και τερματίστε την περίοδο λειτουργίας που αποκλείει τα απαιτούμενα δεδομένα. Σε μικρές εταιρείες όπου ο αριθμός των χρηστών 1C δεν υπερβαίνει τις δεκάδες άτομα, αυτή είναι η βέλτιστη λύση.
  • Εάν ελέγχετε ένα σύστημα με εκατοντάδες υπαλλήλους, η εύρεση της σωστής συνεδρίας χωρίς εξειδικευμένο λογισμικό μπορεί να διαρκέσει πολύ. Σε αυτήν την περίπτωση, θα είναι πολύ πιο αποτελεσματικό να κάνετε επανεκκίνηση του διακομιστή.

Αυτές οι λύσεις είναι ριζικές και στοχεύουν μόνο στη γρήγορη επίλυση του προβλήματος και στην απελευθέρωση δεδομένων για επείγουσα αναφορά. Μπορεί να εξαλειφθεί μόνο με την κατανόηση του λόγου για τον οποίο προέκυψε μια σύγκρουση κλειδώματος κατά την εκτέλεση μιας συναλλαγής 1C. Μετά από τέτοιες ενέργειες, είναι απαραίτητο να βρείτε τρωτά σημεία στο σύστημα, να βελτιστοποιήσετε τη διαμόρφωση ή την εργασία των εργαζομένων. Δεν συνιστάται η χρήση τέτοιων μέτρων σε συνεχή βάση σε περίπτωση τακτικών συγκρούσεων κλειδώματος στις συναλλαγές.

Πόσο συχνά βλέπετε αυτό το μήνυμα; Νομίζω ότι όλοι όσοι έχουν μακροχρόνια εμπειρία με το 1C έχουν αντιμετωπίσει ένα τέτοιο σφάλμα τουλάχιστον μία φορά. Γιατί το πρόγραμμα παράγει ένα τέτοιο σφάλμα; "Διένεξη κλειδώματος κατά τη συναλλαγή: Απέτυχε το κλείδωμα του πίνακα";

Λοιπόν, τις περισσότερες φορές αυτό συμβαίνει λόγω του γεγονότος ότι ένας από τους χρήστες εκτελεί ήδη κάποιο είδος λειτουργίας που έχει μπλοκάρει αυτόν τον πίνακα. Για να λυθεί αυτό το πρόβλημα, όλοι οι χρήστες πρέπει απλώς να βγουν από το πρόγραμμα. Αλλά συμβαίνει επίσης ο χρήστης να βγαίνει από το πρόγραμμα, αλλά η διαδικασία του προγράμματος να μην ξεφορτώνεται από τη μνήμη. Μην πανικοβάλλεστε! Εάν όλοι οι χρήστες έχουν αποχωρήσει από το πρόγραμμα, αλλά το μήνυμα εξακολουθεί να εμφανίζεται, πρέπει να ανοίξετε το μενού Εργαλεία -> Ενεργοί χρήστες.

Και δείτε ποιος εκτός από εσάς εργάζεται αυτήν τη στιγμή με το πρόγραμμα. Εάν όλοι οι χρήστες έχουν αποσυνδεθεί και εξακολουθείτε να βλέπετε ότι υπάρχει κάποιος άλλος εκτός από εσάς, μην ανησυχείτε. Συμβαίνει. Η διαδικασία έχει κολλήσει. Επανεκκινήστε τον υπολογιστή του χρήστη που βρίσκεται σε ενεργή λειτουργία.

Αλλά μερικές φορές ακόμη και αυτό δεν λύνει το πρόβλημα. Συμβαίνει ότι τη στιγμή μιας συναλλαγής η λυχνία αναβοσβήνει ή, για παράδειγμα, ο σκληρός δίσκος βρίσκεται στα τελευταία του σκέλη. Και το επίσης πιθανό, κάποιος έβγαλε το καλώδιο του διανομέα δικτύου και άνοιξε τον βραστήρα στη θέση του και εκείνη τη στιγμή υπολόγιζες αποσβέσεις. Έτσι σε τέτοιες στιγμές η βάση δεδομένων μπορεί να καταστραφεί ή τα δεδομένα να καταγράφονται με σφάλμα.

Σε αυτήν την περίπτωση και σχεδόν πάντα, αν οι παραπάνω συνταγές δεν βοήθησαν, βοηθά το βοηθητικό πρόγραμμα chdbfl.exe. Βρίσκεται στο φάκελο με το εκτελέσιμο αρχείο 1C. Η διαδρομή προς το αρχείο θα είναι περίπου "C:\Program Files\1Cv82\platform_version_number\bin\chdbfl.exe". Λάβετε υπόψη ότι αυτό το βοηθητικό πρόγραμμα από μια έκδοση της πλατφόρμας ενδέχεται να μην λειτουργεί για άλλη.

Επομένως, πρέπει να ανοίξετε το φάκελο με τον αριθμό της τρέχουσας πλατφόρμας στην οποία εργάζεστε.

Πώς μπορώ να δω τον αριθμό πλατφόρμας; Πολύ απλό. Μεταβείτε στο μενού Εργαλεία -> Σχετικά με το πρόγραμμα. Και στη συνέχεια η εικόνα δείχνει πού να αναζητήσετε τον αριθμό της πλατφόρμας.

Επιλέξτε το πλαίσιο ελέγχου "διόρθωση σφαλμάτων που εντοπίστηκαν". Και κάντε κλικ στο κουμπί εκτέλεσης. Αυτό το βοηθητικό πρόγραμμα διορθώνει το 90% όλων των σφαλμάτων που παρουσιάζονται. Πριν χρησιμοποιήσετε αυτό το βοηθητικό πρόγραμμα, συνιστώ ανεπιφύλακτα να δημιουργήσετε ένα αντίγραφο ασφαλείας της βάσης δεδομένων, αλλά εάν παρουσιαστεί σφάλμα ακριβώς τη στιγμή της εκφόρτωσης, αντιγράψτε ολόκληρο τον φάκελο με τη βάση δεδομένων πληροφοριών.

Δεν είναι ασυνήθιστο όταν εργάζεστε σε 1C να λαμβάνετε το σφάλμα "Διένεξη κλειδώματος κατά την εκτέλεση συναλλαγών: Ο μέγιστος χρόνος αναμονής για τη χορήγηση κλειδώματος έχει ξεπεραστεί". Η ουσία του έγκειται στο γεγονός ότι πολλές συνεδρίες προσπαθούν να εκτελέσουν ταυτόχρονα παρόμοιες ενέργειες, επηρεάζοντας τον ίδιο πόρο. Σήμερα θα καταλάβουμε πώς να διορθώσετε αυτό το σφάλμα.

Εκτελέστηκε μεγάλος αριθμός επεμβάσεων

Το πρώτο βήμα κατά την αναζήτηση των λόγων είναι να διευκρινιστεί πόσοι ταυτόχρονοι χρήστες βρίσκονται στη βάση πληροφοριών στην οποία δημιουργείται ένα τέτοιο σφάλμα. Όπως γνωρίζουμε, ο μέγιστος αριθμός τους μπορεί να είναι αρκετά μεγάλος. Αυτό είναι και χίλια και πέντε χιλιάδες.

Ο μηχανισμός κλειδώματος και συναλλαγών περιγράφεται στον οδηγό προγραμματιστή. Χρησιμοποιούνται όταν πολλές συνεδρίες έχουν πρόσβαση στα ίδια δεδομένα ταυτόχρονα. Είναι λογικό ότι τα ίδια δεδομένα δεν μπορούν να αλλάξουν από διαφορετικούς χρήστες ταυτόχρονα.

Θα πρέπει επίσης να ελέγξετε εάν κάποιος από τους χρήστες εκτελεί επεξεργασία μαζικής αλλαγής δεδομένων. Αυτό θα μπορούσε να είναι όπως, τέλος μήνα και παρόμοια. Σε αυτήν την περίπτωση, μετά την ολοκλήρωση της επεξεργασίας, το σφάλμα θα εξαφανιστεί από μόνο του.

Προγραμματισμένες εργασίες

Δεν είναι ασυνήθιστο η αιτία ενός σφάλματος να βρίσκεται σε ένα σύστημα που επεξεργάζεται μεγάλες ποσότητες δεδομένων. Συνιστάται να κάνετε τέτοια πράγματα τη νύχτα. Ορίστε ένα πρόγραμμα για την εκτέλεση τέτοιων εργασιών ρουτίνας εκτός των ωρών εργασίας.

Με αυτόν τον τρόπο, οι χρήστες θα εργάζονται σε ένα σταθερό σύστημα και οι ίδιες οι εργασίες ρουτίνας θα ολοκληρωθούν με επιτυχία, καθώς η πιθανότητα διενέξεων με τις συνεδρίες χρήστη θα μειωθεί.

"Κρεμασμένες συνεδρίες"

Το πρόβλημα των «κολλημένων συνεδριών» των χρηστών είναι γνωστό σχεδόν σε όλους όσοι έχουν συναντήσει την υπηρεσία 1C. Ο χρήστης θα μπορούσε να έχει εγκαταλείψει το πρόγραμμα εδώ και πολύ καιρό ή να έχει κλείσει ένα έγγραφο, αλλά η συνεδρία του παραμένει στο σύστημα. Το πρόβλημα τις περισσότερες φορές απομονώνεται και αρκεί να τερματίσετε μια τέτοια περίοδο λειτουργίας μέσω της κονσόλας διαχειριστή. Τα ίδια προβλήματα μπορεί να προκύψουν με τις εργασίες στο παρασκήνιο.

Σύμφωνα με πολυάριθμα σχόλια στο Διαδίκτυο, τέτοιες καταστάσεις είναι πιο συχνές όταν χρησιμοποιείτε κλειδιά ασφαλείας δικτύου. Εάν η κατάσταση με το «πάγωμα συνεδριών» επαναλαμβάνεται συστηματικά, αυτό είναι ένας λόγος για να ελέγξετε και να διατηρήσετε διεξοδικά το σύστημα και τους διακομιστές (αν η βάση δεδομένων είναι πελάτης-διακομιστής).

Σφάλματα κατά την εγγραφή της διαμόρφωσης

Όλες οι τυπικές διαμορφώσεις αναπτύσσονται από εξειδικευμένους ειδικούς και ειδικούς. Κάθε σύστημα έχει δοκιμαστεί διεξοδικά και βελτιστοποιηθεί για ταχύτερη και πιο σωστή λειτουργία.

Από αυτή την άποψη, η αιτία του σφάλματος μπορεί να βρίσκεται σε μη βέλτιστο κώδικα που έχει γραφτεί από τρίτο προγραμματιστή. Αυτό θα μπορούσε να είναι ένα «βαρύ» αίτημα που θα μπλοκάρει δεδομένα για μεγάλο χρονικό διάστημα. Υπάρχουν επίσης συχνές περιπτώσεις κατασκευής αλγορίθμων με χαμηλή απόδοση και παραβίαση της λογικής.

Υπάρχει μεγάλη πιθανότητα η διένεξη κλειδώματος να προέκυψε ακριβώς λόγω σφαλμάτων προγραμματιστή, εάν προέκυψε μετά από ενημέρωση προγράμματος. Για να ελέγξετε, μπορείτε απλά να "επαναφέρετε" τις βελτιώσεις ή να αναδιαμορφώσετε τον κώδικα.

Συμπτώματα και ιστορικό ασθενών:

Η εργασία πολλών χρηστών μέσω του δικτύου με το ίδιο αρχείο (βάση δεδομένων) περιλαμβάνει μηχανισμό αποκλεισμού δικτύου. Αυτό αναγκάζει το σύστημα να σπαταλήσει πολύτιμο χρόνο για τον εντοπισμό ανοιχτών συνεδριών εγγραφής και την ανάλογη επίλυση διενέξεων.

Τα κύρια σημάδια λειτουργίας αποκλεισμού:

  • γρήγορη εργασία χρήστη με τη βάση δεδομένων μέσω του δικτύου σε αποκλειστική λειτουργία και εξαιρετικά αργή όταν πολλοί χρήστες εργάζονται ταυτόχρονα
  • γρήγορη εμπειρία χρήστη με τοπική βάση δεδομένων στον διακομιστή και αργή εργασία μέσω του δικτύου
  • Οι προσβάσεις στο σύστημα αρχείων είναι λίγο λιγότερο από 10 MB/sec

Έτσι, μου δόθηκε το καθήκον να βεβαιωθώ ότι έως και τρεις χρήστες θα μπορούσαν να εργαστούν σε 1C ταυτόχρονα! Αστείο, έτσι δεν είναι;

Ξέχασα όλα τα αστεία όταν είδα με τι έπρεπε να αντιμετωπίσω: έναν «διακομιστή» με τη μορφή ενός συνηθισμένου υπολογιστή γραφείου και δύο φορητούς υπολογιστές.

Η ευτυχία θα ήταν ελλιπής αν δεν υπήρχαν τα υπέροχα λειτουργικά συστήματα - Windows 7 στον υπολογιστή και σε έναν φορητό υπολογιστή, Windows 8 στον άλλο.

Κατά την προσπάθεια ταυτόχρονης ανάρτησης εγγράφων σε φορητούς υπολογιστές, το ένα έμεινε κολλημένο για περίπου ένα λεπτό και το δεύτερο κατέρρευσε από 1C με το κείμενο σφάλματος "δεν μπορούσε να κλειδώσει το τραπέζι...".

Η κυκλοφορία του 1C σε φορητό υπολογιστή είναι μια ξεχωριστή παράσταση που διήρκεσε περίπου 3 λεπτά!

Σε πολλούς πόρους συνάντησα συμβουλές για τη μετάβαση στην εργασία στην πρόσβαση τερματικού. Δυστυχώς, τα Windows 7 δεν σας επιτρέπουν να μετατραπείτε σε τερματικό διακομιστή χρησιμοποιώντας τυπικά εργαλεία - υπάρχει το πολύ μία ενεργή σύνδεση. Σε αυτήν την περίπτωση, οι υπόλοιπες περίοδοι σύνδεσης δεν τερματίζονται, μπορείτε να συνδεθείτε ξανά κάτω από έναν άλλο χρήστη - "αποβάλλοντας" τον προηγούμενο χρήστη, αλλά χωρίς να τερματίσετε τη συνεδρία του. Επομένως, θα πρέπει να μεταφέρετε το 1C σε ένα λειτουργικό σύστημα διακομιστή, όπου δεν υπάρχουν τέτοιοι περιορισμοί. Ο πελάτης, με δική του ευθύνη, έλυσε το πρόβλημα χρησιμοποιώντας ένα βοηθητικό πρόγραμμα τρίτου κατασκευαστή Windows7_SP1_RDPhack.

Όμως οι περιπέτειες δεν τελείωσαν εκεί. Ακόμη και στην τερματική σύνδεση υπήρξαν σημαντικές καθυστερήσεις. Για άλλη μια φορά οι παντοδύναμες μηχανές αναζήτησης με βοήθησαν. Ακολουθούν συμβουλές για την επιτάχυνση του αρχείου 1C, τις οποίες ακολούθησα:

1. Καθιστώ ανίκανοχρήση πρωτοκόλλου δικτύου IPv6, διαμορφώστε τη διευθυνσιοδότηση στο "παλιό" IPv4.

2. Προσθέστε διεργασίες 1C στις εξαιρέσεις του τείχους προστασίας των Windows, καθώς και στις εξαιρέσεις προστασίας από ιούς ή απενεργοποιήστε τις εντελώς (πιο επικίνδυνο, αλλά μια απλή δοκιμή έδειξε αύξηση ταχύτηταςεπαναμεταφορά εγγράφων όταν το Avast antivirus είναι απενεργοποιημένο παράγοντας του!)

3. Ξεκινήστε τη δημιουργία ευρετηρίου αναζήτησης πλήρους κειμένου σε 1C ή απενεργοποιήστε την εντελώς

4. Εκτελέστε τη δοκιμή και τη διόρθωση της βάσης δεδομένων, ελέγχοντας με το βοηθητικό πρόγραμμα ChDbfl

5. Εκτελέστε το στοιχείο Check Configuration στη διαμόρφωση (εάν η διαμόρφωση δεν είναι τυπική, αυτό μπορεί να είναι χρήσιμο). Με βάση τα αποτελέσματα του ελέγχου της διαμόρφωσης, μειώθηκε ως δια μαγείας σε μέγεθος σχεδόν κατά το ένα τρίτο. Δεν εμβαθύνω ακριβώς στο τι ενημέρωσαν οι εισερχόμενοι προγραμματιστές πριν από εμένα, αλλά το γεγονός είναι προφανές.

6. Απενεργοποιήστε τις περιττές λειτουργικές επιλογές.

7. Ρύθμιση δικαιωμάτων χρήστη. (Αυτή και η προηγούμενη συμβουλή φαινόταν ανόητη μέχρι που παρατήρησα την απόδοση των διαχειριζόμενων φορμών κατά το άνοιγμα μιας λίστας εγγράφων. Όσο λιγότερο περιττό σε μια διαχειριζόμενη διεπαφή, τόσο πιο γρήγορα λειτουργεί, κατά κανόνα)

8. Ξεκινήστε τον επανυπολογισμό των συνόλων και την επαναφορά της ακολουθίας (σημαντική αύξηση μπορεί να συμβεί μόνο εάν τα σύνολα δεν έχουν αποκατασταθεί για μεγάλο χρονικό διάστημα)

9. Καθορίστε "Ταχύτητα σύνδεσης - χαμηλή" στις ρυθμίσεις της λίστας βάσης δεδομένων (αυτό δεν έδωσε πολλά αποτελέσματα, εκτός από το ότι οι εικόνες των υποσυστημάτων απενεργοποιήθηκαν :))

Μετά την ολοκλήρωση όλων αυτών των βημάτων, η βάση δεδομένων αρχείων 1C άρχισε να λειτουργεί πολύ πιο γρήγορα. Άρχισε να εκκινείται σε 10 δευτερόλεπτα το πολύ και η ταχύτητα μεταφοράς εγγράφων αυξήθηκε κατά μέσο όρο 12 φορές.

Ίσως αυτό το σύντομο άρθρο θα σας φανεί χρήσιμο εάν ξαφνικά χρειαστεί να επιταχύνετε τη βάση δεδομένων αρχείων 1C.

P.S: Αλλά η εκκίνηση ενός αρχείου 1C με χρήση πρόσβασης δικτύου σε έναν κοινόχρηστο φάκελο εξακολουθεί να είναι μη ρεαλιστική, επειδή... Ακόμη και η ταχύτερη μονάδα SSD, η μνήμη RAM και ο επεξεργαστής θα αντιμετωπίσουν μπλοκαρίσματα δικτύου και η εργασία περισσότερων του ενός χρηστών θα είναι σχεδόν αδύνατη. Μιλάμε συγκεκριμένα για τη διαμόρφωση του UT 11.1. Οι μικρές διαμορφώσεις που γράφονται μόνοι σας μπορούν να λειτουργήσουν αρκετά γρήγορα ακόμα και στην έκδοση αρχείου.

Προσθήκες από σχόλιαγια δημοσίευση:

Ανασυγκρότηση δίσκουμε βάση αρχείου

Περιελιγμόςβάση δεδομένων (μπορεί να είναι χρήσιμο εάν η βάση δεδομένων είναι μεγάλη, για παράδειγμα, για αρκετά χρόνια). Η βάση δεδομένων του πελάτη ήταν αρκετά νεαρή, επομένως η μείωση δεν ήταν πρακτική.

Αναβάθμιση υλικού - ταχύτερος σκληρός δίσκος, νέος διακόπτης, επεξεργαστής κ.λπ.

Εγκατάσταση σε διακομιστή web, πρόσβαση με χρήση thin client. Εδώ οι απόψεις διίστανται. Κάποιοι λένε ότι είναι πολλές φορές πιο γρήγορος, άλλοι λένε ότι δεν σημειώνεται επιτάχυνση.



Έχετε ερωτήσεις;

Αναφέρετε ένα τυπογραφικό λάθος

Κείμενο που θα σταλεί στους συντάκτες μας: