When you write rather complex SQL for Oracle, sooner or later you will have to apply the odd execution hint because Oracle can't seem to figure out the "best" execution plan itself.
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/hintsref.htm
Now this is certainly not a SQL standard. But still, I'm wondering, are there any other RDBMS that support these kinds of hints, and I really mean hints that are "embedded" in SQL? Are they similar, syntactically (i.e. also placed between the SELECTkeyword and the first selected COLUMN)? Do you know of a general documentation page comparing hints in various RDBMS?
N.B: I'm mostly interested in these RDBMS: Postgres, MySQL, HSQLDB, H2, Derby, SQLite, DB2, Sybase, SQL Server
I know that in db2 the plans are made fixed in some way, not how. In Oracle 11g there are other options besides adding hints to queries. These are SQLProfiles and SQLPlan Baselines, both very powerful. I just finished a performance tuning project where we did not add even a single hint to the code, on the contrary.
You can add Oprimizer Hints to any SQL Server Query
The PLAN clause allows you to define a particular plan to your query in Firebird.
AFAIK, nothing standard nor close to it, but in general, you can do this in a lot of RDBM's, but not all.
I'd also remind you, if you are making some sort of comparison with other DB platforms, that hints in Oracle are entirely non-binding. Which is to say that Oracle is free to disregard your hint if it so chooses.
Hints can be helpfull but I find that I rarely use them anymore - at least not compared to the past when I was working with the older optimizers in earlier Oracle versions. Back then hints were much more of a staple to performance tuning than they are now.
Related
Is there anybody knows that anything is not supported by Greenplum Legacy Query optimizer, but supported by Pivotal Query Optimizer?
Thanks a lot!
PQO generate plans that do a better job with partition elimination, and optimizing query common table expressions (WITH Clause). As far SQL support is concerned, Legacy Query Optimizer handles all SQL that GPDB supports. If PQO sees an operation that it does not support, it automatically falls to planner.
I'm working on a very large query, in a inherited application. This is a large insert-query, that takes 4 tables with well over a million records. I know, I would also rather have this in SQL-server, but there is no infrastructure at this customer to do this :-)
This query has worked for over a year. However, the source-tables keep on growing, and last week it threw the dreaded 'out of system resources'-error. Bummer...!
I think it is possible to optimize this query. Working in MySQL, I would use the explain-command, to see where optimalisation might occur. Is there a equivalent of this in Access? I cannot seem to find it....
kind regards,
Paul
Probably Jet ShowPlan is closest to what you want. You will have to set a registry key. Then query plan information gets dumped to a text file named SHOWPLAN.OUT. You can read about the details in this article on TechRepublic: Use Microsoft Jet's ShowPlan to write more efficient queries
Also try the Performance Analyzer wizard. You can ask it to examine your query alone, or also ask it to examine table or other queries used by that query.
If you haven't compacted the database recently, see whether that improves performance. Compacting also updates index statistics which allows the engine to make better decisions for the query plan.
We are planning a new system for a client in ORACLE 11g. I've been mostly in the Sql Server world for several years, and am not really current on the latest ORACLE updates.
One particular feature I'm wondering if ORACLE has added in by this point is some sort of logical "container" for database objects, akin to Sql Server's SCHEMA.
Trying to use ORACLE's schemas like Sql Server winds up being a disaster for code comparisons when trying to push from dev > test > live.
Packages are sort of similar, except that you can't put tables into a package (so they really only work for logical code grouping).
The only other option I am aware of is the archaic practice of having to prefix object names with a "schema" prefix, i.e. RPT_REPORTS, RPT_PARAMETERS, RPT_LOGS, RPT_USERS, RPT_RUN_REPORT(), with the prefix RPT_ denoting that these are all the objects dealing with our reporting engine say. Writing a system like this feels like we never left the 8.3 file-naming age.
Is there by this point in time any cleaner, more direct way of logically grouping related objects together in ORACLE?
Oracle's logical container for database objects IS the schema. I don't know how much "cleaner" and "more direct" you can get! You are going to have to do a paradigm shift here. Don't try to think in SQL Server terms, and force a solution that looks like SQL Server on Oracle. Get familiar with what Oracle does and approach your problems from that perspective. There should be no problem pushing from dev to test to production in Oracle if you know what you're doing.
It seems you have a bit of a chip on your shoulder about Oracle when you use terms like "archaic practice". I would suggest you make friends with Oracle's very rich and powerful feature set by doing some reading, since you're apparently already committed to Oracle for this project. In particular, pick up a copy of "Effective Oracle By Design" by Tom Kyte. Once you've read that, have a look at "Expert Oracle Database Architecture" by the same author for a more in-depth look at how Oracle works. You owe it to your customer to know how to use the tool you've been handed. Who knows? You might even start to like it. Think of it as another tool in your toolchest. You're not married to SQL Server and you're not being unfaithful by using Oracle ;-)
EDIT:
In response to questions by OP:
I'm not sure why that is a logistical problem. They can be thought of as separate databases, but physically they are not. And no, you do not need a separate data file for each schema. A single datafile is often used for all schemas.
If you want a "nice, self-contained database" ala SQL Server, just create one schema to store all your objects. End of problem. You can create other users/schemas, just don't give them the ability to create objects.
There are tools to compare objects and data, as in the PL/SQL Developer compare. Typically in Oracle you want to compare schemas, not entire databases. I'm not sure why it is you want to have multiple schemas each with their own objects anyway. What does is buy you to do that? Keep your objects (tables, triggers, code, views, etc.) in one schema.
I want to how to do following general step:
where to find slow SQL
how to debug SQL (including functions)
how to create index properly
when using "update statistics", when should I use HIGH or LOW, and why?
I am going to write a paper about this topic; any help is welcomed.
One place to start is, funnily enough, the Informix Performance Tuning Guide, one section of the Informix 11.70 Information Centre. In particular, it explains most of what you need to know about UPDATE STATISTICS, and also about automatic update statistics.
For question 3, at one level, there isn't much to it - you follow the syntax from the manuals and it works. I'm guessing though that you're more concerned with whether you should create an index on a table; this would in part follow on from questions 1 and 2.
There are a variety of ways to find slow SQL. If you have OAT (OpenAdmin Tool), then it has ways to report the slowest queries. Alternatively, you can look to SET EXPLAIN.
If you have Informix 11.70, then there is a built-in SPL (stored procedure language) debugging facility. For earlier versions, Server Studio and Sentinel has some support. You can also look at the built-in TRACE facility and the related SET DEBUG FILE statement, but they tend to be tricky to interpret, and don't really give you performance information (more a question of correct vs incorrect functioning).
I have some ad-hoc reporting users hitting some SQL Server views. Occasionally the read locks taken by these users for particularly lengthy queries causes trouble elsewhere in the system.
I am considering adding some strategic with(nolock) hints to the views but wanted to know if there are any gotchas associated with hints in views.
Please ignore the obvious issues with letting users run queries this close to the SQL metal :).
Also, I know that nolock hints are an advanced feature not to be used lightly and I am well aware that they introduce fun things like dirty reads. Finally, if you're thinking that read_committed_snapshot makes sense here, I must sadly say that it's not available for 2000.
There is a potential for the report to show an inconsistent view of data. That kind of thing is rare, though.
Still, a better strategy is to use replication to create a completely separate reports database.