Thursday, August 17, 2006
As a DBA for a development environment, particularly one without any feathers to show for experience, you would probably have to deal with several different DBMSes. Although I prefer to work with Oracle, I was assigned to a team that uses Microsoft SQL Server 2005. This version is quite user-friendly compared to the previous versions, as long as you follow the step-by-step guides; if you stray from it, it's likely you'll be wondering why something didn't work as the error messages can be quite cryptic.
One of the things that Oracle can do for you within a development environment is help in finding unused objects. The MONITORING USAGE clause and the V$OBJECT_USAGE view are what you would be using. Once you are done, don't forget to use NOMONITORING USAGE, else performance will take a hit.
To do the same on SQL Server, you would probably have to devise some method of your own. To track write operations, you can use Triggers to update another table. For read operations, if you use Stored Procedures or Functions, you could perhaps modify the code. If that isn't an option, you would probably have to rely on the SQL Server Profiler and 3rd party utilities.
When moving from Oracle to SQL Server, you could probably take some time off and work with T-SQL as it is different from PL/SQL. As long as you remember that this is new ground you're covering, you'll find it fun and easy to write T-SQL.
Note: PostgreSQL is a really good alternative to Oracle. You'll have to perform intensive tests as it isn't suitable for a production environment but PL/pgSQL is so close to PL/SQL that porting code shouldn't be too much of a hassle. But why PostgreSQL when Oracle has announced that Oracle 10g Express Edition will be available for free?
One of the things that Oracle can do for you within a development environment is help in finding unused objects. The MONITORING USAGE clause and the V$OBJECT_USAGE view are what you would be using. Once you are done, don't forget to use NOMONITORING USAGE, else performance will take a hit.
To do the same on SQL Server, you would probably have to devise some method of your own. To track write operations, you can use Triggers to update another table. For read operations, if you use Stored Procedures or Functions, you could perhaps modify the code. If that isn't an option, you would probably have to rely on the SQL Server Profiler and 3rd party utilities.
When moving from Oracle to SQL Server, you could probably take some time off and work with T-SQL as it is different from PL/SQL. As long as you remember that this is new ground you're covering, you'll find it fun and easy to write T-SQL.
Note: PostgreSQL is a really good alternative to Oracle. You'll have to perform intensive tests as it isn't suitable for a production environment but PL/pgSQL is so close to PL/SQL that porting code shouldn't be too much of a hassle. But why PostgreSQL when Oracle has announced that Oracle 10g Express Edition will be available for free?
# posted by Nitin Reddy Katkam @ 8/17/2006 02:26:00 PM 
