Drop Down MenusCSS Drop Down MenuPure CSS Dropdown Menu

Thursday, July 21, 2022

12c-asm-new-features:

 12c Database : ASM Enhancements : Password files in ASM Disk group

ASM version 11.2 allowed ASM spfile to be placed in a disk group.

In 12c we can also put ASM password file in an ASM disk group.

ASM : ASMCMD in 12c:

New ASMCMD commands, now ASMCMD has the ability to do password file management, patches on asm instances, and version

pwcopy Copies a password file to the specified location. pwcreate Creates a password file at the specified location. pwdelete Deletes a password file at the specified location. pwget Returns the location of the password file. pwmove […]

12c Database : ASM Enhancements : OCR backup to disk group

Oracle Cluster Registry (OCR) backup in ASM disk group

Before to 12c the ocr backup is located in the master node local disk at GRID_HOME/cdata/backup, but if OCR is corrupted and you have to restore you will need to find the master node and initiate the restore option.

Storing the OCR backup in an […]

Tuesday, July 12, 2022

Oracle RAC VIP and SCAN IPs

 VIPs:

A VIP is a Virtual IP address, and should be defined in DNS and not assigned to any host or interface.When you install GRID/ASM home, you'll specify the VIP names that were assigned in DNS. When Oracle Clusterware starts up, it will assign a VIP to each node in the cluster. The idea is, if a node goes down (crashes), clusterware can immediately re-assign that VIP to a new (surviving) node. This way, you avoid TCP timeout issues.

SCAN:

A SCAN (Single Client Access Name) is a special case of VIP. The SCAN should also be defined in DNS, and not assigned to any host or interface. There should be three IPs associated with the SCAN name in DNS, and the DNS entry should be defined so that one of the three IPs is returned each time DNS is queried, in a round robin fashion.

At clusterware startup time, each of the three VIPs that make up the SCAN will be assigned to a different node in the cluster. (Except in the special case of a two node cluster, one of the nodes wil have a 2 SCAN VIPs assigned to it.) The point of the SCAN, is that no matter how many nodes are added to or removed from the cluster, all the Net Service Name definitions in your tnsnames.ora (or LDAP equivalent) will not need to ever change, because they all refer to the SCAN, which doesn't change, regardless of how many node additions or drops are made to the cluster.


For example, in the three node cluster, you may have:


Physical and virtual hostnames/IPs assigned as follows:


Hostname    Physical IP    Virtual hostnmae   Virtual IP

rac1        10.1.1.1       rac1-vip           10.1.1.4

rac2        10.1.1.2       rac2-vip           10.1.1.5

rac3        10.1.1.3       rac3-vip           10.1.1.6

Additionally, you may have the SCAN defined as: rac-scan with three IPs, 10.1.1.7, 10.1.1.8, 10.1.1.9. Again, the DNS definition would be defined so those IPs are served up in a round robin order.

Note that the SCAN VIPs, Host VIPs, and the Physical IPs are all in the same subnet.

Finally, though you didn't ask about it, to complete the picture, you'd also need one private, non-routable IP assigned per host, and that IP would be associated with the private interconnect. So, you may have something like:

rac1-priv  172.16.1.1

rac2-priv  172.16.1.2

rac3-priv  172.16.1.3

Note that the '-priv' addresses should not be in DNS, only in the /etc/hosts file of each host in the RAC cluster. (They are private, non-routable, and only clusterware will ever know about or use those addresses, so adding to DNS doesn't make sense.)

Note also, that '-priv' and physical IP/hostname definitions should go in /etc/hosts, and the physical IPs and VIPs should be in DNS. So, physical IPs in both DNS and /etc/hosts, VIPs only in DNS, '-priv' addresses only in /etc/hosts.


https://stackoverflow.com/questions/30219464/oracle-rac-vip-and-scan-ips

http://oracledbadmins.blogspot.com/2016/06/f.html


Friday, July 1, 2022

FORCE LOGGING Mode in Oracle:

 Force = even if someone says nologging, then we will log the *normal* redo information

=In Force logging mode Oracle database must write the redo records even when NOLOGGING is used with DDL Statements.

=It will force the write of REDO records even when no-logging is specified.

=If we write the NOLOGGING option with DDLs command then our database will not generate redo for that DDLs but in case of Dataguard or media recovery has negative impact of it. So before implement Dataguard or standby server we need to enable the FORCE LOGGING mode of the Oracle Database.So every changes should be recorded and updated in standby server while syncing.

  • Force Logging is enable at tablespace and database level.
  • Force logging option is by default there for undo tablespace.
  • Force logging is not applicable for TEMP tablespace.

Suplemental = we log *more* than the normal redo information into the redo logs so that GG has more to work with.

NOLOGGING can be used to minimize the amount of redo generated by Oracle. Only the following operations can make use of nologging:

SQL*Loader in direct mode

INSERT /*+APPEND*/ ...

CTAS

ALTER TABLE statements (move/add/split/merge partitions)

CREATE INDEX

ALTER INDEX statements (move/add/split/merge partitions)

starting with 18c you have 2 more possibilities 

STANDBY NOLOGGING FOR LOAD PERFORMANCE
STANDBY NOLOGGING FOR DATA AVAILABILITY