From oracle-l-bounce@freelists.org Mon Mar 29 06:03:26 2004 Return-Path: Received: from air189.startdedicated.com (root@localhost) by orafaq.com (8.11.6/8.11.6) with ESMTP id i2TC3Mk31144 for ; Mon, 29 Mar 2004 06:03:22 -0600 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air189.startdedicated.com (8.11.6/8.11.6) with ESMTP id i2TC3Lo31138 for ; Mon, 29 Mar 2004 06:03:21 -0600 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id AE773634272; Mon, 29 Mar 2004 07:00:09 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25407-30; Mon, 29 Mar 2004 07:00:09 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 9C850634367; Mon, 29 Mar 2004 07:00:08 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Mon, 29 Mar 2004 06:59:02 -0500 (EST) X-Original-To: oracle-l@freelists.org Delivered-To: oracle-l@freelists.org Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 523726342BA for ; Mon, 29 Mar 2004 06:59:02 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25250-16 for ; Mon, 29 Mar 2004 06:59:02 -0500 (EST) Received: from ha-smtp0.tiscali.nl (ha-smtp0.tiscali.nl [195.241.76.186]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 874486342E8 for ; Mon, 29 Mar 2004 06:59:01 -0500 (EST) Received: from LEXLAPTOP (82-168-217-228-bbxl.xdsl.tiscali.nl [82.168.217.228]) by ha-smtp0.tiscali.nl (Postfix) with SMTP id 0A768473D39; Mon, 29 Mar 2004 14:06:57 +0200 (CEST) From: "Lex de Haan" To: , "LazyDBA.com Discussion" Subject: RE: Timesten Vs. Oracle - Performance Date: Mon, 29 Mar 2004 14:06:54 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: X-Virus-Scanned: by amavisd-new at freelists.org X-archive-position: 1965 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: lex.de.haan@naturaljoin.nl Precedence: normal Reply-To: oracle-l@freelists.org X-list: oracle-l X-Virus-Scanned: by amavisd-new at freelists.org I am by no means an expert in this area, but this description immediately triggers "Oracle Streams"... the internal code name for Oracle Streams (during its early development) was "Wall Street Replication". Cheers, Lex. -----Original Message----- From: oracle-l-bounce@freelists.org [mailto:oracle-l-bounce@freelists.org] Sent: maandag 29 maart 2004 12:55 To: oracle-l@freelists.org; LazyDBA.com Discussion Subject: RE: Timesten Vs. Oracle - Performance Folks We are working for a proposal where realtime stock tick data from reuters etc. needs to be streamed into a db and queries to happen on them on realtime basis. the input stream is likely to be around 2000-3000 ticks per second (around 1gb per hr) and the querying will be around 20 mb per hr. The soln is also expected to support failover, high availability etc. Selection of a Suitable Database is the Question. Seek your advise Thanks -----Original Message----- From: John Hallas [mailto:john.hallas@hcresources.co.uk] Sent: Friday, March 26, 2004 3:48 PM To: oracle-l@freelists.org Subject: RE: Timesten Vs. Oracle - Performance Justin Cave wrote If you have a small, read-only or read-mostly database where you can afford to lose updates, an in-memory database is probably ideal. Otherwise, stick with the traditional database. TimesTen is supposed to guarantee no loss of data under certain configurations. However that is balanced by the requirement to have 2 copies running and the probability of having to load a backup copy and then apply the journal. From what I have seen TT is very memory and CPU intensive. It is used to hold mostly reference data so it is read-mostly in our environment. A small read-only Oracle database that is well optimised, on fast disk and with plenty of memory/cache available should be able to perform pretty well anyway. John -----Original Message----- From: Cary Millsap [mailto:cary.millsap@hotsos.com] Sent: Friday, March 26, 2004 12:19 PM To: oracle-l@freelists.org Subject: RE: Timesten Vs. Oracle - Performance I marvel at the in-memory database vendors' messages, because many of the performance-challenged user actions I see on Oracle databases ARE operating entirely in memory. The reason they're slow is that they perform too many accesses upon the buffer cache. This stuff about TB of Oracle buffer cache making "Oracle tuning a thing of the past" is absolute rubbish. See "Why you should focus on LIOs instead of PIOs" at www.hotsos.com/e-library for details. I don't see how the in-memory guys could be doing any better than a reasonably well-optimized Oracle system, unless they're bypassing all the "horrible serialization operations" that an Oracle instance executes. Thing is, without those serialization operations, a system can't provide, for example, read consistency or recoverability. One aspect of the F1 vs Tank analogy that I really like is that a Formula 1 car is a single-user automobile. I think an analogy I like better is F1 vs B-747. It probably works on a lot of different levels: multi-user-ness, procurement and operational maintenance cost, storage capacity, range, ... :) Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com * Nullius in verba * Upcoming events: - Performance Diagnosis 101: 4/6 Seattle, 5/7 Dallas, 5/18 New Jersey - SQL Optimization 101: 3/29 Dallas, 4/19 Denver, 5/3 Boston, 5/24 San Diego - Hotsos Symposium 2005: March 6-10 Dallas - Visit www.hotsos.com for schedule details... ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------