The Oracle tutorial being looked at is the comparison of Oracle and SQL Server in enterprise applications. The company I serve not only has an Oracle database, but also has a SQL Server database, so I often meet people asking me two questions.
The first type is usually "can you teach me to use Oracle?" "In the beginning, my polite answer to that would be" sure, I'm actually going to do an Oracle class, and I'll call you when I'm ready. " It's a good way to do it, and I didn't tell the inquirer it might take me weeks. Sometimes I further tell them where to download Oracle's full version for them to install and be familiar with. But sometimes this is a problem for me because it can lead to too many followers.
The second is generally the beginning of "We have some problems with SQL Server and I want to see how Oracle handles this problem." Well, we've finally made some progress. I can help them, but it won't take me a few hours. It should be a narrative that has been carefully considered for a particular issue, and Oracle's answer to this question will point the way to the Inquirer and may lead them to solve the SQL Server problem. "Our SQL Server database is getting too big," asked the--oracle, "How do we deal with this problem?" Alas... It seems that I am wrong.
I'd like to offer help, but ...
My methods may have been wrong all along. Maybe I should write a summary to summarize some of the problems that may be involved. When other people ask me for help, I can give him the list of questions. If the person is receiving an ordinary Oracle initiation education, the list may be a little broader. On the other hand, if the inquirer is searching for solutions to specific and quantifiable problems, the handbook can also help them move along in the right direction so they can find the answers on their desktops.
But I didn't do it because it took too much time. Although I helped these "aliens" as much as I could, I was really worried about spending too much time with them and straying away from my course. That would be a bad precedent. It will encourage them to come back and turn to me again at some point in time when they encounter some distress. Instead, I just spent a few minutes talking about design flaws in SQL Server. The content that the architecture involves is immutable. If you delve into the technical details of a database platform contrast judgment, you generally cannot get those self-evident principles. Conversely, if you decide to use Microsoft's database platform, these problems must exist. Its characteristics or flaws may be handled better by us, but the basic mechanism of the product is not easily changed-and certainly not easily changed by the end user of the closed source software. Of course, there are ways to alleviate pain, but it is not possible to overcome these problems. There is a big difference between the two platforms, not to mention the differences in the origins of many problems.
Please keep in mind that I am not the system that maintains the florist on the street. Microsoft is doing its best to enter the enterprise into Oracle's territory. So what I'm going to talk about is the concerns of an enterprise-class system administrator. What I care about is ...
Because companies need to manage enterprise-class systems (our company is SAP), I prefer to use multiuser (multiuser) databases. Now you may think that I use this term too lightly. There are actually a large number of users using SQL Server in a multiuser environment, aren't they? But do they deal with a large number of concurrent users that are affected by the platform, or whether they are concurrent users? For example, let's look at the problem with the lock (locking). At first, Microsoft tells you that the reader-blocking-writer mechanism is good and safe. It will tell you that this mechanism prevents the user from performing "misreading (Dirty Read)." Don't believe this nonsense; it's just an excuse for low performance. This reminds me of sun's long-standing insistence that the 64-bit system is not a necessary position. There is no need to be present before they sell this product. Next, one day Scott McNealy in front of you to talk about the benefits of growing physical memory addressing.
So what is "wrong reading"? Microsoft will tell you that if someone is updating a row of data and you are ready to read the data row in the update, you will get a misreading. Wrong reading = Bad data-This is what Microsoft wants you to believe. But what happens if an update operation is not committed for a long time? The data is actually not really changed. What happens if that update is rolled back at the end of the transaction? What do the waiting for these readers get? There's nothing.
It's like I'm in a supermarket, standing in front of juice, trying to decide which one to buy. I know I'll choose one, and I know my kids need juice for breakfast tomorrow. I have reached out my hand, but I have not decided which one to take. Last week I bought apple juice, what did I buy last week? White grape juice. I think it's time to buy some sour grape juice. On the other hand, when I'm thinking, you're standing right behind me, and you're probably thinking, "When is this idiot going to get a bottle and don't block me?" I know what I want! "
You'll find that we're all standing in front of Microsoft's grocery store and you have to wait until I make a decision before you can see what you can use. You see the tempting sour grape juice being placed on the shelves, and I might buy it, which is meaningless to you. Because I might just look, but Microsoft knows you want to buy juice, so you have to wait for me to stop wandering or pick something, and this process happens before you get anything.
Will Oracle make you smaller and easier to view data?
In the Oracle shop on the street, you can see what you can use all day, even if I have already checked it, or I am in the process of picking things up. may be more kinds of juice, I may be more small, who knows? In either case, I don't really make a decision, so why don't you look at something? Maybe I'll take the last bottle of sour grape juice, maybe not. But what's the downside to seeing something? You can call your wife and tell her, "I forgot what you wanted, but there's something here ..."
You will find that in Oracle, the reader is concerned that there is no long, persistent data row update. I might modify a data row in memory, even though it has something to do with other people, but the data row will not be updated until I really issue a commit command. In fact, I may not be a very good programmer, and may be able to keep data lines for a long time before submitting them. Or I might decide not to change the record at all, just to roll back the operation. Therefore, there is no data change at all, but at the same time, you can continue your business, whether I am logged into the system, not to mention whether I am doing the update operation. However, once I have modified the data row and issued a commit command, the data row will change, and you will not be able to read the new value until that time. Because until that time the new value was formally present.
You may think this is a very small difference. But I can tell you that it is a crucial one. When you have to support a system that has several concurrent updates to the same range of data tables, if there are always several users querying the data you are working on, you will find that the reader-blocking-writer mechanism will stop the product from working. This is simply not acceptable in an enterprise system.
Maybe we can discuss some other architectural issues later. For example:
· Lock increase due to insufficient memory
· The error data was returned because SQL Server could not support the consistency of read operations
· Time-intensive maintenance transactions similar to DBCC to detect/prevent performance degradation
· Microsoft's "self-regulating" database, in many cases, hinders database management (DBA)
· Regardless of TPC results, SQL Server lacks scalability
Of course, there are more problems to be solved, but it is here today.
