Wednesday, September 26, 2012

Nonclustered Index Structures

Visit the Below Website to access unlimited exam questions for all IT vendors and Get Oracle Certifications for FREE
http://www.free-online-exams.com

Nonclustered indexes have the same B-tree structure as clustered indexes, except for the following significant differences:

  • The data rows of the underlying table are not sorted and stored in order based on their nonclustered keys.
  • The leaf layer of a nonclustered index is made up of index pages instead of data pages.

Nonclustered indexes can be defined on a table or view with a clustered index or a heap. Each index row in the nonclustered index contains the nonclustered key value and a row locator. This locator points to the data row in the clustered index or heap having the key value.

The row locators in nonclustered index rows are either a pointer to a row or are a clustered index key for a row, as described in the following:

  • If the table is a heap, which means it does not have a clustered index, the row locator is a pointer to the row. The pointer is built from the file identifier (ID), page number, and number of the row on the page. The whole pointer is known as a Row ID (RID).
  • If the table has a clustered index, or the index is on an indexed view, the row locator is the clustered index key for the row. If the clustered index is not a unique index, SQL Server makes any duplicate keys unique by adding an internally generated value called a uniqueifier. This four-byte value is not visible to users. It is only added when required to make the clustered key unique for use in nonclustered indexes. SQL Server retrieves the data row by searching the clustered index using the clustered index key stored in the leaf row of the nonclustered index.

Nonclustered indexes have one row in sys.partitions with index_id >0 for each partition used by the index. By default, a nonclustered index has a single partition. When a nonclustered index has multiple partitions, each partition has a B-tree structure that contains the index rows for that specific partition. For example, if a nonclustered index has four partitions, there are four B-tree structures, with one in each partition.

Depending on the data types in the nonclustered index, each nonclustered index structure will have one or more allocation units in which to store and manage the data for a specific partition. At a minimum, each nonclustered index will have one IN_ROW_DATA allocation unit per partition that stores the index B-tree pages. The nonclustered index will also have one LOB_DATA allocation unit per partition if it contains large object (LOB) columns . Additionally, it will have one ROW_OVERFLOW_DATA allocation unit per partition if it contains variable length columns that exceed the 8,060 byte row size limit. For more information about allocation units, see Table and Index Organization. The page collections for the B-tree are anchored by root_page pointers in thesys.system_internals_allocation_units system view.


Get Oracle Certifications for all Exams
Free Online Exams.com

Using Clustered Indexes

Visit the Below Website to access unlimited exam questions for all IT vendors and Get Oracle Certifications for FREE
http://www.free-online-exams.com

A clustered index determines the physical order of data in a table. A clustered index is analogous to a telephone directory, which arranges data by last name. Because the clustered index dictates the physical storage order of the data in the table, a table can contain only one clustered index. However, the index can comprise multiple columns (a composite index), like the way a telephone directory is organized by last name and first name.

A clustered index is particularly efficient on columns that are often searched for ranges of values. After the row with the first value is found using the clustered index, rows with subsequent indexed values are guaranteed to be physically adjacent. For example, if an application frequently executes a query to retrieve records between a range of dates, a clustered index can quickly locate the row containing the beginning date, and then retrieve all adjacent rows in the table until the last date is reached. This can help increase the performance of this type of query. Also, if there is a column(s) that is used frequently to sort the data retrieved from a table, it can be advantageous to cluster (physically sort) the table on that column(s) to save the cost of a sort each time the column(s) is queried.

Clustered indexes are also efficient for finding a specific row when the indexed value is unique. For example, the fastest way to find a particular employee using the unique employee ID column emp_id is to create a clustered index or PRIMARY KEY constraint on the emp_id column.

Note  PRIMARY KEY constraints create clustered indexes automatically if no clustered index already exists on the table and a nonclustered index is not specified when you create the PRIMARY KEY constraint.

Alternatively, a clustered index could be created on lname, fname (last name, first name), because employee records are often grouped and queried in this way rather than by employee ID
Get Oracle Certifications for all Exams
Free Online Exams.com

Create Filtered Indexes

Visit the Below Website to access unlimited exam questions for all IT vendors and Get Oracle Certifications for FREE
http://www.free-online-exams.com
A filtered index is an optimized nonclustered index especially suited to cover queries that select from a well-defined subset of data. It uses a filter predicate to index a portion of rows in the table. A well-designed filtered index can improve query performance as well as reduce index maintenance and storage costs compared with full-table indexes.

Filtered indexes can provide the following advantages over full-table indexes:

·         Improved query performance and plan quality

A well-designed filtered index improves query performance and execution plan quality because it is smaller than a full-table nonclustered index and has filtered statistics. The filtered statistics are more accurate than full-table statistics because they cover only the rows in the filtered index.

·         Reduced index maintenance costs

An index is maintained only when data manipulation language (DML) statements affect the data in the index. A filtered index reduces index maintenance costs compared with a full-table nonclustered index because it is smaller and is only maintained when the data in the index is changed. It is possible to have a large number of filtered indexes, especially when they contain data that is changed infrequently. Similarly, if a filtered index contains only the frequently modified data, the smaller size of the index reduces the cost of updating the statistics.

·         Reduced index storage costs

Creating a filtered index can reduce disk storage for nonclustered indexes when a full-table index is not necessary. You can replace a full-table nonclustered index with multiple filtered indexes without significantly increasing the storage requirements.

 

Design Considerations

·         When a column only has a small number of relevant values for queries, you can create a filtered index on the subset of values. For example, when the values in a column are mostly NULL and the query selects only from the non-NULL values, you can create a filtered index for the non-NULL data rows. The resulting index will be smaller and cost less to maintain than a full-table nonclustered index defined on the same key columns.

·         When a table has heterogeneous data rows, you can create a filtered index for one or more categories of data. This can improve the performance of queries on these data rows by narrowing the focus of a query to a specific area of the table. Again, the resulting index will be smaller and cost less to maintain than a full-table nonclustered index.

Get Oracle Certifications for all Exams
Free Online Exams.com

SQL Server Surface Area Configuration in SQL Server 2008

Visit the Below Website to access unlimited exam questions for all IT vendors and Get Oracle Certifications for FREE
http://www.free-online-exams.com

Surface area reduction is a security measure that involves stopping or disabling unused components. Surface area reduction helps to improve security by providing fewer avenues for potential attacks on a system.

For new installations of Microsoft SQL Server 2005, some features, services, and connections are disabled or stopped to reduce the SQL Server surface area. For upgraded installations, all features, services, and connections remain in their pre-upgrade state.

Use SQL Server Surface Area Configuration to enable, disable, start, or stop the features, services, and remote connectivity of your SQL Server 2005 installations. You can use SQL Server Surface Area Configuration on local and remote servers.

SQL Server Surface Area Configuration uses Window Management Instrumentation (WMI) to view and change server settings. WMI provides a unified way for interfacing with the API calls that manage registry operations that configure SQL Server. For information about configuring permissions related to WMI, see the topic How to: Configure WMI to Show Server Status in SQL Server Tools.

Get Oracle Certifications for all Exams
Free Online Exams.com

Tuesday, September 25, 2012

Page compression in SQL Server 2008

Visit the Below Website to access unlimited exam questions for all IT vendors and Get Oracle Certifications for FREE
http://www.free-online-exams.com

Until SQL Server 7.0 was released, the page size in SQL Server was 2K; now the page size is 8K.

Microsoft introduced page compression in SQL Server 2008. This new feature is available in the Enterprise edition and developer edition. The page compression feature of SQL Server can compress the entire page.

Page compression is applied only when the page gets full. When page compression occurs there are three operations that happen in the following order:

  • Row compression
  • Prefix compression
  • Dictionary compression
Get Oracle Certifications for all Exams
Free Online Exams.com

Monday, September 24, 2012

Difference between logical & physical standby database?

Visit the Below Website to access unlimited exam questions for all IT vendors and Get Oracle Certifications for FREE
http://www.free-online-exams.com

In  Oracle Data Guard you, Oracle transfers data from the main database to a standby database, and in case of failures, Oracle will switch over to the standby database.  We have two ways to create a standby database, logical standby and physical standby:

Physical standby differs from logical standby:

  • Physical standby schema matches exactly the source database.

  • Archived redo logs and FTP'ed directly to the standby database which is always running in "recover" mode.  Upon arrival, the archived redo logs are applied directly to the standby database.

Logical standby is different from physical standby:

  • Logical standby database does not have to match the schema structure of the source database.
     

  • Logical standby uses LogMiner techniques to transform the archived redo logs into native DML statements (insert, update, delete).  This DML is transported and applied to the standby database.
     

  • Logical standby tables can be open for SQL queries (read only), and all other standby tables can be open for updates.
     

  • Logical standby database can have additional materialized views and indexes added for faster performance.

Installing Physical standbys offers these benefits:

  • An identical physical copy of the primary database

  • Disaster recovery and high availability

  • High Data protection

  • Reduction in primary database workload

  • Performance Faster

Installing Logical standbys offer:

  • Simultaneous use for reporting, summations and queries

  • Efficient use of standby hardware resources

  • Reduction in primary database workload

  • Some limitations on the use of certain datatypes

Get Oracle Certifications for all Exams
Free Online Exams.com

Sunday, September 23, 2012

Oracle 10g Data Guard – Quick Switchover with Physical Standby Database

Visit the Below Website to access unlimited exam questions for all IT vendors and Get Oracle Certifications for FREE
http://www.free-online-exams.com
Once the standby database is setup using Data Guard and works properly, you may want to test switchover, or perform switchover to reduce primary database downtime during OS upgrades or hardware upgrades. (To set up a Physical Standby database, please refer to my OraFAQ blog "Oracle 10g – Manually Create a Physical Standby Database Using Data Guard".)

A switchover allows the primary database to switch roles with its standby database. There is no data loss during a switchover. You can switch back to the original Primary database later by performing another switchover.

In case of primary database failure, you will need to perform failover to transition the standby database to the primary role. After a failover, the original primary database can no longer participate in the Data Guard configuration. So if the original Primary database is still accessible, you should always consider a switchover first.

This document only talks about switchover involving physical standby database. In this example, the original primary data is called PRIM and the original standby database is called STAN.

I. Before Switchover:

1. As I always recommend, test the Switchover first on your testing systems before working on Production.

2. Verify the primary database instance is open and the standby database instance is mounted.

3. Verify there are no active users connected to the databases.

4. Make sure the last redo data transmitted from the Primary database was applied on the standby database. Issue the following commands on Primary database and Standby database to find out:
SQL>select sequence#, applied from v$archvied_log;
Perform SWITCH LOGFILE if necessary.

In order to apply redo data to the standby database as soon as it is received, use Real-time apply.

II. Quick Switchover Steps

1. Initiate the switchover on the primary database PRIM:
SQL>connect /@PRIM as sysdba
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;

2. After step 1 finishes, Switch the original physical standby db STAN to primary role;
Open another prompt and connect to SQLPLUS:
SQL>connect /@STAN as sysdba
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

3. Immediately after issuing command in step 2, shut down and restart the former primary instance PRIM:
SQL>SHUTDOWN IMMEDIATE;
SQL>STARTUP MOUNT;

4. After step 3 completes:
- If you are using Oracle Database 10g release 1, you will have to Shut down and restart the new primary database STAN.
SQL>SHUTDOWN IMMEDIATE;
SQL>STARTUP;

- If you are using Oracle Database 10g release 2, you can open the new Primary database STAN:
SQL>ALTER DATABASE OPEN;

STAN is now transitioned to the primary database role.

5. On the new primary database STAN, perform a SWITCH LOGFILE to start sending redo data to the standby database PRIM.
SQL>ALTER SYSTEM SWITCH LOGFILE;

Reference:
1. Oracle Data Guard Concepts and Administration 10g Release 2 (10.2), B14239-04;
2. Switchover and Failover Best Practices: Oracle Data Guard 10g release 2 by Oracle.
Get Oracle Certifications for all Exams
Free Online Exams.com

How To Open The Standby Database When The Primary Is Lost

Visit the Below Website to access unlimited exam questions for all IT vendors and Get Oracle Certifications for FREE
http://www.free-online-exams.com
Startup Mount

[oracle@rac2 ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.3.0 - Production on Wed Feb 4 19:51:12 2009
Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.
Connected to an idle instance.

SQL> STARTUP MOUNT
ORACLE instance started.
Total System Global Area  218103808 bytes
Fixed Size                  1260984 bytes
Variable Size             184549960 bytes
Database Buffers           29360128 bytes
Redo Buffers                2932736 bytes
Database mounted.
Check Status

SQL> SELECT OPEN_MODE,PROTECTION_MODE,DATABASE_ROLE FROM V$DATABASE;
OPEN_MODE  PROTECTION_MODE      DATABASE_ROLE
---------- -------------------- ----------------
MOUNTED    MAXIMUM PERFORMANCE  PHYSICAL STANDBYHow To Open The Standby Database When The Primary Is Lost
3/5  2/4/2009 
Recover if you have logs to apply
In this example the primary is lost and I don't have more archived logs to apply:

SQL> RECOVER STANDBY DATABASE;
ORA-00279: change 794348 generated at 12/29/2008 12:23:02 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/oradata/dgfdb/archive/1_49_633452428.dbf
ORA-00280: change 794348 for thread 1 is in sequence #49
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00308: cannot open archived log
'/u01/app/oracle/oradata/dgfdb/archive/1_49_633452428.dbf'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
SQL> !ls -l /u01/app/oracle/oradata/dgfdb/archive/
total 31072
-rw-r-----  1 oracle oinstall  1158656 Dec 29 11:31 1_37_633452428.dbf
-rw-r-----  1 oracle oinstall  7385600 Dec 29 11:31 1_38_633452428.dbf
-rw-r-----  1 oracle oinstall  4941824 Dec 29 11:31 1_39_633452428.dbf
-rw-r-----  1 oracle oinstall 13739008 Dec 29 11:31 1_40_633452428.dbf
-rw-r-----  1 oracle oinstall  2272256 Dec 29 11:50 1_41_633452428.dbf
-rw-r-----  1 oracle oinstall     1024 Dec 29 11:51 1_42_633452428.dbf
-rw-r-----  1 oracle oinstall    89088 Dec 29 11:51 1_43_633452428.dbf
-rw-r-----  1 oracle oinstall  1847296 Dec 29 12:18 1_44_633452428.dbf
-rw-r-----  1 oracle oinstall   135680 Dec 29 12:18 1_45_633452428.dbf
-rw-r-----  1 oracle oinstall    67584 Dec 29 12:19 1_46_633452428.
-rw-r-----  1 oracle oinstall    34816 Dec 29 12:22 1_47_633452428.dbf
-rw-r-----  1 oracle oinstall     2048 Dec 29 12:22 1_48_633452428.dbf
Finish the Recovery process

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
Database altered.
Activate the Standby Database

SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;
Database altered.
Check the new status

SQL> SELECT OPEN_MODE,PROTECTION_MODE,DATABASE_ROLE FROM V$DATABASE;
OPEN_MODE  PROTECTION_MODE      DATABASE_ROLE
---------- -------------------- ----------------
MOUNTED    MAXIMUM PERFORMANCE  PRIMARY
Open the Database

SQL> ALTER DATABASE OPEN
Database altered.

SQL> SELECT OPEN_MODE,PROTECTION_MODE,DATABASE_ROLE FROM V$DATABASE;
OPEN_MODE  PROTECTION_MODE      DATABASE_ROLE
---------- -------------------- ----------------
READ WRITE MAXIMUM PERFORMANCE  PRIMARY
Get Oracle Certifications for all Exams
Free Online Exams.com