Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 123»»»

Getting A Clue About Your Databases Expand / Collapse
Author
Message
Posted Friday, January 9, 2009 12:09 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, February 27, 2012 8:09 AM
Points: 290, Visits: 220
Comments posted to this topic are about the item Getting A Clue About Your Databases
Post #633119
Posted Friday, January 9, 2009 4:13 AM


UDP Broadcaster

UDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP Broadcaster

Group: General Forum Members
Last Login: Wednesday, January 2, 2013 12:15 PM
Points: 1,443, Visits: 711
Good article, lots of useful info.
I think this beats going in and poking around blindly!
Post #633239
Posted Friday, January 9, 2009 6:30 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 6:29 AM
Points: 1,577, Visits: 1,906
What an excellent idea! I used to just poke around blind as well. Trying that on a database where the tables all had 4 character names (which were abbreviations from Russian) and the fields had 8 character names (again, from Russian), it's hard to find stuff. Something like this would have helped a lot. I may use these in the future since I happen to set up data transfers from different systems.
Post #633316
Posted Friday, January 9, 2009 6:42 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, February 27, 2012 8:09 AM
Points: 290, Visits: 220
Hi, well thanks :) I also tried to make it more "out of the box thing", so you'd just call one procedure and get some results. But each db is unique, so when you are exploring it, some parameters do have to be adjusted, if only to loose matching of table or column names etc.
Post #633337
Posted Friday, January 9, 2009 7:10 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Wednesday, August 27, 2014 8:01 AM
Points: 1,419, Visits: 2,085
First thanks for the scripts, they will surely help me on some occasions. (the one that get the dependencies instead of viewing them in the tiny box in the enterprise manager)

What I would like to bring is when testing them out I used a database that I was very comfortable with and found that the information that I gathered was not very helpful for someone who would need to get a quick overview of that database type in particular.

Not because the scripts does not work well but because the database work differently than the intended proposed solution and this is a scenario that could happen to others as well. I would like to propose you an additional approach.

I believe, when the database has run a bit, is to get the statistics on index scan / seek etc as the primary way to get information about usefulness of a table instead of the table size / rows.

In my case the most worthy tables only contains a few tenth of rows and looking at them from the index scan / seek reveal that information.

What do you think of this additional approach?
Post #633367
Posted Friday, January 9, 2009 7:27 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, February 27, 2012 8:09 AM
Points: 290, Visits: 220
Thanks for the suggestion, well worth of consideration! I guess I was so desperate looking at some databases I got recently, with nearly half of all tables empty or with max 1 row (really), so I focused on that metric. Combining few methods or trying various approaches is generally the way to go, I suppose.
Post #633380
Posted Friday, January 9, 2009 7:50 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Wednesday, August 27, 2014 8:01 AM
Points: 1,419, Visits: 2,085
Yes I understand your points, there's not a solution that will fit for every problem.

If I could have time I would expand your queries to add a weighting mechanism for some criteria (index, size, row count, update date etc) and let the dba choose how she/he what to configure it with default value to run out of the box.
Post #633410
Posted Friday, January 9, 2009 7:52 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Wednesday, August 17, 2011 7:09 AM
Points: 869, Visits: 963
Good article! There's nothing worse than trying to learn a database that has inherent encryption. :)
Post #633414
Posted Friday, January 9, 2009 8:02 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, April 9, 2009 8:28 AM
Points: 2, Visits: 13
Hello. It must be noted that to perform the coding as presented, one must have 'Admin' rights to the database.
Post #633429
Posted Friday, January 9, 2009 8:16 AM


Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, December 9, 2013 1:26 PM
Points: 60, Visits: 258
Excellent article!
Very impressive topic and easily readable!

I look forward to your future articles!


Paul DB
Post #633454
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse