I got this SQL tuning tool from www.SQLFast.com
It looks fantastic! I used it analyze a very complex query (more than 1000 lines in a single SQL). It automatically analyzed the SQL and helped find out the root cause. I ever tuned such complex query, which took me 10+ hour for troubleshooting.
The question is, I cannot restructure this query. This tool declares it can reuse the tuned SQL outline data and create a SQL profile based on it. How can I do it? The example is not clear enough...
Can anybody help?
You need to run the tuned SQL first, then go to the right-bottom (underneath the execution plan), click "Plan Outline", then click "Edit". Then you will be able to edit the outline data and apply the outline data to the selected SQL.
Related
I am trying to connect Tableau to a SQL view I made in PostgreSQL.
This view returns ~80k rows with 12 fields. On my local PostgreSQL database, it take 7 seconds to execute. But when I try to create a chart in a worksheet using this view, it take forever to display something (more than 2 minutes to add just a field).
This views in complex and involve many join, coalesce and case due to business specifities.
Do you guys have an idea to improve?
Thank you very much for your help ! :-)
Best,
Max
Tableau documentation has helpful info for performance optimization
https://help.tableau.com/current/pro/desktop/en-us/performance_tips.htm
I highly recommend the whitepaper on designing efficient dashboards mentioned on that site - a bit dated, but timeless advice
For starters, learn to use the Performance Recorder in Tableau to find out what tasks are causing delays, and if they involve queries, to capture the SQL that Tableau emits.
With Tableau, and many other client tools, the standard first approach is to see what SQL the client tool generates, then execute that SQL without using the client tool, say just in psql in your case. If you can reproduce the slow query just in SQL, then you are better positioned to either
Optimize your database, say either with indices, or restructuring your schema OR
Understand why your client tool, Tableau in this case, generated that inefficient query and reason about what you could differently in Tableau that would cause it to generate different SQL
The whitepaper I mentioned should be helpful
Does using 'custom SQL' instead of joins in Tableau increase the performance of extract refresh on the server? Can someone explain it briefly?
The answer to almost every performance question is first, "it depends" and second, test and understand the measurement results. Real results carry more weight than advice from anyone on the Internet (from me or anyone else)
Still, custom SQL is usually not helpful for increasing performance in Tableau, and often hurts. It is usually much better to define your relationships in Tableau and let Tableau then generate optimized SQL for each view -- just as you let a compiler generate optimized machine code.
When you use custom SQL, you prevent Tableau from optimizing the SQL it generates. It has to run the SQL you provide in a subquery.
The best use case for custom SQL in Tableau is to access database specific features, or possibly windowing queries. Most other SQL functionality is available by using the corresponding Tableau features.
If you do have a complex slow custom SQL query that you must use, it is usually a good idea to make an extract so you only pay the performance cost during extract refresh.
So in your case, I'd focus effort on streamlining or eliminating the custom SQL, monitoring the query plan for the generated SQL, and indexing your database to best support that query.
We have our data marts/warehouse on Oracle 11g implemented as a star schema. Business reports are designed using OBIEE. I come from a ETL background and have very little knowledge in OBIEE.
Once the OBIEE RPD is designed, I see that OBIEE starts generating SELECT queries in the background to feed data into the reports. On many occasions, I have noticed that the SELECT queries are not optimized (big fact table is fully scanned more than once in separate WITH clauses).
When the report performance is bad, the OBIEE queries are sent to the ETL team for performance tuning. I'm confused about how I can tune them because they are auto generated. I know there is an option to write custom sql in OBIEE (without going via RPD) for each report, but our standards do not allow that and I also think it does not leverage the benefits of OBIEE.
Has anyone faced a problem like above? How to tune such queries?
Firstly, you're right that custom SQL (known as direct database query) is not a good idea in principle, though it is useful on occasion. But it's not the solution to your problem.
Tuning the OBI queries generated is an OBI RPD task, for the OBI developer; tuning the database for the OBI queries generated is a database/ETL task. But you can't really do one without the other – OBI needs to be designed so as to generate suitable queries, and the database needs to be designed in such a way that suitable good queries can be generated to answer the question being asked.
OBI is basically a SQL generator, and if the RPD model is bad suboptimal, then the resulting query will be bad suboptimal. OBI will generate SQL based on the information it has in the RPD about the layout and structure of the data and database.
You're obviously coming at it from the database side, and so to you the SQL is bad because it isn't what you'd write. It's also possible that the database design is bad for getting an answer to the question that OBI is being asked.
As jackohug says, OBIEE is a SQL generator, and the general aproach is to try to optimize the query generated by OBIEE, not try to change this query. Somehow, depending on the performance problem, you can try some tricks.
First all, is your table partioned and your reports can benefit from the partioning?
Second, add indexes on the fact table so any filter on the dimensions can benefit the access to the fact table.
Third, building agregate tables, resuming the fact table, so when reports don't show much detail you first access to the agregate table with much less data, and is only as the users drill down through structure (and while doing so, they are applying filters to the data they are interested in) that they access to the much detailed fact table but applying filters to avoid full scans.
You could also tell OBIEE to use hints when accessing to the table, although, as with Direct Database Query I wouldn't recommend it, I would try first optimizing using the first three aproaches.
Regards
if you have diagnostics and tuning pack licenses, you can run the SQL Tuning Advisor. The SQL Tuning Advisor is running the optimizer in tuning mode and it may be able to generate a SQL Profile with a better execution plan. Sometimes the advisor recommends indexes for tuning as well. Both SQL Profiles and indexes do not require a change to the application.
I've yet to have much success with the SQL tuning advisor. Some experience in SQL tuning and a bit of research can typically produce a far better plan.
If all the layers are built well and all you need is a final tweak then add a hidden column to the start of the report (Answer/Analysis) with a SQL hint.
I'd be very careful about adding hints through the RPD layers because of the many different and unexpected ways that others will join and use the tables.
I am very new to SQL queries and developing a report using the SQL Server 2008. I was trying to find ways to optimize my query and came across something called as SQL Hints. I researched some sites and it said it overwrites the existing optimizing policy which SQL decides for the query.
I would like to know if the same will work for a view? Because I am using views to extract data.
Please guide.
Since view is a saved query, query hints also apply to the query behind view. My humble guess is that you don't have to use hints to optimize your query, look around indexes and ensure your query uses sargs for optimization.
Let´s be frank, my knowledge regarding SQL language is very low.
Nevertheless, my boss gave me the task to build a database application using the following tools: SQL Server and Visual Studio 2008; C#. I use the VS DataSet as a local mirror of the SQL Server.
And let´s be frank again, my understanding of the VS Query builder is also very small, I´m finding it quite confusing, actually. So no help to find from Query builder.
And my knowledge of Linq is even lower...
Perhaps I should mention that the deadline for the project is "aggressively" set, so I have no chance to learn enough about these things during the project. And I´m a bit stupid too, which is no help when it comes to challenges like this (on other occations it might be quite useful though)
With these permissions, what should I do (except for killing myself or retire) to be able to query my tables in a sufficient way?
Start learning. Look for another job at the same time. Obviously your boss is an idiot - giving you tasks to be not qualified for (or the story is a little different - would not be the first "specialist" trying to find employment that is clueless).
Sorry, I really dont know what else to say here - if yo do not know how to do your job, learn. If that does not work, then you can not do your task. Simple like that.
SQL Query takes a day to get started (on a beginner level). If you do not have this time - get your boss hire someone who has the knowledge.
keep a c# reference book handy. Also a book on sql or you can use sql books online. You can always google for your specific problem or use a forum to get answers. Be optimistic, quit whining and get to your task. All the best.
what type of task you want to do in SQL ? define in Detail.
and start working on the sql it's easy to understand.
there is a visual query designer in visual studio. that might be helpful. Open up server explorer, right click and existing database connection or create a new one and then right click to select 'New Query'.
In the query designer, you can add table and visually add conditions for joins, aggregates etc. and see the query being formed.
Use MS Access:
Start up Access, create a new DB.
Import your SQL Server DB to your new Access DB.
Select Create tab -> Query Wizard -> Simple Query Wizard (and it IS simple to use).
When the query is created, you can use the SQL code in your original SQL Server based application - but as SQL Server and Access aren´t 100% aligned, you might need to do some adjustments - google it up. Here is however a good page that will help you out.
Bonus is that it´s a good way to learn SQL "on the fly".