Dino Hsu <dino1.nospam_at_ms1.hinet.net> wrote in message news:<3kmqtt47tpccu9i5h12a56ubrfebqib0l2_at_4ax.com>...
> Dear all,
>
> I am studying <<Oracle designing and tuning for performance>>, there
> is one paragragh as follows: (2 Performance Tuning Methods, tuning
> steps)
>
> <quote begin>
> Step 2: Tune the Data Design
> In the data design phase, you must determine what data is needed by
> your applications. You must consider what relations are important, and
> what their attributes are. Finally, you need to structure the
> information to best meet performance goals.
>
> The database design process generally undergoes a normalization stage
> when data is analyzed to eliminate data redundancy. With the exception
> of primary keys, any one data element should be stored only once in
> your database. After the data is normalized, however, you may need to
> denormalize it for performance reasons. You might decide that the
> database should retain frequently used summary values. For example,
> rather than forcing an application to recalculate the total price of
> all the lines in a given order each time it is accessed, you might
> decide to always maintain a number representing the total value for
> each order in the database. You could set up primary key and foreign
> key indexes to access this information quickly.
>
> Another data design consideration is avoiding data contention.
> Consider a database 1 terabyte in size on which one thousand users
> access only 0.5% of the data. This "hot spot" in the data could cause
> performance problems.
>
> In a multiple-instance setup, try to localize access to the data down
> to the partition level, process, and instance levels. That is,
> localize access to data, such that any process requiring data within a
> particular set of values is confined to a particular instance.
> Contention begins when several remote processes simultaneously attempt
> to access one particular set of data.
>
> In Oracle Parallel Server, look for synchronization points--any point
> in time, or part of an application that must run sequentially, one
> process at a time. The requirement of having sequential order numbers,
> for example, is a synchronization point that results from poor design.
>
> Also consider implementing two Oracle8i features that can help avoid
> contention:
>
> Consider partitioning your data.
>
> Consider using local or global indexes.
>
> See Also:
> For more information on partitioning and indexes, see Oracle8i
> Concepts.
> <quote end>
>
> A multiple-instance setup is, in my idea, the same thing as an Oracle
> Parallel Server, I don't know why it uses different terms here. I
> don't know what "localize access to the data down to the partition
> level" means (I know "partition", though), does it mean different
> parts of data are accessible to different instances? Because I have to
> finish reading tuning first, I cannot wait until I understand OPS,
> hope someone can give me a simple idea about this. Thanks in advance.
>
> Dino
Dino, I think you are correct in that the manual appears to be
referring to an OPS set-up for version 8.1 and lower. With 9i OPS has
been modified and renamed to RAC, real application clusters and
features the increased use of cluster fusion instead of block pinging
and this is supposed to eliminate the need to segregate user access to
one instance.
Received on Mon Oct 29 2001 - 12:20:18 CST
