Results 1 to 7 of 7
  1. #1
    Join Date
    Nov 2004
    Posts
    5

    Unanswered: P4 running 10 TB database?

    Currently I've got a Pentium 4 2.8 running 4 GB Oracle 10g database. It does the job well and traffic is very low, 50 hits a day. I'm confident I already know the answer to this question, but how terribly would she perform running a 10 TB database with the same amount of traffic. As of now I'm unsure exactly how processor intensive such a database would be even for such small amounts of traffic, although I assume it will be quite high.

  2. #2
    Join Date
    Mar 2002
    Location
    Reading, UK
    Posts
    1,137
    Well you'll have to do a statistical analysis of what your users do and what queries end up being run. If your queries retrieve a single row using an unique index then 10TB isnt going to be a problem, if the do full table scans then there will be serious problems. Try running statspack, look at v$sqlarea or put tracing on to find out what queries are being run and how often.

    Alan

  3. #3
    Join Date
    Nov 2004
    Location
    Temple University
    Posts
    36

    Cool P4 Performance - increasing size of database

    There are a number of factors to consider, that you have not given us.
    Are we talking more or larger tables
    What kind of SQL is being executed. If you are doing a lot of math sum(col1), and you increase table size, that can kill you.
    Are you doing a lot of full table scans - memory will probably be your limiting factor.
    How are you going to store all this data - SAN or raid or??

    These are just the major factors that will affect your performance. Don't forget, that Oracle's main cpu use if LIO and Math (functions), but the OS also must use the cpu, and the factors I listed above will have major impact on the work that needs to be performed by the cpu at the OS level.

    The CPU is USUALLY not the factor limiting database performance. There will always be a bottleneck, just be sure that it is not caused by I/O or memory subsystem.

    HTH
    Peter

  4. #4
    Join Date
    Nov 2004
    Location
    Temple University
    Posts
    36
    There are a number of factors to consider, that you have not given us.
    Are we talking more or larger tables
    What kind of SQL is being executed. If you are doing a lot of math sum(col1), and you increase table size, that can kill you.
    Are you doing a lot of full table scans - memory will probably be your limiting factor.
    How are you going to store all this data - SAN or raid or??

    These are just the major factors that will affect your performance. Don't forget, that Oracle's main cpu use if LIO and Math (functions), but the OS also must use the cpu, and the factors I listed above will have major impact on the work that needs to be performed by the cpu at the OS level.

    The CPU is USUALLY not the factor limiting database performance. There will always be a bottleneck, just be sure that it is not caused by I/O or memory subsystem.

    HTH
    Peter

  5. #5
    Join Date
    Nov 2004
    Posts
    5
    I apologize for leaving out such important information. The database will be filled with metadata, and image files from sattelites. No heavy statistical work will be done on the fly as this database is accessed through the internet, so stats are done occasionally and put in their own table. Since this is mostly metadata and maps, few queries using sum, count, etc will be needed. The heaviest scanning will be going through tables for longitude and latitude coordinates. Data will most likely be stored on a SAN.

    From your post I gather that perhaps a P4 might do so long as it has the memory, or am I wrong?

    I shoud also mention that this database may grow to 30TB in the next 3 years. Would a cheap x86 machine be worth it in the long run?
    Last edited by Majmun; 11-15-04 at 12:45.

  6. #6
    Join Date
    Nov 2002
    Location
    Desk, slightly south of keyboard
    Posts
    697
    Hi,

    I really couldn't begin to tell you whether the cheap P4 would be up to the job - but I *would* say, if you do choose to go down that route then atleast go for a multi processor capable, expandable machine (for example, something from the Compaq Proliant range).

    You then atleast have the option of 'popping' another CPU or three in later on. Bear in mind, a quad 500Mhz Xeon will not be as quick as a single 2Ghz Xeon (for 90% of jobs anyway). You should also bear in mind that the general feeling of most Oracle instances is that they are disk bound, not CPU bound. A Proliant can also give you the option to migrate to better/faster RAID controllers and onwards to Fibre attached storage and whatever the current buzzword is for SAN, NAS etc. I'm sure there are other manufacturers who offer the same expandability at (near) P4 prices.

    I don't envy your work on a 30Tb GIS database, there is something about geographic data (specifically arc vectors) which breaks all the rules of Oracle performance. Even with Oracle Spatial ("Oracle Spacedout?") on only 1.4Gb of data, I have been mighty dissappointed.

    Vectors simply do not fit any SQL/relational model. If you're dealing with Points not Arcs then I expect you will have more luck.

    Code:
    select "arcs" 
    where
    [the arc both begins and ends within my displayable space or
    it begins out of my space but ends within or
    it ends out of my space but begins within or
    it both begins and ends outside my space but intersects it or
    
    okay.. getting clever, 
    
    where entire max(x,y), min(x,y) falls within my space
    or entire max(x,y), min(x,y) could intersect my space 
    
    or even better....
    
    "sod it..."
     select * from world....
    ]
    Hth
    Bill
    Please don't email me directly with questions. I've probably just got home from the pub and cannot guarantee the sanity of my answers. In fact, I can't believe I actually made it home.

  7. #7
    Join Date
    Nov 2004
    Location
    Temple University
    Posts
    36

    GIS Database

    Bill is quite right about Oracfle tending to be more disk bound, than cpu bound. As long as you are not performing a lot of calculations, you should not become cpu bound at 50 - 100 hits per day. You must be very careful in how you set up the SAN, ASYNC I/O is a MUST for something this size. You need to be able to free the cpu to do other tasks, while the disks are delivering the data. This in turn leads to a discussion of MEMORY. X86 machines are very limited in the amount of addressable memory. Oracle does have a few tools where you can stuff things in high memory. I have never used them, only read about them, because I run Unix. If you are going to go the X86 route, I would definitely look into Linux. I understand that has a much friendlier memory architechture.

    Of the 3 major subsystems
    cpu
    memory
    storage

    If memory and storage are set up correctly, cpu will not be an issue.

    HTH
    Peter

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •