Archive
Sharing a good Post from Anthony Fernando : How to become a Leader in Life
Dear all,
I am posting an Anthony’s Post : How to become a Leader in Life it s really motivated me & you can also benefited from it.
How To Be A Leader In Life
by anthony on June 13, 2012
As a new manager in a multinational corporation, Donna Peterson’s main focus in life was to prove that she had the skills and talent necessary to succeed in a male dominated industry.
After graduating from Harvard, summa cum laude, and completing her MBA at the Stanford school of business, Donna was confident in her knowledge and ability.
However, even with a strong academic background, Donna’s first year as a manager was tough.
While she tried to apply the principles she’d learnt at college, the members of her team were extremely resistant to change. Also, a number of the older team members continually questioned Donna’s authority and actively tried to undermine her.
By the time of her annual performance review, Donna was stressed, unhappy and was starting to question whether she really did have the street smarts necessary to succeed in the business world.
As she sat nervously in the waiting room at head office, Donna prepared to defend herself against the criticisms that she knew were in store.
At exactly 9am, the board room doors opened and an immaculately dressed woman in her mid fifties emerged. Her name was Karen Whitaker and within the company she was something of a living legend.
Karen greeted Donna warmly, and with an air of smooth authority, led her to a corner office that overlooked the bay. After the preliminaries of the annual review were out of the way, Karen quickly got down to business.
“Donna, I know that you’re doing your best and that you’re trying really hard. In fact, in a lot of ways, you remind me of myself when I started out in this business.” This made Donna smile. It was nice to hear that someone knew how hard she was trying.
“I’m going to give you one piece of advice that I’d like you to follow for the next six months. WIll you do that for me?”
“Of course I will” replied Donna expectantly.
“I want you to stop focusing on PROVING yourself, and start focusing on IMPROVING yourself”
“Umm, OK” replied Donna hesitantly.
“Let me explain” continued Karen, “When you focus on proving yourself, you always try and defend your position and demonstrate that you already have all the answers. However, when you focus on improving yourself, you begin to open yourself up to new ideas and feedback.”
“I think I understand Karen, and I’ll do my best. Thank-you”
When she returned to work, Donna took a piece of paper, and in permanent marker she wrote herself a sign that said, “Stop trying to PROVE yourself – Start trying to IMPROVE yourself”.
She then placed this sign in her top drawer so that she would see it regularly. Over the next six months, this single idea had an incredible impact on Donna’s life at work.
Instead of trying to prove that the theories she’d learnt at college were correct, and that she had all the answers, Donna began talking to other managers and touching base with Karen on a regular basis to improve her understanding of how the company worked in the real world.
She also began reading widely and listening to audiobooks to improve her knowledge of the industry she worked in. She was amazed at how fast things were moving and realised how important it was to stay in touch with emerging ideas.
On a practical level, one of the most useful things Donna did in response to Karen’s advice was to create a special file on her computer called ‘Lessons Learned’
Every time she picked up a useful idea or a gold nugget of advice, she would jot it down in her ‘Lessons Learned’ document. She then reviewed this document once a month to make sure that she was implementing these ideas into her life.
Another major change in Donna’s approach was her response to feedback. In the past her reaction to negative feedback was to fight back and defend herself in order to prove that the negative feedback was unjustified.
Now, with her focus on improving herself, she looked forward to all feedback – good OR bad. When she received negative feedback she now looked at it as a chance to grow and build her skills.
Donna’s new focus also had a big impact on the dynamics of her team. Instead of always trying to prove that she was in charge and knew what was best, she now asked the members of her team for their input before making important decisions.
This was not however the same thing as making decisions by committee. Donna still made the final call, but now everyone in the team felt that they had the opportunity to contribute.
But perhaps best of all, Donna no longer carried the weight of trying to prove that she was perfect all the time.
Her new focus on improving herself allowed her to admit that she sometimes made mistakes and also allowed her to ask for help when she needed it.
So today I’d like to encourage you to apply Karen’s advice to your own life.
Here’s what to do:
1. Stop focusing on PROVING yourself and start focusing on IMPROVING yourself.
2. Instead of defending your current knowledge, find ways to continually increase your levels of understanding and grow as a person.
3. Instead of becoming defensive and fighting against negative feedback, embrace feedback of all kinds and use it to get better.
4. Create a document called ‘Lessons Learned’ and every time you discover a gold nugget of advice, write it down and review your collection regularly.
5. Stop trying to be perfect. Give yourself permission to learn from your mistakes and don’t be afraid to ask for help when you need it.
Until next time,
Dare To Dream!
How to use SQL Server default trace historical events for analysis and reporting
Problem
I often find when you are dealing with bigger data size & started a trace, when tempdb last had an autogrow event, or when the last full backup for master occurred. Usually we have to tell them that they *might* be able to get this information. Since these and other events are captured by the default trace, but the default trace only keeps five 20MB rollover files by default. This means that the event you are after may no longer be there, depending on how long ago it was and how busy your server happens to be. Unfortunately, people often need to find this information well after the fact, and in a lot of these cases the data is no longer available.
Solution
It occurred to me that it would be fairly trivial to set up a job that keeps as much of this history for you as you want. All you need is a table representing an initial “snapshot” of the default trace data, and a job that is responsible for (a) adding any new events to this table periodically (filtering out any “irrelevant” events), and (b) trimming out old history. You can use your own definitions here for “irrelevant” or “old” (more on this below).
To get started, in some permanent database other than tempdb, you can create an initial “snapshot” of the current default trace data with the following code. You might want to choose different columns here depending on what kind of troubleshooting you are hoping to get help with. I’ve left out performance-related columns such as Reads, Writes, CPU, PlanHandle, etc., since none of the events I am interested in for this example record that data anyway. Remember that the more data that you store in this history table, the less history you’ll be able to store given the same disk space.
DECLARE @path NVARCHAR(260);
SELECT @path = REVERSE(SUBSTRING(REVERSE([path]),
CHARINDEX('\', REVERSE([path])), 260)) + N'log.trc'
FROM sys.traces WHERE is_default = 1;
SELECT
TextData = CONVERT(NVARCHAR(MAX), TextData),
DatabaseID,
HostName,
ApplicationName,
LoginName,
SPID,
StartTime,
EndTime,
Duration,
ObjectID,
ObjectType,
IndexID,
EventClass,
[FileName],
RowCounts,
IsSystem,
SqlHandle = CONVERT(VARBINARY(MAX), SqlHandle)
INTO dbo.DefaultTrace_History
FROM sys.fn_trace_gettable(@path, DEFAULT);
CREATE CLUSTERED INDEX IX_StartTime ON dbo.DefaultTrace_History(StartTime);
The clustered index on the StartTime column will be a great help both when trying to find data within a certain date range and also when the background job is trying to append or delete data. You might also consider non-clustered index on EventClass or any column where you think you might be performing targeted searches.
A query to add new data periodically would look like this, making sure to filter out any data from the default trace that you’ve already captured in your history table:
DECLARE @maxDT DATETIME; SELECT @maxDT = MAX(StartTime) FROM dbo.DefaultTrace_History; INSERT dbo.DefaultTrace_History SELECT TextData = CONVERT(NVARCHAR(MAX), TextData), DatabaseID, HostName, ApplicationName, LoginName, SPID, StartTime, EndTime, Duration, ObjectID, ObjectType, IndexID, EventClass, [FileName], RowCounts, IsSystem, SqlHandle = CONVERT(VARBINARY(MAX), SqlHandle) FROM sys.fn_trace_gettable(@path, DEFAULT) WHERE StartTime > @maxDT;
And a query to purge old data, say if you wanted to keep a max of 90 days in history, would look like this:
DELETE dbo.DefaultTrace_History WHERE StartTime < DATEADD(DAY, -90, CURRENT_TIMESTAMP);
You could schedule these in the same job and run them as frequently as you like – important, though, to balance the need to ensure you capture all information with the impact on the system. Every five minutes is way too often, and once a month is not often enough. I would say once a day is probably a safe interval.
You might want to keep the logic in two separate procedures, though. For example if you were doing some emergency troubleshooting, you might want to call the procedure that inserts new data before you start, so that all of the data in the history table is up to date (without also deleting any of the oldest data).
Now, getting back to the irrelevant data that you might want to filter out of the query. You can discover the events that will be captured by the default trace with the following query:
SELECT EventID = e.trace_event_id, Category = c.name, [Event] = e.name FROM sys.traces AS t CROSS APPLY sys.fn_trace_geteventinfo(t.id) AS ti INNER JOIN sys.trace_events AS e ON ti.eventid = e.trace_event_id INNER JOIN sys.trace_categories AS c ON e.category_id = c.category_id WHERE t.is_default = 1 GROUP BY e.trace_event_id, c.name, e.name ORDER BY Category, [Event];
In SQL Server 2012, there are 34 events that are captured; the results are:
EventID Category Event --- ----------------------- ---------------------------------------------------- 92 Database Data File Auto Grow 94 Database Data File Auto Shrink 167 Database Database Mirroring State Change 93 Database Log File Auto Grow 95 Database Log File Auto Shrink 22 Errors and Warnings ErrorLog 55 Errors and Warnings Hash Warning 79 Errors and Warnings Missing Column Statistics 80 Errors and Warnings Missing Join Predicate 69 Errors and Warnings Sort Warnings 155 Full text FT:Crawl Started 156 Full text FT:Crawl Stopped 164 Objects Object:Altered 46 Objects Object:Created 47 Objects Object:Deleted 218 Performance Plan Guide Unsuccessful 109 Security Audit Audit Add DB User Event 108 Security Audit Audit Add Login to Server Role Event 110 Security Audit Audit Add Member to DB Role Event 111 Security Audit Audit Add Role Event 104 Security Audit Audit Addlogin Event 115 Security Audit Audit Backup/Restore Event 117 Security Audit Audit Change Audit Event 152 Security Audit Audit Change Database Owner 102 Security Audit Audit Database Scope GDR Event 116 Security Audit Audit DBCC Event 106 Security Audit Audit Login Change Property Event 20 Security Audit Audit Login Failed 105 Security Audit Audit Login GDR Event 103 Security Audit Audit Schema Object GDR Event 153 Security Audit Audit Schema Object Take Ownership Event 175 Security Audit Audit Server Alter Trace Event 18 Security Audit Audit Server Starts And Stops 81 Server Server Memory Change
(Please review this article which will give you a better idea of what events and columns you want to track and what data you don’t consider important. The example above is just one way to configure your history table and may not be the right setup for you.)
If you had a few of these events you wanted to leave out (e.g. Audit Login Failed because you’re monitoring those elsewhere, or any of the execution plan warnings) you could filter them out this way:
... WHERE StartTime > @maxDT AND EventClass NOT IN (20, 55, 69, 79, 80);
Similarly, if you wanted to have much more targeted monitoring for very specific events (e.g. only Auto Grow events), then you could change the query this way:
... WHERE StartTime > @maxDT AND EventClass IN (92, 93);
If you follow this guideline, you’ll have much higher confidence to be able to track down specific events after the fact, without having to worry about whether they’ve rolled off the default trace already (and without having to hammer the default trace on your production system). You could insulate your production instance even further by replicating or mirroring this data, or sending the data to a linked server and never storing it locally in the first place.
Friends you are welcome to give any query or suggestion.
Bhargava's Blog 