Oakies Blog Aggregator

The Wolf Gift is the first in The Wolf Gift Chronicles by Anne Rice.

Followers of the blog will know that I made a conscious attempt to get into reading a few years ago, having made it to my late 30′s (at the time) having only read a handful of books in my life. Having made the decision to begin reading, the first series of books I chose were The Vampire Chronicles by Anne Rice. I loved The Vampire Chronicles. I loved New Tales of the Vampires. I loved Lives of the Mayfair Witches. I couldn’t face any of the religious or romance novels by Anne Rice, so once I had finished these three series, I thought that was the end of the line for me.

Fast forward a few years and Anne Rice has returned to her roots and started a new series called The Wolf Gift Chronicles, which is not surprisingly about Werewolves. For me, this is like coming home. I like the way Anne Rice writes. I find it very easy to read and typically the pace of her stories suites me perfectly. The Wolf Gift is no exception.

If you’ve been suffering from Anne Rice withdrawal symptoms, you really need to read The Wolf Gift. I don’t think you will be disappointed.

Cheers

Tim…

 

---

The Wolf Gift was first posted on December 8, 2013 at 5:58 pm.
©2012 "The ORACLE-BASE Blog". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement.

My friend Kyle wrote a blog piece a while back

http://www.kylehailey.com/what-delphix-does-in-1-minute-22-seconds/

Now, not to criticise Delphix (in fact,the opposite – its a very very cool product, and you should read some of Kyle’s great blog content on it), but if you have not got it, or can’t get it, then as long as you have some imagecopy backups, and a NFS server hanging around, you can get to the "next best thing" using Oracle’s Direct NFS feature.

So…how close can we get to 1 minute 22 seconds…Lets try on a laptop

18:24:31 SQL> set time on
18:24:31 SQL> STARTUP FORCE NOMOUNT PFILE=C:\oracle\11.2.0.3\database\initC112d.ora
ORACLE instance started.

Total System Global Area  626327552 bytes
Fixed Size                  2257792 bytes
Variable Size             184552576 bytes
Database Buffers          432013312 bytes
Redo Buffers                7503872 bytes

18:24:40 SQL> CREATE CONTROLFILE REUSE SET DATABASE C112d RESETLOGS
18:24:40   2      MAXDATAFILES 200
18:24:40   3      MAXLOGFILES 32
18:24:40   4      MAXLOGMEMBERS 2
18:24:40   5      MAXINSTANCES 1
18:24:40   6      MAXLOGHISTORY 908
18:24:40   7  LOGFILE
18:24:40   8    GROUP 1 'C:\oracle\clone_db\c112d\redo1.log' SIZE 10M BLOCKSIZE 512,
18:24:40   9    GROUP 2 'C:\oracle\clone_db\c112d\redo2.log' SIZE 10M BLOCKSIZE 512,
18:24:40  10    GROUP 3 'C:\oracle\clone_db\c112d\redo3.log' SIZE 10M BLOCKSIZE 512
18:24:40  11  DATAFILE
18:24:40  12   'c:\oracle\bkp\SYSTEM.bkp'
18:24:40  13  ,'c:\oracle\bkp\SYSAUX.bkp'
18:24:40  14  ,'c:\oracle\bkp\UNDOTBS1.bkp'
18:24:40  15  ,'c:\oracle\bkp\USERS.bkp'
18:24:40  16  ,'c:\oracle\bkp\DEMO.bkp'
18:24:40  17  CHARACTER SET WE8MSWIN1252;

Control file created.

18:24:40 SQL> begin
18:24:40   2    dbms_dnfs.clonedb_renamefile('c:\oracle\bkp\system.bkp' , 'y:\c112d\system.clone');
18:24:40   3    dbms_dnfs.clonedb_renamefile('c:\oracle\bkp\sysaux.bkp' , 'y:\c112d\sysaux.clone');
18:24:40   4    dbms_dnfs.clonedb_renamefile('c:\oracle\bkp\undotbs1.bkp' , 'y:\c112d\undotbs1.clone');
18:24:40   5    dbms_dnfs.clonedb_renamefile('c:\oracle\bkp\users.bkp' , 'y:\c112d\users.clone');
18:24:40   6    dbms_dnfs.clonedb_renamefile('c:\oracle\bkp\demo.bkp' , 'y:\c112d\demo.clone');
18:24:40   7  end;
18:24:40   8  /

PL/SQL procedure successfully completed.

18:24:42 SQL> alter database open resetlogs;

Database altered.

18:24:49 SQL>

There you go Kyle…18 seconds

Nothing is more annoying that getting alerted on things that are not critical to you or that you already know is occurring and there is not a darn thing you can do about it.

I’ve also been frustrated to wake up in the morning and to see my inbox flooded with a ton of alerts from numerous EM12c systems and really-  none of them are truly critical, but can appear to be simply overwhelming!

How to we steer the inbox from madness to manageable?

The answer to this question is not just managing metric settings and thresholds-  there are a number of different ways to control what end up in your inbox or alerting you at every waking and sleeping hour.

The part in this series is focused on fine grain rule sets.  This is a post that will show you how in a few, simple steps, with the hopes that you can recreate this as simple or complex as you wish, based to make your EM12c server you better.

Note:  This next post is a change, that as I said, is about changing a rule set-  Remember-  changing a rule set is a change to ALL targets utilizing the rule set, vs. changing a metric policy or threshold at a target level, so think through what you want to change and how you want to make the change BEFORE you make the change.  All options I show you here can be performed in many, many different ways to address the problem.  Rationally think about the change you need to make, test it out and use common sense.

So for our email today, one of my clients systems have started to send this incident to my inbox at night:

 Host=hostxyz.client7.com
 Target type=Oracle Management Service
 Target name=#0000ff;">hostxyz.client7.com:4892_Management_Service
 Categories=Performance
 Message=#0000ff;">Loader Throughput (rows per second) for Loader_D exceeded the critical threshold (75). Current value: 65.08#0000ff;"> 
 Severity=Critical
 Event reported time=Dec 4, 2013 8:50:10 AM CST
 Operating System=Linux
 Platform=x86_64
 Associated Incident Id=#0000ff;">51218
 Associated Incident Status=New
 Associated Incident Owner=SYSMAN
 Associated Incident Acknowledged By Owner=No
 Associated Incident Priority=Very High
 Associated Incident Escalation Level=0
 Event Type=Metric Alert
 Event name=Management_Loader_Status:load_processing
 Metric Group=Active Loader Status
 Metric=#0000ff;">Loader Throughput (rows per second)
 Metric value=65.08
 Key Value=Loader_D
 Key Column 1=Loader Name
 Rule Name= Incident Management Ruleset,Incident creation Rule for metric alerts.
 Rule Owner=SYSMAN
 Update Details:
 Loader Throughput (rows per second) for Loader_D exceeded the critical threshold (75). Current value: 65.08
 Incident created by rule (Name = Incident Management Ruleset, Incident creation Rule for metric alerts.; Owner = SYSMAN).

I could really care less about this and am already receiving this information once it hits the warning threshold for review.  I don’t want to be woke up in the middle of the night, nor is it something that I can really address as a critical outage for this client.

Let’s edit our rule set by taking the information offered us in the email from the “Rule Name” section:

Rule Name= Incident Management Ruleset,Incident creation Rule for metric alerts.

Incident Rule Sets

Log into the EM12c and click on “Setup”, “Incidents” and then “Incident Rules”

You should see your Incident Rule Sets listed.

 

We’ll take the following information from our Incident email we recevied:

Rule Name= Incident Management Ruleset,Incident creation Rule for metric alerts.

and then one more section, “Categories”, (remember, some Incidents can belong to more than one category):

Categories=Performance

Taking just these two lines above, this tells us what incident rule is alerting us.  What we may not realize, is that by default, critical metric alerts notify on ALL categories and you then distinguish this by rule set, by target, by group, etc.  This is where the EM12c again proves itself to be a self-service product, giving the power to the administrator to receive notifications on any incident in the way that they want to receive or NOT receive.

Armed with this information, we are now going to take this example for our client and edit the rule set-

 

We’ve highlighted the rule set that matches the first part of the Rule name “combination” and click on Edit.

Then upon entering the info for the rule set, we’ll need to edit the actual rule, which is the second part of the combination offered in the “Rule Name” from the email.  Click on the Rule Tab, the rule which we wish to edit, then click on “Edit”.

 

This will take you into the rules basic information on what it uses for requirements it needs to trigger an incident.

By default, most rules are created to be triggered by very simple choices-

• Type of Alert, in this case-  Metric Alert
• Severity, in this case-  Critical

All other granularity has been left wide open, but you can change this and finely tune the granularity.

Now in the above email, we are told that the Category involved is “Performance”, but we really don’t want this waking us up in the middle of the night, as-

1.  This may be a server that regularly has high resource usage.

2.  It’s not a critical “pending outage” issue, but an issue that we would need to investigate in the morning or may already be a known issue that is scheduled to be addressed.

To address the emails,  we are going to make two changes.

1.  Only email on what is mission critical outage issues for Metric Alerts

2.  Create a new rule that will create an incident for any categories that are outside of what we want to be notified of for metric alerts.

 

As you can see in the above example, I’ve added a check-mark for the Category and chosen the following:

• Availability
• Capacity
• Error
• Fault

I can then click on Next and Save the change.

We still have the other categories that are important to us, but we just don’t want them emailing anymore.  I want them to create an incident and I’ll review them when I review my Incident Manager, as I’ve been a strong proponent of using the Incident manager in this manner.

Create a New Rule for Category Level Metric Alert Coverage

We have now returned to the Rules that make up the Rule Set-  Click on “Create” to create a new rule.  We are going to create a rule very similar to the one we just edited, (just in case you need an example to use as a reference…) but we are going to choose the other categories and have the rule handle these categories of Metric Alerts incidents differently.

 

Choose the default radio button, “Incoming events and updates to events” and click Continue, which will take you to the rule wizard.

 

For this rule, we choose the following:

• Type:  Metric Alert
• Severity: Critical
• Category: All the categories we didn’t choose for our rule that is still in place.

Click on Next to proceed to the next set the step of actions when the Metric is triggered in the wizard:

We want the EM to ALWAYS perform the actions when a metric alert for these categories are triggered, so leave the default here.

To save us time and energy, I believe is automating the assignment of the metric alerts and other common incident.

• Assign to SYSMAN or a User created for this purpose in the EM12c.  You can even assign a specific email address if one person or group are in charge of addressing these types of incidents, (more options, more options… )
• This is still critical, so assign the priority to “Urgent” or “Very High”.

We want these categories to NOT email, so skip the email section.

Choose to clear events permanently, unless you wish to retain this data.

Proceed to the next section of the wizard, where you can review your Condition and Action Summary.

 

Click to proceed to the next screen and add a meaningful name for your rule and a meaningful description-

 

Click on Save and then you will need to click on OK to save the rule to your existing rule set.

 

By following this process, we have 

1.  Removed specific categories from emailing from a specific rule so that only critical “possible” production outage incidents are going to email/paging.

2.  Added a second rule to handle those categories no longer in the original and to create incidents for review when appropriate time.

This could easily be built out so that a unique user is created with an email address to page uniquely and only assign mission critical, production OUTAGE to alert.

One rule could handle this for just production admin group, one business line, etc. to happen only after hours by editing the notification schedule.

You have the power in your hands to build out your Enterprise Manager 12c environment in the way you need it to support you and to do what your business needs to be more productive.

 

 

 

Tags:  

---

Copyright © DBA Kevlar [EM12c- Managing Incidents, Stopping the Insanity, Part III], All Right Reserved. 2013.

Very common request I get from my customers is to parameterize the query executed by a Hive action in their Oozie workflow.
For example, the dates used in the query depend on a result of a previous action. Or maybe they depend on something completely external to the system – the operator just decides to run the workflow on specific dates.

There are many ways to do this, including using EL expressions, capturing output from shell action or java action.
Here’s an example of how to pass the parameters through the command line. This assumes that whoever triggers the workflow (Human or an external system) has the correct value and just needs to pass it to the workflow so it will be used by the query.

Here’s what the query looks like:

insert into test select * from test2 where dt=${MYDATE}

MYDATE is the parameter that allows me to run the query on a different date each time. When running this query in hive, I’d use something like “set MYDATE=’2011-10-10′” before running the query. But when I run it from Oozie, I need to pass the parameter to the Hive action.

Lets assume I saved the query in a file hive1.hql. Here’s what the Oozie workflow would look like:

	
	
		
			${jobTracker}
			${nameNode}
			${hiveSiteXML}
			
			MYDATE=${MYDATE}
		
		
		
	
	
		Action failed, error message[${wf:errorMessage(wf:lastErrorNode())}]
	
	

The important line is “MYDATE=${MYDATE}”. Here I translate an Oozie parameter to a parameter that will be used by the Hive script. Don’t forget to copy hive-site.xml and hive1.hql to HDFS! Oozie actions can run on any datanode and will not read files on local file system.

And here’s how you call Oozie with the commandline parameter:
oozie job -oozie http://myserver:11000/oozie -config ~/workflow/job.properties -run -verbose -DMYDATE=’2013-11-15′

Thats it!