Posts Categorized: Pythian
Log Buffer #4: A Carnival of the Vanities for DBAs
Today is SysAdmin day, don’t you know. Right up until last year, DBAs were included in this global movement to celebrate systems administrators. The Internet Wayback Machine gladly shows us how the site looked last year, clearly including DBAs right in the home page. This year? No mention of us!
Doug Burns of Doug’s Oracle Blog has volunteered to edit and publish Log Buffer #4. Thank you, Doug! We look forward to next Friday.
Welcome to the second weekly edition of Log Buffer, a series of “Carnival of the Vanities” blogs for DBAs. (I get to call it a series now that there’s more than one.)
A client asked me, “How can I move a table to another schema in Oracle?” The quick answer I gave him is, “not possible”. You have to rebuild it via “create table as select”. You might ask, justifiably, why would you want to do that anyway? His problem was that the application has been split into 2 parts, and he wanted to have separate schemas for each part, to ensure that there is no cross-schema table access.
Welcome to the inaugural Log Buffer, a Carnival of the Vanities for the DBA community. Since this is the first, the duty of hosting it falls to us, but we hope other bloggers in the community will take on future editions. Here are our favourite database-related blog articles.
My name is Dave Edwards, and I started at The Pythian Group a week ago my work here has been given the title Communications Specialist. This position is a new one, so I’m building it as I go.. In general terms, my job is to help Pythian tell its stories. That takes in everything from technical documentation and whitepapers, to our blog posts. Wherever words are required.
I’ve been invited by new Pythian partner GridApp to co-host a webinar with their eminent chief scientist, Matt Zito. If you don’t know about GridApp, you certainly should. They offer a rapid-provisioning and configuration management system called Clarity that substantially streamlines repetitive database management chores while simultaneously providing visibility into inventory and configuration changes.
With the new dynamic performance views available in SQLserver 2005 you can run queries which allow you to determine these poor performers without much extra work. It is not statspack or Automatic Workload Repository (AWR) or V$ACTIVE_SESSION_HISTORY (more importantly) but it is a good start to determining what sql and what sessions are consuming the most resources in SQLserver 2005 instance.
I have been scanning some blogs by different teams involved with SQLserver 2005. There is a bit of cross linking happening so some articles are repeated on one or more blogs. Here is a short list: