Pythian Group

I must confess, that game I’m leasurely working on is nothing but a big fat excuse to dabble with fun bits of technology that I don’t get to touch with my usual projects. And in that optic, yesterday I fooled around with logging and internationalization stuff.

… Yes, I know. I’m using a game as a pretext to work on logging and I18N. I’m ashamed of myself. But aaanyway, let’s see what I got to discover.

Read the rest of this entry . . .

Hello Everyone,

This is one of my fist posts under Pythian’s blog. I will try to keep those short and simple at the beginning.

Recently I was troubleshooting a new GNS (Grid Name Services) functionality.

For more information please see here: Oracle Clusterware Network Configuration Concepts.

I have noticed that there is a-trace-level parameter in the GNS process string.
# ps -ef | grep gns
root 26790 1 2 14:41 ? 00:00:00 /u01/app/11.2.0/grid/bin/gnsd.bin -trace-level 0 -ip-address 10.10.193.201 -startup-endpoint ipc://GNS_hostrac01_23867_408c49e351f1f6a8
root 26825 17210 0 14:41 pts/1 00:00:00 grep gns


Unfortunately there is no description as of now in the documentation or MOS on how to change it to generate invaluable diagnostic information.
NOTE: I am sure the documentation will be updated in Database 12c version (c for Cloud ;)

For a time being the following should work for you:

# /u01/app/11.2.0/grid/bin/crsctl modify resource ora.gns -attr "TRACE_LEVEL=6"
# /u01/app/11.2.0/grid/bin/srvctl stop gns
# /u01/app/11.2.0/grid/bin/srvctl start gns


I hope that this advice will help you to diagnose your GNS issue.

I will blog about the way I resolved future GNS-related issues later on.

It looks like I have said too much for my very first post already.

See you around,

Yury

Just another DBA from down under

A data file is considered unrecoverable if an unrecoverable operation has been performed on an object residing in the data file since the last backup of the data file. Operations will become unrecoverable if they are not logged in the redo log. These “nologging” operations that suppress the generation of redo log, include the following:

1. direct load/SQL load
2. direct-path inserts result from insert or merge statement
3. ALTER TABLE commands
4. CREATE and ALTER INDEX commands
5. INSERT /*+APPEND*/
6. partition manipulation
7. database object that has explicitly set with nologging option
8. Oracle eBusiness Suite concurrent job execution identified in Oracle metalink note: 216211.1
9. Oracle eBusiness Suite patches activities that involve database object manipulation

The database recovery operations will look completed, but those data blocks used by the nologging objects in the data file will be marked corrupted when they are recovered. Accessing those nologging data objects in the recovered database instance will return a data block reading error such as ORA-1578 and ORA-26040, and the logical corruption in the data file will prevent the database object from being useful in the recovered database instance.

How do we detect unrecoverable operations?

Unrecoverable data files are those that involve nologging operations since the last successful backup took place. There are several ways to identify them. Read the rest of this entry . . .

In two words: online operations. In a paragraph: Forget partitioning, row-based replication and events. The big reasons most people are going to salivate over 5.1, and probably start plans to upgrade now, are the online operations:

• online ALTER TABLE for column rename, column default value change, and adding values to the end of an ENUM/SET
• Online, table-based logging. No more need to restart your server to enable or change the general or slow query logs. You can have the standard file-based output or choose a table format…which you can query.

Read the rest of this entry . . .