Hi Our application has a function where it will calculate various totals on employee schedules. One very large group's schedule was taking about 40 seconds to process before a defrag, dump, load, defrag was performed. After the rebuild/defrag process the user reported that the process was taking about 35 seconds. Besides making sure that there is enough memory to cache the entire database, and the rebuild/defrag process described above, what are some of the other ways to speed up sqla database processing? I realize that we may have to look at redesigning the schedule totaling function, but I want to make sure that sqla is setup for its fastest possible performance. Thanks, Doug. asked 06 Jul '13, 18:24 dejstone |
Hi Doug We are using SQLA for intensive calculations (less data retrieval). Some pointers:
As Volker stated, every use-case is different, but you cannot go wrong with these steps (especially the first one). Good luck! answered 08 Jul '13, 01:59 Liam Breck Carter FWIW, I'm quite sure for his second point, Liam is relating to the following FAQ:
(08 Jul '13, 16:11)
Volker Barth
Impressive memory Volker :-)
(09 Jul '13, 00:52)
Liam
Replies hidden
...nah, just the linked pages of this forum:)
(09 Jul '13, 01:50)
Volker Barth
...or should I have said: "Virtual memory!"?
(09 Jul '13, 06:18)
Volker Barth
|
Hi Doug, I would first make sure your database server and client run on the latest EBF patch and if possible the last release of SQL Anywhere (16). We've encountered several major performance increases when installing the latest patch (on version 11.0.1). Indexes can really speed up things. I would check which queries are executed during your 35/40s period and try to optimize them by adding specific indexes. Remember that adding indexes also has drawbacks ! answered 08 Jul '13, 09:58 MichaelMange... |
When you follow Liam's advice to use the procedure profiler, you may discover one or more slow SQL queries. If you obtain representative and meaningful plans (Graphical Plan With Statistics) for those queries, maybe you can see where to apply Michael's advice to create an index. You could also save and post the saplan files here. ...and/or run the Index Consultant. ...and/or run Database Tracing In 50 Easy Steps ( that's a last resort :) answered 09 Jul '13, 12:44 Breck Carter |
IMVHO, the re-design of complex and "slow" queries is usually much more efficient than methods to speed up the "whole database" - unless one is faced with obvious bottlenecks like way too less RAM and the like.
Besides that, in order to avoid the common answer "It depends...", I guess you will have to ask more specific questions and tell more on your options of choice. I don't think there is one and only setup for "the fastest possible performance" in general...