Thursday, December 11, 2003, 8:44:43 AM, [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: rcn> The biggest thing about working on database in the rcn> multi-TB range is that its a nice buzzword for your rcn> resume. Its not necessarily harder.
This brings back some memories. I remember back when I moved up to my first "big" database. I went from managing a bunch of 5-10GB databases to one that was some 70GB in size. (try not to laugh now, ok<grin>) I was practically petrified. I fired off this one query to hit DBA_EXTENTS and sum up extent sizes for the different tablespaces. I was afraid the database might impload. Such a big database. So many extents. Well, I was much too easily intimidated. That big database was no different than the little instance on my laptop. Some differences, I've found, come into play when you start to move large amounts of data around. For example, I might be able to move a small table from one tablespace to another using an INSERT...SELECT...FROM. But maybe I don't want to do it that way for a table that's 10GB in size. Export/Import works, but what if my table is 10GB and my disks are only 4GB? And then there's the network. I'm not above exporting a table over TCP/IP connection, but that only works up to a certain point. A 5MB table? Ok. A 1MB table I might even try over a dial-up connection. A 10GB table over the network? Not ok. You really have to think a lot more about *how* you move data when the volumes get high. rcn> Besides, when your on a 'lower' end project with less rcn> resources and less people, Id argue that alot of times rcn> your job is alot harder. You dont have the same rcn> hardware and you have to do alot more different things rcn> yourself. Though it doesnt look as good on a resume... I did a lot of different things. That's true. I think they look ok on my resume though, and I like lots of variety and change in what I do. Actually, it's how I got into PL/SQL. Had I been doing DBA work at a really big site, I probably wouldn't have been asked to also take on PL/SQL development for a client application. As it was, I sort of got sucked into pretty much everything that was even remotely connected to the database, which was pretty much everything. Best regards, Jonathan Gennick --- Brighten the corner where you are http://Gennick.com * 906.387.1698 * mailto:[EMAIL PROTECTED] Join the Oracle-article list and receive one article on Oracle technologies per month by email. To join, visit http://four.pairlist.net/mailman/listinfo/oracle-article, or send email to [EMAIL PROTECTED] and include the word "subscribe" in either the subject or body. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jonathan Gennick INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
