Billing users

We have a mssql hotel with our clients databases of various sizes. Our problem is our to bill these clients in a fair way to cover the total cost of maintaining the database server. I will appreciate any suggestion. Thanks in advance!
There aren't charge back mechanisms built in to SQL Server as you know.
You'll need to do the work based on sampling of some kind and come up with a
formula that you think is decent for your needs.
Take a look at the columns in master..sysprocesses and see what's of
interest to bill by.
Some people I've chatted with bill primarily based on IO and IO is easy to
track on a file level by using fn_virtualfilestats.
You would think that tracking by IO is not representative. But in many ways,
disk is the most expensive part of most server configurations and it's easy
to track on a pretty reliable way with the above function...
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"Bamyz" <anonymous@.discussions.microsoft.com> wrote in message
news:D6BBBA2F-0274-40CB-BF9B-5EB4667C376D@.microsoft.com...
> We have a mssql hotel with our clients databases of various sizes. Our
problem is our to bill these clients in a fair way to cover the total cost
of maintaining the database server. I will appreciate any suggestion. Thanks
in advance!
|||Thanks very much Brian and have a happy easter!

Billing users

We have a mssql hotel with our clients databases of various sizes. Our problem is our to bill these clients in a fair way to cover the total cost of maintaining the database server. I will appreciate any suggestion. Thanks in advance!There aren't charge back mechanisms built in to SQL Server as you know.
You'll need to do the work based on sampling of some kind and come up with a
formula that you think is decent for your needs.
Take a look at the columns in master..sysprocesses and see what's of
interest to bill by.
Some people I've chatted with bill primarily based on IO and IO is easy to
track on a file level by using fn_virtualfilestats.
You would think that tracking by IO is not representative. But in many ways,
disk is the most expensive part of most server configurations and it's easy
to track on a pretty reliable way with the above function...
--
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"Bamyz" <anonymous@.discussions.microsoft.com> wrote in message
news:D6BBBA2F-0274-40CB-BF9B-5EB4667C376D@.microsoft.com...
> We have a mssql hotel with our clients databases of various sizes. Our
problem is our to bill these clients in a fair way to cover the total cost
of maintaining the database server. I will appreciate any suggestion. Thanks
in advance!|||Thanks very much Brian and have a happy easter!

Billing users

We have a mssql hotel with our clients databases of various sizes. Our probl
em is our to bill these clients in a fair way to cover the total cost of mai
ntaining the database server. I will appreciate any suggestion. Thanks in ad
vance!There aren't charge back mechanisms built in to SQL Server as you know.
You'll need to do the work based on sampling of some kind and come up with a
formula that you think is decent for your needs.
Take a look at the columns in master..sysprocesses and see what's of
interest to bill by.
Some people I've chatted with bill primarily based on IO and IO is easy to
track on a file level by using fn_virtualfilestats.
You would think that tracking by IO is not representative. But in many ways,
disk is the most expensive part of most server configurations and it's easy
to track on a pretty reliable way with the above function...
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"Bamyz" <anonymous@.discussions.microsoft.com> wrote in message
news:D6BBBA2F-0274-40CB-BF9B-5EB4667C376D@.microsoft.com...
> We have a mssql hotel with our clients databases of various sizes. Our
problem is our to bill these clients in a fair way to cover the total cost
of maintaining the database server. I will appreciate any suggestion. Thanks
in advance!|||Thanks very much Brian and have a happy easter!

Beware of ipowerweb - They are TERRIBLE!

Beware of ipowerweb
Their billing team made a mistake and thought that I did not pay.
Without sending me a notice they took the server from me.
After they understood the mistake they gave me another server, but it is
empty, and they say that they deleted the files.
They are TERRIBLE!!!
Gil Teva
www.donkey.co.il
Ipowerweb customer 2557939495
Sounds like a good lawyer could be useful in this situation.
"Gil Teva" <gilteva@.actcom.net.il> wrote in message
news:411de50f@.news.barak.net.il...
> Beware of ipowerweb
> Their billing team made a mistake and thought that I did not pay.
> Without sending me a notice they took the server from me.
> After they understood the mistake they gave me another server, but it is
> empty, and they say that they deleted the files.
> They are TERRIBLE!!!
> Gil Teva
> www.donkey.co.il
> Ipowerweb customer 2557939495
>

Beware of ipowerweb - They are TERRIBLE!

Beware of ipowerweb
Their billing team made a mistake and thought that I did not pay.
Without sending me a notice they took the server from me.
After they understood the mistake they gave me another server, but it is
empty, and they say that they deleted the files.
They are TERRIBLE!!!
Gil Teva
www.donkey.co.il
Ipowerweb customer 2557939495Sounds like a good lawyer could be useful in this situation.
"Gil Teva" <gilteva@.actcom.net.il> wrote in message
news:411de50f@.news.barak.net.il...
> Beware of ipowerweb
> Their billing team made a mistake and thought that I did not pay.
> Without sending me a notice they took the server from me.
> After they understood the mistake they gave me another server, but it is
> empty, and they say that they deleted the files.
> They are TERRIBLE!!!
> Gil Teva
> www.donkey.co.il
> Ipowerweb customer 2557939495
>

Best way to setup data structure

I have an online application that works and functions like an accounting,
payroll, scheduliing and billing system. In the past, each center that
signed up would be setup in thier own database on SQL 2000. As this grows
more and more multisite organizations are using this service. It will
possible to have one organization with 2,000 centers using this service. My
question is: Should I continue setting up individual databases for each
center or should I combine the 2,000 centers for the one company into one
database and have a center key to distinguse the data. The only issue with
the mulit sites are reporting across the 2,000 or so centers. 95% of the
application is center specific the only time the data needs to be combined is
for some reports that are company wide.
Thanks,
Mark
Hi
I would do one database, but it depends on how well normalised the Db is and
what a stress test would show up.
Managing 2000 DB's becomes a nightmare.
How big ar the DB's and how big do you expect them to grow?
Regards
Mike
"Mark" wrote:

> I have an online application that works and functions like an accounting,
> payroll, scheduliing and billing system. In the past, each center that
> signed up would be setup in thier own database on SQL 2000. As this grows
> more and more multisite organizations are using this service. It will
> possible to have one organization with 2,000 centers using this service. My
> question is: Should I continue setting up individual databases for each
> center or should I combine the 2,000 centers for the one company into one
> database and have a center key to distinguse the data. The only issue with
> the mulit sites are reporting across the 2,000 or so centers. 95% of the
> application is center specific the only time the data needs to be combined is
> for some reports that are company wide.
> Thanks,
> Mark
|||The databse is normalized and where it is not, we are in the process of
fixing that now. The database size after 2 years of use is about 3 gigs - I
would imagine each database could grow to 10 gigs a piece at which time we
will get rid of some of the data. The size of the database is really
dependant on the activity of the centers.
Thanks,
Mark
"Mike Epprecht (SQL MVP)" wrote:
[vbcol=seagreen]
> Hi
> I would do one database, but it depends on how well normalised the Db is and
> what a stress test would show up.
> Managing 2000 DB's becomes a nightmare.
> How big ar the DB's and how big do you expect them to grow?
> Regards
> Mike
> "Mark" wrote:
|||I would put everything in one DB. one of our companies has around 400
lawfirms and everything is in one database. The main thing that you have to
think about is security. In our case each lawfirm has a role and many tables
contain a field that specifies to which law firm the row belongs (row level
security). This is basically the idea but it gets more complex when you have
multiple groups with each law firm. This is based on the requirements and
something that you have to analyze). The
process might be painful but you have a lot to win as a DBA:
-amount of work for you and the developers ($$$)
-more simplified disaster recovery
-For reporting you can replicate your database on a different server and let
your clients hit the your reporting box instead of your prod.
-You will not need as many connection strings!
-Avoiding an administrative nightmare
Sasan Saidi, MSc in CS
Senior DBA
Brascan Business Services
"I saw it work in a cartoon once so I am pretty sure I can do it."
"Mark" wrote:
[vbcol=seagreen]
> The databse is normalized and where it is not, we are in the process of
> fixing that now. The database size after 2 years of use is about 3 gigs - I
> would imagine each database could grow to 10 gigs a piece at which time we
> will get rid of some of the data. The size of the database is really
> dependant on the activity of the centers.
> Thanks,
> Mark
> "Mike Epprecht (SQL MVP)" wrote:

Best way to setup data structure

I have an online application that works and functions like an accounting,
payroll, scheduliing and billing system. In the past, each center that
signed up would be setup in thier own database on SQL 2000. As this grows
more and more multisite organizations are using this service. It will
possible to have one organization with 2,000 centers using this service. My
question is: Should I continue setting up individual databases for each
center or should I combine the 2,000 centers for the one company into one
database and have a center key to distinguse the data. The only issue with
the mulit sites are reporting across the 2,000 or so centers. 95% of the
application is center specific the only time the data needs to be combined is
for some reports that are company wide.
Thanks,
MarkHi
I would do one database, but it depends on how well normalised the Db is and
what a stress test would show up.
Managing 2000 DB's becomes a nightmare.
How big ar the DB's and how big do you expect them to grow?
Regards
Mike
"Mark" wrote:
> I have an online application that works and functions like an accounting,
> payroll, scheduliing and billing system. In the past, each center that
> signed up would be setup in thier own database on SQL 2000. As this grows
> more and more multisite organizations are using this service. It will
> possible to have one organization with 2,000 centers using this service. My
> question is: Should I continue setting up individual databases for each
> center or should I combine the 2,000 centers for the one company into one
> database and have a center key to distinguse the data. The only issue with
> the mulit sites are reporting across the 2,000 or so centers. 95% of the
> application is center specific the only time the data needs to be combined is
> for some reports that are company wide.
> Thanks,
> Mark|||The databse is normalized and where it is not, we are in the process of
fixing that now. The database size after 2 years of use is about 3 gigs - I
would imagine each database could grow to 10 gigs a piece at which time we
will get rid of some of the data. The size of the database is really
dependant on the activity of the centers.
Thanks,
Mark
"Mike Epprecht (SQL MVP)" wrote:
> Hi
> I would do one database, but it depends on how well normalised the Db is and
> what a stress test would show up.
> Managing 2000 DB's becomes a nightmare.
> How big ar the DB's and how big do you expect them to grow?
> Regards
> Mike
> "Mark" wrote:
> > I have an online application that works and functions like an accounting,
> > payroll, scheduliing and billing system. In the past, each center that
> > signed up would be setup in thier own database on SQL 2000. As this grows
> > more and more multisite organizations are using this service. It will
> > possible to have one organization with 2,000 centers using this service. My
> > question is: Should I continue setting up individual databases for each
> > center or should I combine the 2,000 centers for the one company into one
> > database and have a center key to distinguse the data. The only issue with
> > the mulit sites are reporting across the 2,000 or so centers. 95% of the
> > application is center specific the only time the data needs to be combined is
> > for some reports that are company wide.
> >
> > Thanks,
> > Mark|||I would put everything in one DB. one of our companies has around 400
lawfirms and everything is in one database. The main thing that you have to
think about is security. In our case each lawfirm has a role and many tables
contain a field that specifies to which law firm the row belongs (row level
security). This is basically the idea but it gets more complex when you have
multiple groups with each law firm. This is based on the requirements and
something that you have to analyze). The
process might be painful but you have a lot to win as a DBA:
-amount of work for you and the developers ($$$)
-more simplified disaster recovery
-For reporting you can replicate your database on a different server and let
your clients hit the your reporting box instead of your prod.
-You will not need as many connection strings!
-Avoiding an administrative nightmare
--
Sasan Saidi, MSc in CS
Senior DBA
Brascan Business Services
"I saw it work in a cartoon once so I am pretty sure I can do it."
"Mark" wrote:
> The databse is normalized and where it is not, we are in the process of
> fixing that now. The database size after 2 years of use is about 3 gigs - I
> would imagine each database could grow to 10 gigs a piece at which time we
> will get rid of some of the data. The size of the database is really
> dependant on the activity of the centers.
> Thanks,
> Mark
> "Mike Epprecht (SQL MVP)" wrote:
> > Hi
> >
> > I would do one database, but it depends on how well normalised the Db is and
> > what a stress test would show up.
> >
> > Managing 2000 DB's becomes a nightmare.
> >
> > How big ar the DB's and how big do you expect them to grow?
> >
> > Regards
> > Mike
> >
> > "Mark" wrote:
> >
> > > I have an online application that works and functions like an accounting,
> > > payroll, scheduliing and billing system. In the past, each center that
> > > signed up would be setup in thier own database on SQL 2000. As this grows
> > > more and more multisite organizations are using this service. It will
> > > possible to have one organization with 2,000 centers using this service. My
> > > question is: Should I continue setting up individual databases for each
> > > center or should I combine the 2,000 centers for the one company into one
> > > database and have a center key to distinguse the data. The only issue with
> > > the mulit sites are reporting across the 2,000 or so centers. 95% of the
> > > application is center specific the only time the data needs to be combined is
> > > for some reports that are company wide.
> > >
> > > Thanks,
> > > Mark

Best way to setup data structure

I have an online application that works and functions like an accounting,
payroll, scheduliing and billing system. In the past, each center that
signed up would be setup in thier own database on SQL 2000. As this grows
more and more multisite organizations are using this service. It will
possible to have one organization with 2,000 centers using this service. My
question is: Should I continue setting up individual databases for each
center or should I combine the 2,000 centers for the one company into one
database and have a center key to distinguse the data. The only issue with
the mulit sites are reporting across the 2,000 or so centers. 95% of the
application is center specific the only time the data needs to be combined i
s
for some reports that are company wide.
Thanks,
MarkHi
I would do one database, but it depends on how well normalised the Db is and
what a stress test would show up.
Managing 2000 DB's becomes a nightmare.
How big ar the DB's and how big do you expect them to grow?
Regards
Mike
"Mark" wrote:

> I have an online application that works and functions like an accounting,
> payroll, scheduliing and billing system. In the past, each center that
> signed up would be setup in thier own database on SQL 2000. As this grows
> more and more multisite organizations are using this service. It will
> possible to have one organization with 2,000 centers using this service.
My
> question is: Should I continue setting up individual databases for each
> center or should I combine the 2,000 centers for the one company into one
> database and have a center key to distinguse the data. The only issue wit
h
> the mulit sites are reporting across the 2,000 or so centers. 95% of the
> application is center specific the only time the data needs to be combined
is
> for some reports that are company wide.
> Thanks,
> Mark|||The databse is normalized and where it is not, we are in the process of
fixing that now. The database size after 2 years of use is about 3 gigs - I
would imagine each database could grow to 10 gigs a piece at which time we
will get rid of some of the data. The size of the database is really
dependant on the activity of the centers.
Thanks,
Mark
"Mike Epprecht (SQL MVP)" wrote:
[vbcol=seagreen]
> Hi
> I would do one database, but it depends on how well normalised the Db is a
nd
> what a stress test would show up.
> Managing 2000 DB's becomes a nightmare.
> How big ar the DB's and how big do you expect them to grow?
> Regards
> Mike
> "Mark" wrote:
>|||I would put everything in one DB. one of our companies has around 400
lawfirms and everything is in one database. The main thing that you have to
think about is security. In our case each lawfirm has a role and many tables
contain a field that specifies to which law firm the row belongs (row level
security). This is basically the idea but it gets more complex when you have
multiple groups with each law firm. This is based on the requirements and
something that you have to analyze). The
process might be painful but you have a lot to win as a DBA:
-amount of work for you and the developers ($$$)
-more simplified disaster recovery
-For reporting you can replicate your database on a different server and let
your clients hit the your reporting box instead of your prod.
-You will not need as many connection strings!
-Avoiding an administrative nightmare
Sasan Saidi, MSc in CS
Senior DBA
Brascan Business Services
"I saw it work in a cartoon once so I am pretty sure I can do it."
"Mark" wrote:
[vbcol=seagreen]
> The databse is normalized and where it is not, we are in the process of
> fixing that now. The database size after 2 years of use is about 3 gigs -
I
> would imagine each database could grow to 10 gigs a piece at which time we
> will get rid of some of the data. The size of the database is really
> dependant on the activity of the centers.
> Thanks,
> Mark
> "Mike Epprecht (SQL MVP)" wrote:
>