on 2013 Jul 06 7:24 PM
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.
Hi Doug
We are using SQLA for intensive calculations (less data retrieval). Some pointers:
Use the profiler in Sybase Central to find your bottle-necks (Only profile procedures and functions)
There is an overhead in calling functions that one tends to ignore. If you have loads of functions that each performs a small task, consider moving them back into the main procedure. There are strict guidelines as to when SQLA will translate your function to an inline set of calls within the calling routine. But generally speaking, you should do well flattening your depth of functions calling functions, calling... you get the idea.
Consider materialized views. Following your performance profiling (1), see if you can replace some data retrieval from views (if any) with materialized views. It can make a huge difference in calculation performance if you reduce the fetch-time of single-row selections.
FASTFIRSTROW. If your calculation typically requires one record from a data set, consider using the FastFirstRow table hint in a query's FROM clause to set the optimization goal for a specific query without having so set the global optimisation goal settings of your database.
As Volker stated, every use-case is different, but you cannot go wrong with these steps (especially the first one). Good luck!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
FWIW, I'm quite sure for his second point, Liam is relating to the following FAQ:
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 🙂
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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 !
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
75 | |
9 | |
9 | |
8 | |
8 | |
7 | |
7 | |
6 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.