Sometimes it is very useful to get the DDL of an object of particular database.
We can recreate such a user from one environment to another without even knowing the password.
DDL statements can be obtained by calling the function:
object_type IN VARCHAR2,
name IN VARCHAR2,
schema IN VARCHAR2 DEFAULT NULL,
version IN VARCHAR2 DEFAULT 'COMPATIBLE',
model IN VARCHAR2 DEFAULT 'ORACLE',
transform IN VARCHAR2 DEFAULT 'DDL')
In tables where changes constantly, as a maintenance over the DB, you have to rebuild the indexes B-TREE periodically, for example (the syntax is more complex):
ALTER INDEX SCOTT.PK_EMP REBUILD;
A B-TREE ideal has branches all perfectly balanced, a B-TREE degraded can offer linear time rather than logarithmic search because of strong imbalance.
To determine if an index should be rebuilt:
Sometimes you need to perform operations on a BD when opened, for example moving datafiles or put tablespaces in read only.
These transactions generally can be performed with the BD in production, but the problem arises when we have a high activity and we have to make many changes. In these cases it is best to restrict access to users, allowing access only DBA (sys or system if we have not created any other).
We can put the database in quiesce mode (still or inactive), only SYS and SYSTEM can create new sessions, the rest remain until they complete the transaction.
To view the status of the database:
BLOBs tables with different tablespaces in the remainder of the table, have a somewhat different treatment.
We will prepare a test environment:
We create two tablespaces with:
CREATE SMALLFILE TABLESPACE "TS_PFIRMA_DATOS" LOGGING DATAFILE '/u01/app/oracle/oradata/PRUEBA/TS_PFIRMA_DATOS.dbf' SIZE 10M EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;
CREATE SMALLFILE TABLESPACE "TS_PFIRMA_BLOB" LOGGING DATAFILE '/u01/app/oracle/oradata/PRUEBA/TS_PFIRMA_BLOB.dbf' SIZE 10M EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;
Surely more than once have deleted records from a table in large quantities, perhaps millions. Once this is done it expected would be a reduction of the space used in the tablespaces, but it does not. Extensions but remain free to use the given table, can not use another table.
After the removal of millions of records, you must compact the table to return to tablespace free space once done we can even reduce the size of the datafiles without meeting the limitation imposed by the HIGH WATER MARK (maximum size reached by the objects within a datafile).
Suppose the table:
Recently following the document ID 456468.1, I made a verification of the integrity of the catalog. Anyway, they have appeared a couple of errors indicating a problem with an object identifier:
This object exist in dba_objects, the query:
Once again he repeats the story, a PathSet installed with the idea of solving problems and new ones appear (this time without document).
This time it was to install the PatchSet 10.2.0.5 on the version 10.2.0.1. The fact is that now when trying to run the SQL Access Advisor, the task is not created but an error in the alert.
It is possible that an application displays in its log an ORA-01591 error, which according to official documentation is due to a 2-phase trasacción that can not be completed.
Such transactions are used, for example, when a commit using tables obtained from a dblink becomes.It verifies that you can make a remote commits, another local and finally performs in the 2 locations atomically.
Well when connecting with a dblink is lost during a transaction, the transaction is in an uncertain state and if another session attempts to modify the objects involved see the ORA-01591 error.
Since the release of Oracle Database 11g, it has reinforced security by default. This should in principle be positive, but there are some situations where some behaviors may be unpleasant.
The most obvious example can be found in the modification of the profile (PROFILE) DEFAULT, which is applied to any user created by default.
Recently, to solve a production problem identified as a bug (solventable with Path Set 10.2.0.4) has been necessary to update BD Oracle version 10.2.0.1 to 10.2.0.5 (that matter we are going to last Patch Set).
After installing the Path Set 10.2.0.5 for Linux 64 bits, which went smoothly and update catalogs databases, everything seemed to go perfectly.
At the moment the COMPATIBLE parameter remained with the original version 10.2.0.1.
Problems occurred about a day later when a report stopped working, the alert displays: