OLTP vs Reporting Database vs OLAP Database

Dear All,
I have a fundamental questions regarding my design of my SQL Server
Database.
Current SQL Server 2000 Design Setting (in one server)
-1 Database for OLTP
-1 Database for OLAP -> Generating Cubes
Planned SQL Server 2000 Design Setting (in two servers):
-1 Database for OLTP -> at Server A
-1 Database for Reporting Purposes -> at Server B
-1 Database for OLAP -> at Server B
My Question -> Is it necessary to separate reporting database and OLAP
database?
Any sugestion please.
Thanks
Robert Lieif you want to provide reports based on a copy of your OLTP database, so you
can create a "read-only" database optimized for reporting purpose.
you can provide (near)real time reports.
this usage as an advantage: you don't impat you operationnal server by
executing complex queries. but.. garbage in garbage out...
if you want to have a common and cleansed database for both reporting and
analysis to insure that you'll allways display the same information, use the
same database for RS + OLAP. but, generally, this database in not real-time
updated.
so what is your primary usage for your reports?
- operationnal purpose
- analytical purpose
but you can also provide reports based on the 2 databases regarding the
performance of your queries.
if you have some performance problems with your OLTP database (the copy on
the server B) then the OLAP database and cubes will improove the response
time.
also, look at the number of users... 100 users on a 10seconds report vs 100
users on a 1second report...
"Robert Lie" <robert.lie24@.gmail.com> wrote in message
news:uD8T74gSFHA.2520@.TK2MSFTNGP09.phx.gbl...
> Dear All,
> I have a fundamental questions regarding my design of my SQL Server
> Database.
> Current SQL Server 2000 Design Setting (in one server)
> -1 Database for OLTP
> -1 Database for OLAP -> Generating Cubes
> Planned SQL Server 2000 Design Setting (in two servers):
> -1 Database for OLTP -> at Server A
> -1 Database for Reporting Purposes -> at Server B
> -1 Database for OLAP -> at Server B
> My Question -> Is it necessary to separate reporting database and OLAP
> database?
> Any sugestion please.
> Thanks
> Robert Lie|||Here my considerations
1. Reporting Database:
- To provide operational reports with 10 minutes delay.
- Not Disturbing OLTP Server
- Incrase response time for users who access reports (estimation
max 20 users in the same time)
2. OLAP Database:
- To generate Cubes
- To boost the Cubes generation performance since it won't
affected by users who access reports.
- For analytical purpose
And both of them are not real-time.
Please explain further about garbage in garbage out?
So what do you think of my considerations?
Thanks a lot
Robert Lie
Jj wrote:
> if you want to provide reports based on a copy of your OLTP database, so y
ou
> can create a "read-only" database optimized for reporting purpose.
> you can provide (near)real time reports.
> this usage as an advantage: you don't impat you operationnal server by
> executing complex queries. but.. garbage in garbage out...
> if you want to have a common and cleansed database for both reporting and
> analysis to insure that you'll allways display the same information, use t
he
> same database for RS + OLAP. but, generally, this database in not real-tim
e
> updated.
> so what is your primary usage for your reports?
> - operationnal purpose
> - analytical purpose
> but you can also provide reports based on the 2 databases regarding the
> performance of your queries.
> if you have some performance problems with your OLTP database (the copy on
> the server B) then the OLAP database and cubes will improove the response
> time.
> also, look at the number of users... 100 users on a 10seconds report vs 10
0
> users on a 1second report...
>
> "Robert Lie" <robert.lie24@.gmail.com> wrote in message
> news:uD8T74gSFHA.2520@.TK2MSFTNGP09.phx.gbl...
>
>
>|||creating a copy of the OLTP database is good choice
you can use the log shipping function to do this (or other methods)
(how do you plan to synchronize your databases?)
generating cubes will not lock your database if you do incremental updates
on a optimized cube. (or just a litlle lock)
Partitions will help you for the cube process step.
But your design appear to be good.
garbage in garbage out = bad data quality in the source = bad quality in
output (non existant clientID, duplicated product name, duplicated
records...). so an ETL tool can improove the data quality during the
process. or if you want to synchronize multiple sources (like reference
tables and operationnal tables)
But these steps reduce the loading time by adding data cleansing time.
if you think next step (which is SQL 2005) you'll have a lot of new features
to help you.
for example, you will be able to load directly a partition of your cube
while you'll load your database, so 1 read and 2 destinations
(and there is a lot of options)
"Robert Lie" <robert.lie24@.gmail.com> wrote in message
news:%23RX3SehSFHA.248@.TK2MSFTNGP15.phx.gbl...[vbcol=seagreen]
> Here my considerations
> 1. Reporting Database:
> - To provide operational reports with 10 minutes delay.
> - Not Disturbing OLTP Server
> - Incrase response time for users who access reports (estimation
> max 20 users in the same time)
> 2. OLAP Database:
> - To generate Cubes
> - To boost the Cubes generation performance since it won't affected by
> users who access reports.
> - For analytical purpose
> And both of them are not real-time.
> Please explain further about garbage in garbage out?
> So what do you think of my considerations?
> Thanks a lot
> Robert Lie
>
> Jj wrote:|||Actually what I want to do is not just copy the OLTP Database, but DTS
from OLTP tables to summaries form Tables to eliminate the join and
complex calculation when show up some reports.
-> What do you think?
Since my SQL Server 2000 is standard edition so I can't do a kind of
cube partition.
Thanks
Jj wrote:
> creating a copy of the OLTP database is good choice
> you can use the log shipping function to do this (or other methods)
> (how do you plan to synchronize your databases?)
> generating cubes will not lock your database if you do incremental updates
> on a optimized cube. (or just a litlle lock)
> Partitions will help you for the cube process step.
> But your design appear to be good.
> garbage in garbage out = bad data quality in the source = bad quality in
> output (non existant clientID, duplicated product name, duplicated
> records...). so an ETL tool can improove the data quality during the
> process. or if you want to synchronize multiple sources (like reference
> tables and operationnal tables)
> But these steps reduce the loading time by adding data cleansing time.
> if you think next step (which is SQL 2005) you'll have a lot of new featur
es
> to help you.
> for example, you will be able to load directly a partition of your cube
> while you'll load your database, so 1 read and 2 destinations
> (and there is a lot of options)
> "Robert Lie" <robert.lie24@.gmail.com> wrote in message
> news:%23RX3SehSFHA.248@.TK2MSFTNGP15.phx.gbl...
>
>