Getting A Clue About Your Databases

  • Comments posted to this topic are about the item Getting A Clue About Your Databases

  • Good article, lots of useful info.

    I think this beats going in and poking around blindly!

  • 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.

  • 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.

  • 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?

  • 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.

  • 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.

  • Good article! There's nothing worse than trying to learn a database that has inherent encryption. 🙂

  • Hello. It must be noted that to perform the coding as presented, one must have 'Admin' rights to the database.

  • Excellent article! :smooooth:

    Very impressive topic and easily readable!

    I look forward to your future articles!

    Paul DB

  • Nice, useful article. Good scripts. Thanks.

    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • Great article, I really like your approach. Working in ETL, I too often have to look at unfamiliar data, with guidance that is missing or unreliable, and it's great having a toolkit to examine such data. I wrote some code that will examine a table and determine possible natural keys for it: You might want to consider adding it to your toolbelt. 🙂

  • Nice article...:)

  • Anirban Paul (1/9/2009)

    Nice article...:)

    Just curious ! ! !

    Why Anirban always had same response to all articles ?

    SQL DBA.

  • Each time you post on the forum you get a point, could be the reason.

    Or it also could be to let a positive feedback for the author. Always feel good to know that you are doing something good even if it's only from few words.

Viewing 15 posts - 1 through 15 (of 22 total)

You must be logged in to reply to this topic. Login to reply