On Fri, 23 Jun 2000, Dave hardy wrote:
> Thanks.
>
> Large=an Oracle db that will handle all of the state's insurance agent and licensing
>data, increasing OLTP, much of the state's health care rates and forms data, consumer
>complaint data, and eventually all of the state's Medicare/Managed Care and hospital
>discharge data. Probably some web access to some of this as well.
>
> Uptime=08:00-18:00 M-F, tops, for the forseeable future.
>
> There is no current database per se for all of this data; it's broken up amongst
>Access, Paradox and vanilla ASCII at present.
>
> Training and resources are somewhat limited, although initially there is a good
>budget for this.
>
> The vendor prefers to support Solaris, as that is where their o.s. 'expertise' is,
>although they will also support NT, not their preferred platform, however. As for
>Linux, they do not have any expertise in it, and as for other UNIX platforms they do
>not have a test environment for them and have not tested with any of them as yet, so
>their support for any of these other products would not be 'in depth' and would,
>rather, be 'limited.'
>
> The people involved primarily with this decision appear not to be overly concerned
>about the vendor's level of support for the o.s. and would presumably ramp up
>training for at least a couple of individuals to handle that part of it.
>
> What we have here is a possibility of tilting some folks a little further over to
>Open Source and community support, and away from M$ and NetWare.
>
>
Well, Unix is Unix (OK, not quite, there are differences), from an
admin level you'll see a lot the same (I'd guess 90% of what you need
to learn to admin one unix carries over to another, including Linux).
If they run it on NT, they are familiar with Intel hardware. Porting
probably isn't a problem, unless they are using some Solaris features,
it should port easily. The advantage is that you don't have to buy
Sun boxes, but can use intel platforms (emphasize $ saved for your
decisionmakers). Part of it will be the scalability - this sounds
like a lot of data in the long term. I also wonder how much of it
needs to go into one database, or could it be separate dbs? (one
question: are you building a data warehouse, or will this be for
transactional systems, or both? The database design requirements are
very different, & I normally recommend separating the two, with a feed
from the transactional to the warehouse (and to the reporting dbs,
whihc are another set of requirements). Depending on scalability
requirements, Linux isn't up with the commercial unices yet.
OS Support: Well, there's a couple of different things here:
1. Administration - that's probably you guys, with training
2. Application support on the OS - the vendor, obviously
3. Support of the OS. Unfortunately, no OS is bug-free (Linux is
getting closer, but not there yet). What are the plans if there is a
problem in the OS? Will you have people who can patch it? What kind
of down-time can you take? Depending on requirements, skills, &
management "need" to have someone to blame (vs someone to fix the
problem, which is the real question) it will vary in terms of how you
want to do this.
jeff
------------------------------------------------------------------------
Jeffry Smith Technical Sales Consultant Mission Critical Linux
[EMAIL PROTECTED] phone:603.930.9379 fax:978.446.9470
------------------------------------------------------------------------
Thought for today: The meek shall inherit the earth -- they are too weak to refuse.
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
