February 4, 2009 at 7:21 pm
Grant Fritchey (2/4/2009)
And I've been staying out of the way since this was identified as PeopleSoft. Same approach I take at work.
Why? You don't like working with PeopleSoft? 😉
February 5, 2009 at 5:35 am
1) It's just not open for the kind of manipulation I'm used to making
2) I don't have access to the tools it needs
3) Because I've been told to keep my sticky fingers off
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 5, 2009 at 6:30 am
Okay, makes sense (1 and 2). Number 3, I haven't been told that, but I'm not trying to do that much with it and if I was, I'd just work closely with our PeopleSoft Admin and developers. There are some things I'd like to investigate, I just don't have the time at the moment.
February 5, 2009 at 7:00 am
Lynn Pettis (2/5/2009)
Okay, makes sense (1 and 2). Number 3, I haven't been told that, but I'm not trying to do that much with it and if I was, I'd just work closely with our PeopleSoft Admin and developers. There are some things I'd like to investigate, I just don't have the time at the moment.
I forgot #4) Our Peoplesoft is on Oracle.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 5, 2009 at 9:37 am
I really do not know what this means but I have uploaded a file with the results of
select * from sys.dm_db_missing_index_details
February 5, 2009 at 10:00 am
I have just uploaded the results from running sys.dm_db_missing_index_group_stats
is this is bad as it looks I am really not sure how to read it yet.
I know I am asking a lot of questions but this has just been laid in my lap we moved to peoplesoft in
august 08 and I have had no training if you could bare with me a little longer I would be very GRATEFUL.
February 5, 2009 at 10:22 am
That is scary. However, I wouldn't worry too much (worry some, yeah).
I'm hesitant to suggest what to do since this is PeopleSoft, but let's assume for a moment that it's just another database. Instead of sweating indexes, especially in batch like this, instead focus on what's actually happening on the system. Use a server-side trace (do a search for that phrase) to collect data on the queries that are being run on the system. Find the ones that run longest and are run most often. Focus on those queries. They may need indexes, in which case the missing indexes list will help.
Now, back to reality. Since it's Peoplesoft, I'm not sure the same rules apply.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 5, 2009 at 1:23 pm
If this is a query run from a front-end process, you need to figure out how to run a trace from the PeopleSoft side. This is how we determined the actual source of our performance issue. We were able to identify a 200,000 row table that had no index that once indexed eliminated our problem. The problem table never showed up when using DTA or in missing_index system table.
What is more perplexing regarding the problem we had, is everthing worked fine under SQL Server 2000. The table was not indexed there either.
I'll try to get our PeopleSoft Admin to get in on this thread. She may be able to help you get the front end trace going if you are having problems with that part.
Viewing 8 posts - 31 through 37 (of 37 total)
You must be logged in to reply to this topic. Login to reply