|
|
|
|
|
|
|
|
|
|
|
Oracle's Response (8)
|
|
|
32. This is incorrect. see 27 & 28. |
|
|
|
#32 is about needless rollback segments for index creation. This is still correct for all versions of Oracle, even for Oracle 9i, when you create an index without the "parallel nologging unrecoverable" option. |
|
 |
|
|
|
|
|
| 33. This is incorrect. You get the normal "failed to extend segment <x> by <size> in tablespace <t>" error in 8.1.7, and there are no rollback segments in 9i. |
|
|
My Oracle instance was 8.1.7. Oracle normally reports running out of space as Mr. Conway says, but it is not consistent. When I was creating an index, Oracle 8.1.7 did not report the problem. The rollback segment which ran out of space, was the rollback segment on the tablespace that Oracle was using to temporarily sort the data for the index. My process was just hanging there. I decided to look at the alert log and saw the disk space problem. Mr. Conway needs to check out comp.database.oracle. Others have the same problem. |
|
|
 |
|
|
|
|
|
|
| 34. This is incorrect. You can create a function-based index that implements dictionary order. Can Sybase create a user-defined function index? |
|
|
Though Oracle cannot implement dictionary order automatically like Sybase, you can create an index based on a function. The create index example in the 9i SQL reference uses the UPPER() function. This solves the dictionary order problem, but it leaves the more serious comparison problem. In order to make Oracle treat "Your Name" equal to "YOUR NAME" in a lookup, you must have an additional column in your table identical to your string column but just for the upper case equivalent of your string column.
I also have to ask whether I ever needed a function-based index. I have never needed one using Sybase for 10 years. However I would have to use it in Oracle in lieu of that fact that dictionary ordering doesn't exist in the first place. For Sybase, one could achieve function-based indexes using CIS and Open Server. But that would too complex for 99% of programmers. |
|
|
|
|
|
| 35. This is incorrect. It makes a backup copy, tnsnames.001, tnsnames.002, etc. |
|
|
My complaint was that Oracle's network assistant program deletes the tnsnames file when you answer "Discard changes?" with "Yes." Not only does it discard your changes, but also it deletes your whole file. I guess Mr. Conway will have to talk to Oracle DBAs other than me. I am not making this stuff up. The version of Oracle was something like 8.1.5 on Solaris. When I asked Engage's resident Oracle fan about this, he smiled and said, "That is why I always make a copy of the file before I run any Oracle program." That was a statement from an Oracle fan! Oracle fans expect this stuff to happen. It is normal for Oracle. |
|
|
|
|
|
| 36/37. Use the DB Configuration assistant, save the scripts, and all the scripts to create the database run. |
|
|
Mr. Conway did not read everything I had said. I ran dbassist to configure a new instance. The dbassist program aborted because of an error I made. (I didn't make a disk partition big enough to hold a tablespace.) I did save dbassist's scripts. After I increased the partition size, I tried to run those scripts. The scripts crashed.
DBassist left the directories in a state where the scripts would not run. Directories and files left over from dbassist were present which the script did not want to see. Other directories and files the scripts required but dbassist had deleted them. It was obvious that the scripts checked nothing. DBassist simply didn't check preconditions nor did it clean up after itself. |
|
|
|
|
|
| 38. Pretty petty. How many times do you install a database incorrectly? |
|
|
I changed question #38 since Mr. Conway's answer, but I'll answer his question anyway. It generally takes me up to 3 attempts to install a new version of Oracle correctly. I think I've seen only one Oracle install go right the first time. (A Windows install.) I have never seen Oracle install right the first time on Solaris. Many times there are errors in the installation screens themselves. For example, in 9i, Oracle says MB but means KBs. Every time there are 100s of stored procedures and objects that Oracle fails to create. Despite those failures, Oracle says, "Installation successful." Later you find out that some basic PL/SQL packages didn't install. You have to go back and manually install them. And then, God forbid, do not have any Oracle processes running while you try to configure a new instance. The installation will crash because Oracle was stupid enough to use the same shared-memory segment names in some underlying installation process as other instances.
There are a million possible problems that can happen when installing Oracle. There is a 99.9% chance the DBA will get hit by at least one. 80% of the problems are Oracle not checking the input parameters. The remaining 20% come from Oracle's underlying scripts not working. After the instance comes up, one usually has to fix it. As for the time it takes to install Oracle instances, I have seen good computer people take 3 days to 2 weeks attempting to install Oracle. Some just give up. If I installed an instance every day, I could get the time down to about 2 hours (not including waiting for Oracle to initialize tablespaces). But for a new version of Oracle, it takes about a 2 days of my full attention. 90% of that time I spend getting accustomed to and finding work-arounds to Oracle's new batch of problems.
New versions of Sybase, on the other hand, take me 30 minutes to install. If I misname a disk device, Sybase tells me up front. Sybase doesn't wait 5 hours into the process to bomb out and then tell me "Installation successful." If Sybase has a problem with insufficient memory, disk areas, or anything, it tells me immediately. 99% of the time, Sybase installs correctly the first time. The other 1% is easily fixed because Sybase tells me what went wrong. And there is never, ever, a problem in their underlying scripts. I have never seen a single botch-up in 11 years. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
