Several myths about Oracle databases

1. RAC (or OPS in Oracle 8i)
RAC is a myth that has been widely used for a long time. Because RAC has high hardware requirements, especially before 9i, it was almost always running on minicomputers, many people think of RAC as a synonym for stability and speed. Actually? In fact, we should first look at what the purpose of the RAC design is: To solve the high availability and high concurrency, so rather than the overall performance improvement. To a certain extent, RAC is slower than a single node because it has more communication and management between nodes than a single node. However, because of its high availability and support for a large number of concurrent connections, RAC applications are so extensive that the load can be evenly distributed on multiple machines with poor performance, when one node fails, other nodes can take over. But what RAC brings about is the complexity of management and performance reduction (this is especially evident in Ops OLTP systems, but it is much better in RAC systems ).
2. Partition)
Sometimes, someone may ask me, "How slow is the application speed when I partition a large table? I think it should be faster ", I will ask if his index is a local index? Is most of the applications based on the partition keyword as the query condition? The answer is often: "By the way, we use partition indexes for ease of management. We only have a small portion of queries with partition conditions, but most of them do not ". By the way, the reason is that the partition is not the fast = true parameter. In fact, this parameter is not used at all. Let's look at the purpose of partitioning for the convenience of large-scale Object Management in data warehouse systems such as DSS. The primary two functions of partitioning are high manageability and scalability, but performance improvement is not mentioned. Because of the large table partition, we can easily manage a partition instead of the whole table. However, if the query is not performed according to the partition conditions, and the index is a local index, the query needs to be separated to multiple local index trees for scanning instead of one index tree.
3. Parallel)
Today, I flipped through an oracle book and translated the word as a clue. At that time, I found that I was not dizzy. Parallelism is also a widely used myth. Before talking about parallelism, let's talk about a problem of assignment of work. There is a department leader, and there are 12 small soldiers (let's talk about it first). One day, a small task is coming, in fact, he finished the work in an hour, but he had to assign the work to the following 12 people at the same time. As a result, the meeting was held-> division of labor-> separate actions-> integration. The whole process was completed, they found it took one and a half hours. Why? The reason is the Blind division of labor. Parallel query is like this. It is suitable for a small number of concurrent users in the data warehouse environment to execute large queries. In the above example, it is good to assign a large job to 12 people. Therefore, the question to consider before deciding to use parallel queries is: will it affect other users because concurrency occupies a large amount of resources, parallel statements that increase the query speed. In addition to parallel queries, parallel DDL is a commonly used method for management to reduce maintenance time.