Re: flagship sunk

Double Echo wrote: > Serge Rielau wrote: > >> Double Echo, I think the point made is that apparently Oracle also >> realizes that one DBMS is not good enough to cover the whole market. >> Oracle has at least 4 DBMS: RDB, Times10, Oracle 10g and their mobile >> devices DBMS whichever it's name is (Oracle Light??). >> RDB may be the odd one out, but the others clearly cater to different >> markets. >> > > The point is, IDS is _not_ a realtime database, nor is it an in-memory > database. The closest thing to TimesTen would be MySQL's NDB database > engine. Interesting that Oracle bought InnoDB, could be that we'll see > NDB disappear too. That would be unfortunate, but the point is, IDS has > little if anything in common with TimesTen. They are two different > products. > > From the spec "Oracle TimesTen In-Memory Database. (PDF)" on http://www.oracle.com/database/timesten.html, it takes 36 microseconds for an insert ~ 27,778 inserts per second. IDS with Real Time Load does 60,000 inserts per second with simultaneously queries http://www.ibm.com/software/data/informix/foundations/finance/ The Swedish Meteorological Institute loads one million weather data per second and creates weather forecasts at the same time using IDS. A weatherdata consists of a coordinate, altitute, timestamp, temperature, humidity, wind speed, wind direction, pressure and more.

Claus Samuelsen wrote: > > From the spec "Oracle TimesTen In-Memory Database. (PDF)" on > http://www.oracle.com/database/timesten.html, it takes 36 microseconds > for an insert ~ 27,778 inserts per second. > > IDS with Real Time Load does 60,000 inserts per second with > simultaneously queries > http://www.ibm.com/software/data/informix/foundations/finance/ > > The Swedish Meteorological Institute loads one million weather data per > second and creates weather forecasts at the same time using IDS. A > weatherdata consists of a coordinate, altitute, timestamp, temperature, > humidity, wind speed, wind direction, pressure and more. I think you will find that generally it's not necessarily valid to compare data load times with data insert times. For the Real Time Load, and also for the Swedish Meteorological Instititue, what process is actually storing the data on disk somewhere so that it can later be loaded ? It's that process that may be a more valid comparison.

Mark Townsend said: > > Claus Samuelsen wrote: > >> From the spec "Oracle TimesTen In-Memory Database. (PDF)" on >> http://www.oracle.com/database/timesten.html, it takes 36 microseconds >> for an insert ~ 27,778 inserts per second. >> >> IDS with Real Time Load does 60,000 inserts per second with >> simultaneously queries >> http://www.ibm.com/software/data/informix/foundations/finance/ >> >> The Swedish Meteorological Institute loads one million weather data per >> second and creates weather forecasts at the same time using IDS. A >> weatherdata consists of a coordinate, altitute, timestamp, temperature, >> humidity, wind speed, wind direction, pressure and more. > > I think you will find that generally it's not necessarily valid to > compare data load times with data insert times. For the Real Time Load, > and also for the Swedish Meteorological Instititue, what process is > actually storing the data on disk somewhere so that it can later be > loaded ? It's that process that may be a more valid comparison. What ARE you blathering on about? -- Bye now, Obnoxio "C'est pas parce qu'on n'a rien ' dire qu'il faut fermer sa gueule" - Coluche did i mention i like nulls? heck, i even go so far as to say that all columns in a table except the primary key could/should be nullable. this has certain advantages, for example, if you need to insert a child record and you don't have a parent row for it, just do an insert into the parent table with the primary key value (everything else null), and voila, relational integrity is preserved. but this is, admittedly, a bit controversial among modellers. --r937, dbforums.com

Claus Samuelsen wrote: > From the spec "Oracle TimesTen In-Memory Database. (PDF)" on > http://www.oracle.com/database/timesten.html, it takes 36 microseconds > for an insert ~ 27,778 inserts per second. > > IDS with Real Time Load does 60,000 inserts per second with > simultaneously queries > http://www.ibm.com/software/data/informix/foundations/finance/ SQL*Plus: Release 10.2.0.1.0 - Production on Mon Feb 6 08:51:41 2006 Copyright (c) 1982, 2005, Oracle. All rights reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production With the Partitioning, OLAP and Data Mining options SQL> CREATE TABLE parent ( 2 part_num NUMBER(10), 3 part_name VARCHAR2(15)); Table created. SQL> SQL> CREATE TABLE child AS 2 SELECT * 3 FROM parent 4 WHERE 1=2; Table created. SQL> DECLARE 2 j PLS_INTEGER := 1; 3 k parent.part_name%TYPE := 'Transducer'; 4 BEGIN 5 FOR i IN 1 .. 20000 6 LOOP 7 SELECT DECODE(k, 'Transducer', 'Rectifier', 8 'Rectifier', 'Capacitor', 9 'Capacitor', 'Knob', 10 'Knob', 'Chassis', 11 'Chassis', 'Transducer') 12 INTO k 13 FROM dual; 14 15 INSERT INTO parent VALUES (j+i, k); 16 END LOOP; 17 COMMIT; 18 END; 19 / PL/SQL procedure successfully completed. SQL> SELECT COUNT(*) FROM parent; COUNT(*) ---------- 20000 SQL> SELECT COUNT(*) FROM child; COUNT(*) ---------- 0 SQL> CREATE OR REPLACE PROCEDURE fast_way IS 2 3 TYPE myarray IS TABLE OF parent%ROWTYPE; 4 l_data myarray; 5 6 CURSOR r IS 7 SELECT part_num * 10, part_name 8 FROM parent; 9 10 BEGIN 11 OPEN r; 12 LOOP 13 FETCH r BULK COLLECT INTO l_data LIMIT 1000; 14 15 FORALL i IN 1..l_data.COUNT 16 INSERT INTO child VALUES l_data(i); 17 18 EXIT WHEN r%NOTFOUND; 19 END LOOP; 20 COMMIT; 21 CLOSE r; 22 END fast_way; 23 / Procedure created. SQL> set timing on SQL> exec fast_way PL/SQL procedure successfully completed. Elapsed: 00:00:00.10 SQL> SELECT COUNT(*) FROM child; COUNT(*) ---------- 20000 That's 20,000 records in 1/10th of a second on my pathetic little IBM G40 ThinkPad with its single 7500 RPM drive from a cold boot with nothing cached in memory. I don't know where your numbers are coming from but perhaps there are a few tuning issues that need to be addressed. -- Daniel A. Morgan http://www.psoug.org damorgan@x.washington.edu (replace x with u to respond)

Obnoxio The Clown wrote: >>I think you will find that generally it's not necessarily valid to >>compare data load times with data insert times. For the Real Time Load, >>and also for the Swedish Meteorological Instititue, what process is >>actually storing the data on disk somewhere so that it can later be >>loaded ? It's that process that may be a more valid comparison. > > > What ARE you blathering on about? If you don't know then perhaps you should consider a change of profession. ;-) -- Daniel A. Morgan http://www.psoug.org damorgan@x.washington.edu (replace x with u to respond)

DA Morgan said: > > Claus Samuelsen wrote: > >> From the spec "Oracle TimesTen In-Memory Database. (PDF)" on >> http://www.oracle.com/database/timesten.html, it takes 36 microseconds >> for an insert ~ 27,778 inserts per second. > > I don't know where your numbers are coming from but perhaps there are a > few tuning issues that need to be addressed. Perhaps if I trimmed the original post to its salient points for you...? -- Bye now, Obnoxio "C'est pas parce qu'on n'a rien ' dire qu'il faut fermer sa gueule" - Coluche did i mention i like nulls? heck, i even go so far as to say that all columns in a table except the primary key could/should be nullable. this has certain advantages, for example, if you need to insert a child record and you don't have a parent row for it, just do an insert into the parent table with the primary key value (everything else null), and voila, relational integrity is preserved. but this is, admittedly, a bit controversial among modellers. --r937, dbforums.com

DA Morgan said: > > Obnoxio The Clown wrote: > >>>I think you will find that generally it's not necessarily valid to >>>compare data load times with data insert times. For the Real Time Load, >>>and also for the Swedish Meteorological Instititue, what process is >>>actually storing the data on disk somewhere so that it can later be >>>loaded ? It's that process that may be a more valid comparison. >> >> >> What ARE you blathering on about? > > If you don't know then perhaps you should consider a change of > profession. ;-) Yes, perhaps I should become an Oracle marketer. -- Bye now, Obnoxio "C'est pas parce qu'on n'a rien ' dire qu'il faut fermer sa gueule" - Coluche did i mention i like nulls? heck, i even go so far as to say that all columns in a table except the primary key could/should be nullable. this has certain advantages, for example, if you need to insert a child record and you don't have a parent row for it, just do an insert into the parent table with the primary key value (everything else null), and voila, relational integrity is preserved. but this is, admittedly, a bit controversial among modellers. --r937, dbforums.com

DA Morgan wrote: > Claus Samuelsen wrote: > >> From the spec "Oracle TimesTen In-Memory Database. (PDF)" on >> http://www.oracle.com/database/timesten.html, it takes 36 microseconds >> for an insert ~ 27,778 inserts per second. >> >> IDS with Real Time Load does 60,000 inserts per second with >> simultaneously queries >> http://www.ibm.com/software/data/informix/foundations/finance/ > > > SQL*Plus: Release 10.2.0.1.0 - Production on Mon Feb 6 08:51:41 2006 > > Copyright (c) 1982, 2005, Oracle. All rights reserved. > > > Connected to: > Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production > With the Partitioning, OLAP and Data Mining options > > SQL> CREATE TABLE parent ( > 2 part_num NUMBER(10), > 3 part_name VARCHAR2(15)); > > Table created. No primary key constraint, no index? tsk, tsk > > SQL> > SQL> CREATE TABLE child AS > 2 SELECT * > 3 FROM parent > 4 WHERE 1=2; > > Table created. Cute way to copy a table schema ! > > SQL> DECLARE > 2 j PLS_INTEGER := 1; > 3 k parent.part_name%TYPE := 'Transducer'; What an ugly syntax > 4 BEGIN > 5 FOR i IN 1 .. 20000 > 6 LOOP > 7 SELECT DECODE(k, 'Transducer', 'Rectifier', > 8 'Rectifier', 'Capacitor', > 9 'Capacitor', 'Knob', > 10 'Knob', 'Chassis', > 11 'Chassis', 'Transducer') > 12 INTO k > 13 FROM dual; > 14 > 15 INSERT INTO parent VALUES (j+i, k); > 16 END LOOP; > 17 COMMIT; > 18 END; > 19 / > > PL/SQL procedure successfully completed. > > SQL> SELECT COUNT(*) FROM parent; > > COUNT(*) > ---------- > 20000 > > SQL> SELECT COUNT(*) FROM child; > > COUNT(*) > ---------- > 0 > > SQL> CREATE OR REPLACE PROCEDURE fast_way IS > 2 > 3 TYPE myarray IS TABLE OF parent%ROWTYPE; > 4 l_data myarray; > 5 > 6 CURSOR r IS > 7 SELECT part_num * 10, part_name > 8 FROM parent; > 9 > 10 BEGIN > 11 OPEN r; > 12 LOOP > 13 FETCH r BULK COLLECT INTO l_data LIMIT 1000; > 14 > 15 FORALL i IN 1..l_data.COUNT > 16 INSERT INTO child VALUES l_data(i); > 17 > 18 EXIT WHEN r%NOTFOUND; > 19 END LOOP; > 20 COMMIT; > 21 CLOSE r; > 22 END fast_way; > 23 / > > Procedure created. > > SQL> set timing on > SQL> exec fast_way > > PL/SQL procedure successfully completed. > > Elapsed: 00:00:00.10 > SQL> SELECT COUNT(*) FROM child; > > COUNT(*) > ---------- > 20000 > > That's 20,000 records in 1/10th of a second on my pathetic little IBM > G40 ThinkPad with its single 7500 RPM drive from a cold boot with > nothing cached in memory. Now here you are really wrong. The only data not cached must be the data in the table dual. I don't have deep inside knowledge of 10g, but I presume that it has a caching mechanism. So after inserting 20,000 rows in table parent, data should all be cached. Or perhaps you feel that the G40 is pathetic, because you've removed the RAM? > > I don't know where your numbers are coming from but perhaps there are a > few tuning issues that need to be addressed. Well, if you cannot read plain english and follow the URLs I can't help you. Click and read.

Obnoxio The Clown wrote: >>DA Morgan said: >>> Obnoxio The Clown wrote: >>>> Mark Townsend postulated: >>>> I think you will find that generally it's not necessarily valid to >>>> compare data load times with data insert times. For the Real Time Load, >>>> and also for the Swedish Meteorological Instititue, what process is >>>> actually storing the data on disk somewhere so that it can later be >>>> loaded ? It's that process that may be a more valid comparison. >>> >>> What ARE you blathering on about? >>> >> If you don't know then perhaps you should consider a change of >> profession. ;-) > > Yes, perhaps I should become an Oracle marketer. > Daniel I can picture you on your little bicycle, with monkey perched on your head, chasing after the big clown in his mini... whooo-hooo! ( I haven't stopped laughing on this one *<8o)

Claus Samuelsen wrote: >> SQL> CREATE TABLE parent ( >> 2 part_num NUMBER(10), >> 3 part_name VARCHAR2(15)); >> >> Table created. > > No primary key constraint, no index? tsk, tsk Good point for anything other than a demo ... but by definition the SQL statement calls for a full table scan. Any index would be ignored. >> SQL> CREATE TABLE child AS >> 2 SELECT * >> 3 FROM parent >> 4 WHERE 1=2; >> >> Table created. > > Cute way to copy a table schema ! Someone will be pleased. ;-) >> SQL> DECLARE >> 2 j PLS_INTEGER := 1; >> 3 k parent.part_name%TYPE := 'Transducer'; > > What an ugly syntax Not sure you understand it as it is a thing of great beauty. What is says is that the variable "k" is dynamically created at runtime to match the data type and size of a specific column in a specific table. If the table is altered the code still runs flawlessly. >> That's 20,000 records in 1/10th of a second on my pathetic little IBM >> G40 ThinkPad with its single 7500 RPM drive from a cold boot with >> nothing cached in memory. > > Now here you are really wrong. The only data not cached must be the data > in the table dual. I don't have deep inside knowledge of 10g, but I > presume that it has a caching mechanism. So after inserting 20,000 rows > in table parent, data should all be cached. Or perhaps you feel that the > G40 is pathetic, because you've removed the RAM? >> I don't know where your numbers are coming from but perhaps there are a >> few tuning issues that need to be addressed. > > Well, if you cannot read plain english and follow the URLs I can't help > you. Click and read. Oh I can both read and click on links. I also know that while Oracle published TAF failover times of 10 seconds I was getting subsecond failovers in my lab. So my guess is that the number published was the number approved by legal giving a huge margin for error on the worst hardware platform the product would support. And based on the TimesTen database I have installed in my lab I think the numbers published so low as to be laughable. -- Daniel A. Morgan http://www.psoug.org damorgan@x.washington.edu (replace x with u to respond)

DA Morgan said: > > Claus Samuelsen wrote: > >>> SQL> CREATE TABLE parent ( >>> 2 part_num NUMBER(10), >>> 3 part_name VARCHAR2(15)); >>> >>> Table created. >> >> No primary key constraint, no index? tsk, tsk > > Good point for anything other than a demo ... but by definition the SQL > statement calls for a full table scan. Any index would be ignored. Yeah, but an index would slow down load times, wouldn't it? Which is what we're talking about, after all. -- Bye now, Obnoxio "C'est pas parce qu'on n'a rien ' dire qu'il faut fermer sa gueule" - Coluche did i mention i like nulls? heck, i even go so far as to say that all columns in a table except the primary key could/should be nullable. this has certain advantages, for example, if you need to insert a child record and you don't have a parent row for it, just do an insert into the parent table with the primary key value (everything else null), and voila, relational integrity is preserved. but this is, admittedly, a bit controversial among modellers. --r937, dbforums.com