Sunday, June 17, 2018

HISTOGRAMS

Nice article explained about Histograms-

HISTOGRAMS


1.What Are Histograms?
Histograms are additional, “special” column statistics.
These statistics have information about the data distribution in the column.
The values of the column that has histograms are sorted into buckets. These buckets are statistic buckets, as the data itself on the disk is not sorted.
Based on the number of distinct values in the column, the database will pick one of the four types of histograms (as of 12c and up):
-Frequency Histograms
-Top Frequency Histograms
-Height-Balanced Histograms (legacy)
-Hybrid Histograms
These histogram types, will be discussed in a future blog post.
2.Why Do We Need Histograms?

Without histograms, the optimizer assumes the data is distributed uniformly in the column. How would that look like?
Lets take for example table A that has 100 rows, with 4 distinct values for the column color:
red, blue, green, yellow.
Without histograms, the optimizer assumes that there are 25 rows with color red, 25 rows with color blue, 25 rows with color green, 25 rows with color yellow.
Why is this a bad assumption?
What if there is only one row with color red, 1 row with color blue, and 1 row with color green, and then there are 97 rows of color yellow.
In this case the data distribution is not uniform. We can say that the data is skewed. If the data is skewed, then the optimizer might (and most likely will) generate inaccurate cardinality estimates, which can lead to sub-optimal execution plans.
Histograms could make the difference in the optimizer picking an execution plan with a full table scan or an execution plan with an index scan.
3.When Are Histograms Created?
If you gather stats on a table using dbms_stats, with the METHOD_OPT set to SIZE AUTO (which is the default), then the database will create histograms automatically if needed.
How does the database know that histograms are needed?
After you gathered stats on the table, and ran some select statements, the following dictionary table: SYS.COL_USAGE$ is updated, with information about previous 

predicates used in queries.
Then you gather stats again. Now the database will check SYS.COL_USAGE$, to see which columns will need histograms. If needed, it will gather histograms.
If you enjoyed this article, and would like to learn more about databases, please sign up below, and you will receive



Monday, June 4, 2018

How to restore archive logs to an alternative location when they already reside on disk (Doc ID 399894.1)

SYMPTOMS

When attempting to restore archive logs that are already located on disk using RMAN the following message will be raised:
restore not done; all files readonly, offline, or already restored

CAUSE

The message above is correct however if the archivelogs are stored within ASM you are not able to use the os copy or move command to retrieve them.

RMAN> run {
2> set archivelog destination to '/tmp';
3> restore archivelog from logseq=60 until logseq=65;
4> }

executing command: SET ARCHIVELOG DESTINATION
using target database controlfile instead of recovery catalog

Starting restore at 2006/11/17 08:51:01
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=147 devtype=DISK

archive log thread 1 sequence 60 is already on disk as file +DGROUP2/rman/archivelog/2006_11_17/thread_1_seq_60.267.606732487
archive log thread 1 sequence 61 is already on disk as file +DGROUP2/rman/archivelog/2006_11_17/thread_1_seq_61.263.606732499
archive log thread 1 sequence 62 is already on disk as file +DGROUP2/rman/archivelog/2006_11_17/thread_1_seq_62.265.606732505
archive log thread 1 sequence 63 is already on disk as file +DGROUP2/rman/archivelog/2006_11_17/thread_1_seq_63.278.606732509
archive log thread 1 sequence 64 is already on disk as file +DGROUP2/rman/archivelog/2006_11_17/thread_1_seq_64.277.606732509
archive log thread 1 sequence 65 is already on disk as file +DGROUP2/rman/archivelog/2006_11_17/thread_1_seq_65.276.606732521
restore not done; all files readonly, offline, or already restored
Finished restore at 2006/11/17 08:51:02

SOLUTION


There are three potential solutions:

1) Use the RMAN copy command
RMAN> copy archivelog '+DGROUP2/rman/archivelog/2006_11_17/thread_1_seq_60.267.606732487' to '/tmp/archive_seq_60.arc';
If there are only a few archivelogs required then the copy command can be repeated for each log. However if there are multiple archive logs below solutions may be preferable.
2) Try to use the FORCE clause in the restore command to restore the archivelog to an alternate location even when the archvie already exists on disk:
RMAN> run {
2> set archivelog destination to '/tmp';
3> restore FORCE archivelog from logseq=60 until logseq=65;
4> }
3)  Use the RMAN uncatalog command.
RMAN> change archivelog from logseq=60 until logseq=65 uncatalog;

uncataloged archive log
archive log filename=+DGROUP2/rman/archivelog/2006_11_17/thread_1_seq_60.267.606732487 recid=64 stamp=606732490
uncataloged archive log
archive log filename=+DGROUP2/rman/archivelog/2006_11_17/thread_1_seq_61.263.606732499 recid=65 stamp=606732500
uncataloged archive log
archive log filename=+DGROUP2/rman/archivelog/2006_11_17/thread_1_seq_62.265.606732505 recid=66 stamp=606732507
uncataloged archive log
archive log filename=+DGROUP2/rman/archivelog/2006_11_17/thread_1_seq_63.278.606732509 recid=67 stamp=606732508
uncataloged archive log
archive log filename=+DGROUP2/rman/archivelog/2006_11_17/thread_1_seq_64.277.606732509 recid=68 stamp=606732511
uncataloged archive log
archive log filename=+DGROUP2/rman/archivelog/2006_11_17/thread_1_seq_65.276.606732521 recid=69 stamp=606732523
Uncataloged 6 objects
Once the archivelogs have been successfully uncataloged you are able to successfully restore the archive logs to new location.

RMAN> run {
2> set archivelog destination to '/tmp';
3> restore archivelog from logseq=60 until logseq=65;
4> }

executing command: SET ARCHIVELOG DESTINATION

Starting restore at 2006/11/17 08:57:06
using channel ORA_DISK_1

channel ORA_DISK_1: starting archive log restore to user-specified destination
archive log destination=/tmp
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=60
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=61
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=62
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=63
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=64
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=65
channel ORA_DISK_1: restored backup piece 1
piece handle=+DGROUP2/rman/backupset/2006_11_17/annnf0_tag20061117t084948_0.275.606732589 tag=TAG20061117T084948
channel ORA_DISK_1: restore complete
Finished restore at 2006/11/17 08:57:08
 Following the successul restore of the archivelogs you can then continue to recatalog the archivelogs back into the ASM diskgroup. Below is an example of cataloging one archivelog.
RMAN> catalog archivelog '+DGROUP2/rman/archivelog/2006_11_17/thread_1_seq_60.267.606732487';

cataloged archive log
archive log filename=+DGROUP2/rman/archivelog/2006_11_17/thread_1_seq_60.267.606732487 recid=76 stamp=606733388

Sunday, June 3, 2018

SETUP/CONFIGURE THE POSTGRESQL STREAMING REPLICATION

POSTGRES REPLICATION

----------------------------------------------


SETUP AND CONFIGURE REPLICATION POSTGRES