Microsoft Dynamics Development

Re: Performance on SQL

apap — Tue, 29 Mar 2005 18:38:47 GMT

Αν μπορείς, έχω το παρακάτω email: alexandros.papaspiridis@gmail.com

σε ευχαριστώ και πάλι

Re: Performance on SQL

ArisB — Mon, 28 Mar 2005 18:55:40 GMT

Ένα mail ή καλύτερα ενα ftp site για να το ανεβάσω επειδή είναι μεγάλο.

Re: Performance on SQL

apap — Wed, 23 Mar 2005 21:56:49 GMT

καλησπέρα, όταν μπορείς στείλε το zip γιατί το password δεν παίζει
σε ευχαριστώ

Re: Performance on SQL

apap — Wed, 16 Mar 2005 14:14:42 GMT

σε ευχαριστώ πάρα πολύ. Θα το δοκιμάσω και αν υπάρχει πρόλβημα θα σε ειδοποιήσω

Re: Performance on SQL

ArisB — Tue, 15 Mar 2005 19:39:47 GMT

I'd like to ask for the status?

We have got some new Files for Version 3.70B. May be this could help in your problem.

Please see the link below.

kind regards
Richard Tupy

Hello,

The hot fix for your issue has been packaged and placed on an HTTP site for you to download.

WARNING: This fix is not publicly available through the Microsoft website as it has not gone through full Microsoft regression testing. If you would like confirmation that this fix is designed to address your specific problem, or if you would like to confirm whether there are any special compatibility or installation issues associated with this fix, you are encouraged to speak to a Support Professional in Product Support Services.

The package is password protected so be sure to enter the appropriate password for each package. To ensure the right password is provided cut and paste the password from this mail.

NOTE: Passwords expire every 7 days so download the package within that period to insure you can extract the files. If you receive two passwords it means you are receiving the fix during a password change cycle. Use the second password if you download after the indicated password change date.

Package:
-----------------------------------------------------------
KB Article Number(s): 886851, 886859, 887053, 887331, 887713, 887714, 887715, 887717, 887736, 887966, 890640
Language: All (Global)
Platform: i386
Location: (http://hotfixv4.microsoft.com/Microsoft%20Business%20Solutions–Navision%203.70/latest/KB890640/19868/free/213925_intl_i386_zip.exe)
Password: DpMp2$F
Password Changes On: 02/18/2005
Next Password: VMMpcFn

NOTE: Be sure to include all text between '(' and ')' when navigating to this hot fix location!

------------------------------------------------------------------------------
Αν δεν παίζει το password στείλε μου το mail σου για να σου στείλω το exe (zip 6 MB)!

Re: Performance on SQL

apap — Sat, 12 Mar 2005 18:29:47 GMT

Καλημέρα,
θα μπορούσες να στείλεις το Url του exe για την 3.7.Β

ευχαριστώ
αλέξανδρος παπασπυρίδης

Re: Performance on SQL

ArisB — Fri, 11 Mar 2005 20:28:22 GMT

Για το συγκεκριμένο πρόβλημα πείρα επιτελούς απάντηση από το support μετά από ένα μήνα!!!
Και το καλό είναι ότι η απάντηση λέει ότι είναι πρόβλημα το οποίο μαζί με άλλα λύνεται από το exe του πολυαναμενόμενου 3.70Β. Κατέβασα το exe μόνο από κάποιο link που μου έστειλαν (στην διάθεση σας για όποιον θέλει να το δοκιμάσει) και στον SQL κάνει convert την βάση.

Re: Performance on SQL

dionisp — Tue, 08 Feb 2005 21:46:03 GMT

Υπάρχουν θέματα με τον SQL και το Navision και ο λόγος που υπάρχουν είναι ότι η εφαρμογή δεν είχε γραφτεί για SQL αλλά για την Native. Όταν πάρθηκε η απόφαση να τρέχει και σε SQL δεν ξαναγράφτηκε για τον SQL διότι το κόστος που θα είχαν οι συνεργάτες για να κάνουν upgrade στην SQL version θα ήταν τεράστιο.

Το θέμα λοιπόν είναι ότι πολλές φορές SQL εγκαταστάσεις χρειάζονται fine tuning. Γενικότερα δεν υπάρχει κανόνας που να λέει τι πρέπει να κάνεις γιατί είναι per case, ωστόσο οι αλλαγές προκύπτουν συνήθως σε δύο σημεία:
Kώδικας: κλασσική περίπτωση το application των open items όπου στο κώδικα κάνει ένα loop με κάποιο κλειδί για να κάνει apply μια πληρωμή σε τιμολόγιά. Όταν βρει ανοιχτό τιμολόγιο κάνει modify στην εγγραφή που είχε εκείνη τη στιγμή στο loop σε πεδίο που ανήκει στο κλειδί (το "status" open αν θυμάμαι καλά). Αυτό στην Native δουλεύει μια χαρά αλλά στον SQL επειδή κάνει modify record από το rowset, καταλήγει σε table scan με αποτέλεσμα να πέφτει το performance.

Indexes: Το Navision είναι overindexed διότι χρησιμοποιεί τα indexes για να κάνει sorting κάτι το οποίο είναι ολότελα άχρηστο στον SQL. Επίσης πολλές φορές, το SIFT implementation στον SQL πρέπει να είναι διαφορετικό από ότι στην Native. Μικροί πίνακες (πχ. Reservation Entry) έχουν πάρα πολλά indexes για να υπολογίζουν sift πεδία τα οποία έχουν κόστος στο performance του SQL επειδή με κάθε καταχώρηση κάνει πάρα πολλά insert. Τέλος μερικά indexes είναι λάθος διότι η σειρά των πεδίων δεν είναι αρκετά περιοριστική για τα αποτελέσματα που γυρνάει (πχ. Indexes στα Value Entries που αρχίζουν με το "Item Ledger Entry Type" που είναι option με 6 τιμές ενώ μετά υπάρχει στο Index το "Item No.").

Hardware: υπάρχουν συγκεκριμένες οδηγίες για το hardware setup.

Maintenance: Οι περισσότεροι συνεργάτες, συνηθισμένοι από την plug & play λογική της Native, ξεχνούν ότι ο SQL θέλει maintenance.

Όλα αυτά αναλυμένα από ειδικούς (και όχι από εμένα) συν τα εργαλεία που θα σε βοηθήσουν στον εντοπισμό του προβλήματος συν κάποιες οδηγίες και μεθοδολογία για την λύση των προβλημάτων, μπορείς να τα βρεις στο partnersource. Κάνε ένα search για το Tools CD της έκδοσης 4.00 και κατέβασε το. Περιλαμβάνει το SQL Server Resource kit που είναι πολύ χρήσιμο και επίσης έχει το κλασσικό Performance troubleshooting Kit το οποίο έχει ανανεωθεί για τον SQL.

Νομίζω ότι οι πληροφορίες που θα βρεις στα εργαλεία θα σε βοηθήσουν πολύ.

Re: Performance on SQL

ArisB — Wed, 19 Jan 2005 01:20:01 GMT

Αν είναι έτσι και δεν υπάρχει άλλη λύση, τότε μην περιμένεις και πολλά από την 4.00 γιατί όταν έβαλα το post στο Support μου απάντησε ένας απιστευτός τύπος ότι πρέπει να κάνω disable τα SIFT tables (κάθε φορά που ένας χρήστης αλλάζει ένα BOM)και διάφορες άλλες ....!

Re: Performance on SQL

KelMan — Wed, 19 Jan 2005 00:21:31 GMT

Πιστεύω ότι έχει να κάνει με το implementation της database στον SQL Server...

Κι εξηγώ:

Η native database του Navision δεν είναι όπως αυτή του SQL Server (σε ότι αφορά τη σχέση των clustered / non-clustered indexes). Όταν στον SQL Server υπάρχει ένα clustered index πχ MachineNo και προσθέσεις ένα non-clustered index πχ MachineComponentΝο, τότε τo non-clustered index "κάθεται" πάνω στο clustered με αποτέλεσμα τα leaf pages του index να περιέχουν τον συνδυασμό non-clustered index key + clustered index key (MachineΝο+MachineComponentNo) για κάθε κλειδί.

Στη native database του Navision, απ' ότι έχω καταλάβει, τα indexes κρατούνται ξεχωριστά για κάθε συνδυασμό κλειδιών, δηλ, για κάθε ομάδα primary + secondary key/keys. Μάλιστα, είναι πολύ σπουδαία η κατάλληλη επιλογή κλειδιών για διαδικασίες όπως αναζήτηση εγγραφών, reporting, κλπ που πολλοί πίνακες του Navision είναι φορτωμένοι με πληθώρα εναλλακτικών συνδυασμών κλειδιών που χρησιμοποιούνται ανάλογα με το τι θες να κάνεις.

Που είναι το πρόβλημα λοιπόν; Ο τύποι που έκαναν το port της database, όρισαν το primary key σε κάθε πίνακα στον SQL Server (που από default γίνεται και clustered index) και κατόπιν όρισαν τα non-clustered indexes αλλά με χαζό (για να μην πω τίποτε άλλο) τρόπο.

Φαντάσου, κάτι σαν:

CREATE TABLE MachineComponent(
MachineComponentΝο int PRIMARY KEY,
MachineComponentNAme varchar(100),
MachineNo int FOREIGN KEY ...
...)

CREATE NONCLUSTERED INDEX x
ON MachineComponent(MachineComponentΝο, MachineNo)
CREATE NONCLUSTERED INDEX y
ON MachineComponent(MachineComponentΝο, MachineComponentName)
CREATE NONCLUSTERED INDEX z
ON MachineComponent(MachineComponentΝο, MachineComponentType, MachineComponentName)
κλπ

Κανένας άνθρωπος που ξέρει περί SQL Server δεν θα έβαζε το MachineComponentΝο μέσα στα x, y και z indexes γιατί ξέρει ότι το MachineComponentΝο "εννοείται" κατά κάποιο τρόπο αφού το non-clustered index θα πέσει πάνω στο clustered. Και φυσικά, δεν υπάρχει κανένας κανόνας που να λέει ότι θα πρέπει υποχρεωτικά το clustered index field να είναι και primary key μιας και συνήθως για clustered indexes είναι καλύτεροι υποψήφιοι κλειδιά που χρησιμοποιούνται για αναζήτηση σε ranges τιμών, για ταξινόμηση, κλπ.

Το αποτέλεσμα αυτού του λανθασμένου σχεδιασμού είναι non-clustered indexes με πολύ λιγότερα non-cluster keys ανά leaf-page (αφού το μέγεθος του κλειδιού είναι για παράδειγμα MachineComponentΝο+MachineComponentΝο+MachineNo αντί MachineComponentCode+MachineNo)
πράγμα που σημαίνει πολύ περισσότερα I/O opperations καθώς και μη αποτελεσματική αξιοποίηση των clustered indexes. Όλα αυτά μπορείς εύκολα να τα διαπιστώσεις αν εξετάσεις τα indexes σε μια SQL Server database του Navision.

Τώρα, δεν γνωρίζω για ποιόν λόγο έγινε ότι έγινε, ενδεχομένως να μπορείς να βάλεις χέρι και να αρχίζεις να αλλάζεις τα indexes στον SQL Server κατά το δοκούν... Δεν το έχω δοκιμάσει και δεν ξέρω αν θα παρουσιαστεί κάποιο πρόβλημα όπως για παράδειγμα στην περίπτωση που θα ορίσεις νέα συμπληρωματικά κλειδιά για κάθε πίνακα, μέσα από το περιβάλλον ανάπτυξης του Navision. Ελπίζω να λυθούν αυτά τα προβλήματα στην έκδοση 4 γιατί η εντύπωση που μου δημιουργήθηκε από όλη αυτήν την ιστορία είναι "Α, είναι προϊόν Microsoft, πρέπει να παίζει οπωσδήποτε με SQL Server, φτιάξτο τώρα να τρέχει και αργότερα το σενιάρουμε"!

Performance on SQL

ArisB — Tue, 18 Jan 2005 20:55:38 GMT

Έχει κάποιος άλλος παρατηρήσει πρόβλημα με το performance σε SQL Server ?

Παράδειγμα σε στην αλλαγή του Status ενός Production BOM από New σε Certified κάνει περίπου 12-18 λεπτά , ενώ σε Native Navision Client max 5sec.

To ίδιο και με την ενημέρωση του Production BOM στην καρτέλα του είδους.

Το έχω κάνει Case στο Support αλλά .....!!!!