I am looking for a way to find all previous versions of the DBMS (Oracle is used). My point is to return versions of the DBMS that ever existed on the server and time when they were renewed in the following format:
I found sys.registry$history, but not sure that this is exactly what I need.
Which functions is it better to use in this case?
DBA_REGISTRY_SQLPATCH should contain all of the information that you need.
SELECT action_time,
description,
source_version,
target_version
FROM DBA_REGISTRY_SQLPATCH
WHERE source_version <> target_version
ORDER BY action_time;
DBA_REGISTRY_PATCH was introduced in 12.1.0.2. This is the source of patching information you should use for Oracle Databases moving forwards. In 11.2 you could try selecting information from DBA_REGISTRY_HISTORY. Mike Dietrich has an article explaining all of this
Related
I am working with legacy SQL code and I am finding a lot of queries like the following:
SELECT --+rule
username,
usernotes
FROM
userinfotable
ORDER BY
username
I read the Oracle Optimizer Hints documentation, but I can't find an exact reference for a --+rule. I am thinking this rule is possibly an obsolete artifact from a code generation tool that may have been designed to replace "--+rule" with user or generated /*+ SQL */ hint code.
What do you think? Does the --+rule code [literally] in the above example actually do anything as-is? or can I just discard it?
Platform = Delphi 6 with Direct Oracle Access components, Oracle 10g2 with last supported updates. Most of the Legacy SQL code was developed when using Oracle 7 and 8.
The answer is in the referenced documentation you have given:
The following syntax shows hints contained in both styles of comments
that Oracle supports within a statement block.
{DELETE|INSERT|MERGE|SELECT|UPDATE} /*+ hint [text] [hint[text]]... */
or
{DELETE|INSERT|MERGE|SELECT|UPDATE} --+ hint [text] [hint[text]]...
The --+ hint format requires that the hint be on only one line.
So it was an allowed syntax rule for hints: but I think I have never seen it.
In Oracle SQL "rule" hint means use the Rule Based Optimizer (RBO) instead of CBO (Cost Based Optimizer): since Oracle 10 it is no more supported. So for Oracle you cannot discard it: it should be taken into account but without support ...
10.2 doc says:
Rule-based Optimization (RBO) Obsolescence
RBO as a functionality is no longer supported. RBO still exists in
Oracle 10g Release 1, but is an unsupported feature. No code changes
have been made to RBO and no bug fixes are provided. Oracle supports
only the query optimizer, and all applications running on Oracle
Database 10g Release 1 (10.1) should use that optimizer. Please review
the following Oracle Metalink desupport notice (189702.1) for RBO:
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_
database_id=NOT&p_id=189702.1
You can also access desupport notice 189702.1 and related notices by
searching for "desupport of RBO" at:
http://metalink.oracle.com
Notice 189702.1 provides details about the desupport of RBO and the
migration of applications based on RBO to query optimization.
Some consequences of the desupport of RBO are:
CHOOSE and RULE are no longer supported as OPTIMIZER_MODE initialization parameter values and a warning is displayed in the
alert log if the value is set to RULE or CHOOSE. The functionalities
of those parameter values still exist but will be removed in a future
release. See "OPTIMIZER_MODE Initialization Parameter" for information
optimizer mode parameters.
ALL_ROWS is the default value for the OPTIMIZER_MODE initialization parameter.
The CHOOSE and RULE optimizer hints are no longer supported. The functionalities of those hints still exist but will be removed in a
future release.
Existing applications that previously relied on rule-based optimization (RBO) need to be moved to query optimization.
Where's the best place to store the version of a table in Oracle? Is it possible to store the version in the table itself, e. g. similar to the comment assigned to a table?
I don't think you can store that information in Oracle, except maybe in a comment on the table, but that would be error prone.
But personally I think you shouldn't want to keep track of versions of tables. After all, to get from a version 1 to a version 2, you may need to modify data as well, or other objects like triggers and procedures that use to new version of the table.
So in a way, it's better to version the entire database, so you can 'combine' multiple changes in one atomic version number.
There are different approaches to this, and different tools that can help you with that. I think Oracle even has some built-in feature, but with Oracle, that means that you will be charged gold bars if you use it, so I won't get into that, and just describe the two that I have tried:
Been there, done that: saving schema structure in Git
At some point we wanted to save our database changes in GitHub, where our other source is too.
We've been using Red Gate Source Control for Oracle (and Schema Compare, a similar tool), and have been looking into other similar tools as well. These tools use version control like Git to keep the latest structure of the database, and it can help you get your changes from your development database to scripts folder or VCS, and it can generate migration scripts for you.
Personally I'm not a big fan, because those tools and scripts focus only on the structure of the database (like you would with versioning individual tables). You'd still need to know how to get from version 1 to version 2, and sometimes only adding a column isn't enough; you need to migrate your data too. This isn't covered properly by tools like this.
In addition, I thought they were overall quite expensive for the work that they do, they don't work as easy as promised on the box, and you'd need different tools for different databases.
Working with migrations
A better solution would be to have migration script. You just make a script to get your database from version 1 to version 2, and another script to get it from version 2 to version 3. These migrations can be about table structure, object modifications, or even just data, it doesn't matter. All you need to do is remember which script was executed last, and execute all versions after that.
Executing migrations can be done by hand, or you can simply script it. But there are tools for this as well. One of them is Flyway, a free tool (paid pro support should you need it) that does exactly this. You can feed it SQL scripts from a folder, which are sorted and executed in order. Each script is a 'version'. Meta data about the process is stored in a separate table in your database. The whole process is described in more detail on Flyway's website.
The advantage of this tool is that it's really simple and flexible, because you just write the migration scripts yourself. All the tool does is execute them and keep track of it. And it can do it for all kinds of databases, so you can introduce the same flow for each database you have.
One way is to define a comment on the table:
comment on table your_table is 'some comment';
Then you can read that meta information using all_tab_comments table.
See
How to get table comments via SQL in Oracle?
For further reading, see:
https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_4009.htm
I found this document on the official ORACLE page while searching for information on Computed/Automatic/Virtual Columns:
http://www.oracle.com/technetwork/database/rdb/automatic-columns-132042.pdf
(Title: "Guide to Using SQL: Computed and Automatic Columns. A feature of Oracle Rdb")
Can anyone tell of these features really exist in ORACLE (I'm using version 10g, the document says Computed/Automatic is there since 7.1)?
I can't get any of the examples to work. Also the SQL formatting and syntax highlighting with ORACLE SQL Developer (v 3.0.04) does not work on these statements.
The document does not state that it is a tech-preview or something like that and according to the last page it has been around since May 2002.
For me it reads like a very early preview of 11g's VIRTUAL COLUMNS. What do you think?
Thanks,
Blama
You're reading the documentation of another product: Rdb (this is not Oracle Database Server)!
Is there a way to mandate table/column comments in Oracle 11g.
Some Database parameters or something of that sort.
Probably not, no.
Presumably, when you're creating objects, you do so by giving the DBA a script to run in each environment. Just as the DBA would do things like examine the naming conventions of the tables and columns that you create, the DBA should be enforcing whatever other standards you have such as requiring comments on objects.
You could run a report of objects and/or columns that don't have comments and instruct the developers to correct the problems.
If you really want a technical solution, you may be able to hack something together. For example, you could create a DDL trigger that fired when a new object was created. The trigger could use the DBMS_JOB package to create a job that will run a few minutes later and check whether comments have been added. Assuming that comments were missing, you could take whatever action you deem appropriate-- that could include dropping the object if you really wanted to. I would strongly suggest a process solution instead but you could build a technical solution.
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.