Diagnosing Memory Use

I've noticed high memory consumption on some of our workstations that eventually cause unacceptable performance problems. Through Task Manager, I see that SQL Server is consuming the bulk of this memory.

A coworker has implemented a system to periodically restart SQL Server (using netstop/netstart). This does hold down memory usage but I'd like to avoid doing this.

I'd like to diagnose SQL Server and find exactly what it is doing that consumes so much memory.

I am aware of three tools to diagnose this:
- Performance Monitor
- Enterprise Manager "Current Activity"
- SQL Server Profiler

Which is the best tool to do this and how would I approach this scenario?The bottleneck may not be the memory consumption. The Task Manager is showing you the max memory sql is allowed to allocate, not the actual memory sql is currently using. You may have something else hosted your system.|||Originally posted by joejcheng
The bottleneck may not be the memory consumption. The Task Manager is showing you the max memory sql is allowed to allocate, not the actual memory sql is currently using. You may have something else hosted your system.

Task Manager shows both Mem Usage (actively paged in) and VM Size (reserved but not necessarily paged in) for the sqlservr.exe process. Those are 651MB/670MB respectively. Using Performance Monitor I see that the disk use is high, and the "Pages/sec" is high.

Shortly after doing a netstop/netstart restart of SQL Server Mem Usage/VM Size = 36MB/44MB respectively and performance is great. Our application has already reconnected to SQL Server and is operating at full speed.

This really has to be SQL Server related.|||Just to make sure, the users all have SQL or MSDE installed on their workstations or laptops, right? You can cap the amount of memory that SQL Server uses, but that will probably increase the amount of disk I/O and may cause even more problems. Anyway, try running this from a command line

osql /S(local) /E /Q"sp_configure 'max server memory (MB)', 256"
osql /S(local) /E /Q"reconfigure with override"

You may need to modify that a bit with the proper workstation\instancename, but it will keep SQL Server from hogging memory. Good luck.|||Originally posted by MCrowley
Just to make sure, the users all have SQL or MSDE installed on their workstations or laptops, right? You can cap the amount of memory that SQL Server uses, but that will probably increase the amount of disk I/O and may cause even more problems. Anyway, try running this from a command line

osql /S(local) /E /Q"sp_configure 'max server memory (MB)', 256"
osql /S(local) /E /Q"reconfigure with override"

You may need to modify that a bit with the proper workstation\instancename, but it will keep SQL Server from hogging memory. Good luck.

Thanks for the feedback!

Actually, there are no users just an internal app that runs 24/7.

We could cut SQL Server's memory allotment but as you said, that will increase disk use which is the main problem. What I want to know is why it is using the memory that it is. Once I identify that, I can redesign to use less resources. I suspect a design problem rather than simply a lack of resources.|||Ahh. Then your problem seems to be that your database has grown to more than probably 500 MB. More likely to more than 1GB. SQL Server (and Oracle, Informix, DB2, etc.) will store information in memory for faster access. You can cut down on the amount of I/O you need to perform by reducing redundancy in the data, or applying indexes on the tables that are queried most often.

The first method may be beyond help, as reconfiguring the database is near impossible without a total re-write of the application. As for the second, open Profiler in the SQL program group, and connect to your server. Under Events, remove Security Audit and Sessions. On the filters page, add a limit under Reads of greater than or equal say 100 reads. 1 read is only a logical I/O rather than a physical one, but you should be able to figure out quickly which queries are your problem children. Good luck.|||Hi,

I had similar doubts and i would like you to see the following link, which is a discussion on the same forum
http://www.dbforums.com/showthread.php?threadid=966886&referrerid=47114

regards,
henry

Diagnosing Memory Problems?

I've noticed high memory consumption on some of our workstations that
eventually cause unacceptable performance problems. Through Task
Manager, I see that SQL Server (sqlsrvr.exe) is consuming the bulk of
this memory.
We've found that restarting SQL Server (using netstop/netstart)
dramatically reduces memory usage but it gradually creeps back to an
unacceptable level and becomes a problem (high pages/sec thrashing). We
are setting up a system that will periodically restart SQL Server. This
is a stopgap solution.
I'd like to identify what in SQL Server is using this memory and why.
Ideally, I would redesign my applications so that this wouldn't happen.
I suspect some kind of design flaw or usage error and I want to identify
it. Adding physical RAM isn't an option since this is running on a 70
workstation farm.
I don't want to simply limit SQL Server's memory allotment since this
leads to increased disk use which is the main problem.
I am aware of three tools to diagnose this:
- Performance Monitor
- Enterprise Manager "Current Activity"
- SQL Server Profiler
Which is the best tool to do this and how would I approach this scenario?
Thank You!SQL Server and most other high-end database products are
essentially disk caching engines (that provide
transactions and management etc)
so under most circumstances, its suppose to use all
available memory for most effective disk caching
it will also release memory to other apps if the available
system memory falls below 4-6MB (i do wish MS would
increase this setting to 16-32MB)
however, if you are not using it as a dedicated DB server,
use Ent Manager to restrict the max memory to some desired
amount, 64-128M is good for a development system.
don't trying to figure out which queries are using memory,
unless you want to reduce the amount of data.
>--Original Message--
>I've noticed high memory consumption on some of our
workstations that
>eventually cause unacceptable performance problems.
Through Task
>Manager, I see that SQL Server (sqlsrvr.exe) is consuming
the bulk of
>this memory.
>We've found that restarting SQL Server (using
netstop/netstart)
>dramatically reduces memory usage but it gradually creeps
back to an
>unacceptable level and becomes a problem (high pages/sec
thrashing). We
>are setting up a system that will periodically restart
SQL Server. This
>is a stopgap solution.
>I'd like to identify what in SQL Server is using this
memory and why.
>Ideally, I would redesign my applications so that this
wouldn't happen.
>I suspect some kind of design flaw or usage error and I
want to identify
>it. Adding physical RAM isn't an option since this is
running on a 70
>workstation farm.
>I don't want to simply limit SQL Server's memory
allotment since this
>leads to increased disk use which is the main problem.
>I am aware of three tools to diagnose this:
>- Performance Monitor
>- Enterprise Manager "Current Activity"
>- SQL Server Profiler
>Which is the best tool to do this and how would I
approach this scenario?
>Thank You!
>.
>|||Excellent insight. Thank you!
joe chang wrote:
> SQL Server and most other high-end database products are
> essentially disk caching engines (that provide
> transactions and management etc)
> so under most circumstances, its suppose to use all
> available memory for most effective disk caching
> it will also release memory to other apps if the available
> system memory falls below 4-6MB (i do wish MS would
> increase this setting to 16-32MB)
> however, if you are not using it as a dedicated DB server,
> use Ent Manager to restrict the max memory to some desired
> amount, 64-128M is good for a development system.
> don't trying to figure out which queries are using memory,
> unless you want to reduce the amount of data.|||I am consistantly getting Physical Memory Usage High errors. My Buffer Cache is running at 99% and the Server Memory is at 87%. Any thoughts on what's causing this?

Development, Staging, Production - best practice

Hi,
I would appreciate your advice in deploying enterprise BI solution. The task
at hand is this: I need to get the data from DW (SQL 2005), process into SSAS
and present with SSRS. I may also need to offer a third party OLAP browser as
a part this of solution. My initial thoughts about the setup for this are:
- SRV1: Development server, with all SQL 2005 components, IIS, and any third
party OLAP tools that we might pick.
-SRV2: Staging/Processing. Schedule and run SSIS to get data from DW, and
refresh and process SSAS cubes.
-SRV3: Production Reporting/Web server: This server would hold processed
cubes from SRV2 (archived and restored on SRV3), SSRS, IIS any any third
party OLAP browser that we may pick.
Initially there will be 2-3 developers, 15-20 cubes and 30-40 reports. We
are targeting to server 20-30 Report users.
Does the above setup make sense? Do I need dedicated web server with or
without SSRS? Please share thoughts or advise of any best practice articles.
Thank you.
ZoranHello Zoran,
The server setup need to be decide with that how large your cube is and how
many data your cube stored.
Yes, you need to seperate a stand alone server to process all the Cube data
and use the Reporting Services as the Front End Server.
I don't think you need to dedicate the web server with Reporting Services
because the Reporting Services is also a web application in the web front
end. Also, considering your report users, your report web quest will not at
a high level.
Hope this helps.
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================This posting is provided "AS IS" with no warranties, and confers no rights.|||Thank you Wei,
Currently all our cubes are MOLAP, with database sizes ranging from 30 MB to
300 MB. I read that one of the most efficient ways to move from Staging to
Production is backup and retore. But, is it good practice to keep production
cubes on the same server as SSRS? Technically, there would be no processing
on that server, cubes would only sit there for user's queries...
Zoran
"Wei Lu [MSFT]" wrote:
> Hello Zoran,
> The server setup need to be decide with that how large your cube is and how
> many data your cube stored.
> Yes, you need to seperate a stand alone server to process all the Cube data
> and use the Reporting Services as the Front End Server.
> I don't think you need to dedicate the web server with Reporting Services
> because the Reporting Services is also a web application in the web front
> end. Also, considering your report users, your report web quest will not at
> a high level.
> Hope this helps.
> Sincerely,
> Wei Lu
> Microsoft Online Community Support
> ==================================================> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> ==================================================> This posting is provided "AS IS" with no warranties, and confers no rights.
>|||Hello Zoran,
Whether putting the SSRS together with the Cube depends on the size and how
system resource used by the SSAS.
In your scenario, I think it is OK for you to put the SSRS on the same
server at this time. But if your cube grows, you may need to seperate the
SSAS with SSRS.
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================This posting is provided "AS IS" with no warranties, and confers no rights.|||Hi ,
How is everything going? Please feel free to let me know if you need any
assistance.
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================This posting is provided "AS IS" with no warranties, and confers no rights.|||Thank you Wei.
In your previous post you you mentioned "depends how system resources
(are)used by SSAS". In my scenario, they would be used for user queries
(direct and via SSRS). There would be no processing done on this server.
I can certainly see the number of cubes grow in near future. Is one server
for SSRS and SSAS going to work, or am I setting myself up for upgrade in
near future?
Regards,
Zoran Knezic
"Wei Lu [MSFT]" wrote:
> Hi ,
> How is everything going? Please feel free to let me know if you need any
> assistance.
> Sincerely,
> Wei Lu
> Microsoft Online Community Support
> ==================================================> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> ==================================================> This posting is provided "AS IS" with no warranties, and confers no rights.
>|||RS 2005 does all rendering in RAM. As long as you have enough RAM I think
you will be OK. I would suggest starting off on one server. Perhaps let
management know that you will need to monitor the usage and there is a
chance they will need to be split onto separate servers. RS 2008 is going to
be much smarter and with how it renders.
You said the following: Initially there will be 2-3 developers, 15-20 cubes
and 30-40 reports. We
are targeting to server 20-30 Report users.
This is not that many users. I do not have cubes but I have a datamart which
includes a table with 150 million rows (small rows admittedly) plus several
tables that have several million rows. RS 2005 and the datamart are on the
same server without difficulty. Similar number of users (more reports). My
server is old (4 years old) and ready for replacement. I have 4
processors(2.4 GHz), 4 Gigs of Ram (so this is not a huge powerful box by
any means). Performance is very very good for me. Running SQL 2005 Standard
edition.
Since you are just getting started. If you are able to plan on using RS 2008
I would do so. RS 2008 should be able to use a SQL 2005 db for its
metadata/object caching so it is a licensing issue.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"zk_" <zk_@.newsgroup.nospam> wrote in message
news:EB03F7C3-13D3-40D2-8991-7FAF755EEFCE@.microsoft.com...
> Thank you Wei.
> In your previous post you you mentioned "depends how system resources
> (are)used by SSAS". In my scenario, they would be used for user queries
> (direct and via SSRS). There would be no processing done on this server.
> I can certainly see the number of cubes grow in near future. Is one server
> for SSRS and SSAS going to work, or am I setting myself up for upgrade in
> near future?
> Regards,
> Zoran Knezic
> "Wei Lu [MSFT]" wrote:
>> Hi ,
>> How is everything going? Please feel free to let me know if you need any
>> assistance.
>> Sincerely,
>> Wei Lu
>> Microsoft Online Community Support
>> ==================================================>> When responding to posts, please "Reply to Group" via your newsreader so
>> that others may learn and benefit from your issue.
>> ==================================================>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>|||Thank you Bruce.
It is good to hear a first hand experience with DB and SSRS on the same
server.
I am sure that SSAS creates bigger overhead then DB, but judging by your
experience, I might be OK.
My IMIT colleagues came up with 2x 2.8 GHz server, with 16 Gb of RAM.
Alternatively I might be able to suggest two servers, 2x2.8 GHz 8GB of RAM
each.
Once again, thank you for your time.
Zoran Knezic
"Bruce L-C [MVP]" wrote:
> RS 2005 does all rendering in RAM. As long as you have enough RAM I think
> you will be OK. I would suggest starting off on one server. Perhaps let
> management know that you will need to monitor the usage and there is a
> chance they will need to be split onto separate servers. RS 2008 is going to
> be much smarter and with how it renders.
> You said the following: Initially there will be 2-3 developers, 15-20 cubes
> and 30-40 reports. We
> are targeting to server 20-30 Report users.
> This is not that many users. I do not have cubes but I have a datamart which
> includes a table with 150 million rows (small rows admittedly) plus several
> tables that have several million rows. RS 2005 and the datamart are on the
> same server without difficulty. Similar number of users (more reports). My
> server is old (4 years old) and ready for replacement. I have 4
> processors(2.4 GHz), 4 Gigs of Ram (so this is not a huge powerful box by
> any means). Performance is very very good for me. Running SQL 2005 Standard
> edition.
> Since you are just getting started. If you are able to plan on using RS 2008
> I would do so. RS 2008 should be able to use a SQL 2005 db for its
> metadata/object caching so it is a licensing issue.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
>
> "zk_" <zk_@.newsgroup.nospam> wrote in message
> news:EB03F7C3-13D3-40D2-8991-7FAF755EEFCE@.microsoft.com...
> > Thank you Wei.
> > In your previous post you you mentioned "depends how system resources
> > (are)used by SSAS". In my scenario, they would be used for user queries
> > (direct and via SSRS). There would be no processing done on this server.
> > I can certainly see the number of cubes grow in near future. Is one server
> > for SSRS and SSAS going to work, or am I setting myself up for upgrade in
> > near future?
> >
> > Regards,
> > Zoran Knezic
> >
> > "Wei Lu [MSFT]" wrote:
> >
> >> Hi ,
> >>
> >> How is everything going? Please feel free to let me know if you need any
> >> assistance.
> >>
> >> Sincerely,
> >>
> >> Wei Lu
> >> Microsoft Online Community Support
> >>
> >> ==================================================> >>
> >> When responding to posts, please "Reply to Group" via your newsreader so
> >> that others may learn and benefit from your issue.
> >>
> >> ==================================================> >> This posting is provided "AS IS" with no warranties, and confers no
> >> rights.
> >>
> >>
>
>

Development - Test Environment Questions

Hi,
I've been given the task of creating a dev/test environment. Currently we
have several production applications using databases on a common SQL Server.
If changes are required, the developers are performing the changes on the
production system - yea I know BAD,BAD,BAD - but I didn't set this up but
instead inherited it. I'd like to configure a dev/test environment to move
the devs off of the production system and to faciliate their development of
future projects coming up soon.
How is your dev/test environment configured? I'm looking for a few examples
here that I can work with to implement our dev/test based on our budget and
system capabilities.
I.e., Each dev has their own sandbox or each dev shares a common dev env -
then changes are implemented to test env (and by who - dev or dba - and
how - scripts) etc... then scripted to deploy on prod systems etc... also
we image/ghost systems or use VMs and also we use Visual SourceSafe to...
Trying to come up with a solid game plan here.
Thanks for any input.
Jerry
Jerry Spivey wrote:
> Hi,
> I've been given the task of creating a dev/test environment. Currently
> we have several production applications using databases on
> a common SQL Server. If changes are required, the developers are
> performing the changes on the production system - yea I know
> BAD,BAD,BAD - but I didn't set this up but instead inherited it. I'd
> like to configure a dev/test environment to move the devs off of the
> production system and to faciliate their development of future
> projects coming up soon.
> How is your dev/test environment configured? I'm looking for a few
> examples here that I can work with to implement our dev/test based on
> our budget and system capabilities.
> I.e., Each dev has their own sandbox or each dev shares a common dev
> env - then changes are implemented to test env (and by who - dev or
> dba - and how - scripts) etc... then scripted to deploy on prod
> systems etc... also we image/ghost systems or use VMs and also we use
> Visual
> SourceSafe to...
> Trying to come up with a solid game plan here.
> Thanks for any input.
> Jerry
At most companies where I've worked in the past, we had development
servers that were used strictly for development. They generally
contained stripped down data from the production databases with any
customer sensitive data masked. Lead developers generally had dbo rights
and may even have admin rights depending on the size of the company.
Version control software was used for all object changes. Initial
application testing was done on the dev servers.
QA/Test servers were not managed by development. They were usually owned
by QA group. We would provide detailed scripts to update QA servers with
the necessary changes. Users would test the applications on QA servers.
QA servers have data that more closely mimics production in terms of
data value distribution and quantity and may even be created from
production backups. Sensitive data was not masked back then, as I
recall, but it may have to be today. QA has the ability to reload the
database in case the migration to QA fails. It's important to be able to
always start from an exact copy of the production database schema.
These days, you can use multiple SQL Server Instances to save hardware
(assuming you have the necessary memory). VMs, while convenient, are
probably not ideal for performance testing. But I'm not well informed
about the capabilites of the server VM products.
If everything tested ok, the updates were escalated to production.
David Gugick
Quest Software
www.imceda.com
www.quest.com
|||Thanks David.
Looking into using named instances with EE to help control costs. Will be
looking into implementing Visual SourceSafe as well.
I noticed you work for Quest. I have a few questions about the Quest
Central if you're open to them. Please email me if so.
Thanks
Jerry
"David Gugick" <david.gugick-nospam@.quest.com> wrote in message
news:%23YygmKIaFHA.1044@.TK2MSFTNGP10.phx.gbl...
> Jerry Spivey wrote:
> At most companies where I've worked in the past, we had development
> servers that were used strictly for development. They generally contained
> stripped down data from the production databases with any customer
> sensitive data masked. Lead developers generally had dbo rights and may
> even have admin rights depending on the size of the company. Version
> control software was used for all object changes. Initial application
> testing was done on the dev servers.
> QA/Test servers were not managed by development. They were usually owned
> by QA group. We would provide detailed scripts to update QA servers with
> the necessary changes. Users would test the applications on QA servers. QA
> servers have data that more closely mimics production in terms of data
> value distribution and quantity and may even be created from production
> backups. Sensitive data was not masked back then, as I recall, but it may
> have to be today. QA has the ability to reload the database in case the
> migration to QA fails. It's important to be able to always start from an
> exact copy of the production database schema.
> These days, you can use multiple SQL Server Instances to save hardware
> (assuming you have the necessary memory). VMs, while convenient, are
> probably not ideal for performance testing. But I'm not well informed
> about the capabilites of the server VM products.
> If everything tested ok, the updates were escalated to production.
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com
|||Jerry Spivey wrote:
> Thanks David.
> Looking into using named instances with EE to help control costs. Will
> be looking into implementing Visual SourceSafe as well.
> I noticed you work for Quest. I have a few questions about the Quest
> Central if you're open to them. Please email me if so.
> Thanks
> Jerry
>
The best way for you to get information and help with the Quest product
line is to contact sales. Our offices and numbers are located here:
http://www.quest.com/company/us_offices.asp
David Gugick
Quest Software
www.imceda.com
www.quest.com
|||Change management is the term.
http://www.innovartis.co.uk/pdf/Inno...ange_Mgt. pdf
This is a white paper on the subject using Source Control (Visual Source
Safe) as the back bone of the approach. The application DB Ghost
(www.dbghost.com) was built using this methodology.
regards,
Mark Baekdal
http://www.dbghost.com
http://www.innovartis.co.uk
+44 (0)208 241 1762
Build, Comparison and Synchronization from Source Control = Database change
management for SQL Server
"Jerry Spivey" wrote:

> Hi,
> I've been given the task of creating a dev/test environment. Currently we
> have several production applications using databases on a common SQL Server.
> If changes are required, the developers are performing the changes on the
> production system - yea I know BAD,BAD,BAD - but I didn't set this up but
> instead inherited it. I'd like to configure a dev/test environment to move
> the devs off of the production system and to faciliate their development of
> future projects coming up soon.
>
> How is your dev/test environment configured? I'm looking for a few examples
> here that I can work with to implement our dev/test based on our budget and
> system capabilities.
> I.e., Each dev has their own sandbox or each dev shares a common dev env -
> then changes are implemented to test env (and by who - dev or dba - and
> how - scripts) etc... then scripted to deploy on prod systems etc... also
> we image/ghost systems or use VMs and also we use Visual SourceSafe to...
> Trying to come up with a solid game plan here.
> Thanks for any input.
> Jerry
>
>

Development - Test Environment Questions

Hi,
I've been given the task of creating a dev/test environment. Currently we
have several production applications using databases on a common SQL Server.
If changes are required, the developers are performing the changes on the
production system - yea I know BAD,BAD,BAD - but I didn't set this up but
instead inherited it. I'd like to configure a dev/test environment to move
the devs off of the production system and to faciliate their development of
future projects coming up soon.
How is your dev/test environment configured? I'm looking for a few examples
here that I can work with to implement our dev/test based on our budget and
system capabilities.
I.e., Each dev has their own sandbox or each dev shares a common dev env -
then changes are implemented to test env (and by who - dev or dba - and
how - scripts) etc... then scripted to deploy on prod systems etc... also
we image/ghost systems or use VMs and also we use Visual SourceSafe to...
Trying to come up with a solid game plan here.
Thanks for any input.
JerryJerry Spivey wrote:
> Hi,
> I've been given the task of creating a dev/test environment. Currently
> we have several production applications using databases on
> a common SQL Server. If changes are required, the developers are
> performing the changes on the production system - yea I know
> BAD,BAD,BAD - but I didn't set this up but instead inherited it. I'd
> like to configure a dev/test environment to move the devs off of the
> production system and to faciliate their development of future
> projects coming up soon.
> How is your dev/test environment configured? I'm looking for a few
> examples here that I can work with to implement our dev/test based on
> our budget and system capabilities.
> I.e., Each dev has their own sandbox or each dev shares a common dev
> env - then changes are implemented to test env (and by who - dev or
> dba - and how - scripts) etc... then scripted to deploy on prod
> systems etc... also we image/ghost systems or use VMs and also we use
> Visual
> SourceSafe to...
> Trying to come up with a solid game plan here.
> Thanks for any input.
> Jerry
At most companies where I've worked in the past, we had development
servers that were used strictly for development. They generally
contained stripped down data from the production databases with any
customer sensitive data masked. Lead developers generally had dbo rights
and may even have admin rights depending on the size of the company.
Version control software was used for all object changes. Initial
application testing was done on the dev servers.
QA/Test servers were not managed by development. They were usually owned
by QA group. We would provide detailed scripts to update QA servers with
the necessary changes. Users would test the applications on QA servers.
QA servers have data that more closely mimics production in terms of
data value distribution and quantity and may even be created from
production backups. Sensitive data was not masked back then, as I
recall, but it may have to be today. QA has the ability to reload the
database in case the migration to QA fails. It's important to be able to
always start from an exact copy of the production database schema.
These days, you can use multiple SQL Server Instances to save hardware
(assuming you have the necessary memory). VMs, while convenient, are
probably not ideal for performance testing. But I'm not well informed
about the capabilites of the server VM products.
If everything tested ok, the updates were escalated to production.
--
David Gugick
Quest Software
www.imceda.com
www.quest.com|||Thanks David.
Looking into using named instances with EE to help control costs. Will be
looking into implementing Visual SourceSafe as well.
I noticed you work for Quest. I have a few questions about the Quest
Central if you're open to them. Please email me if so.
Thanks
Jerry
"David Gugick" <david.gugick-nospam@.quest.com> wrote in message
news:%23YygmKIaFHA.1044@.TK2MSFTNGP10.phx.gbl...
> Jerry Spivey wrote:
>> Hi,
>> I've been given the task of creating a dev/test environment. Currently we
>> have several production applications using databases on
>> a common SQL Server. If changes are required, the developers are
>> performing the changes on the production system - yea I know
>> BAD,BAD,BAD - but I didn't set this up but instead inherited it. I'd
>> like to configure a dev/test environment to move the devs off of the
>> production system and to faciliate their development of future
>> projects coming up soon.
>> How is your dev/test environment configured? I'm looking for a few
>> examples here that I can work with to implement our dev/test based on
>> our budget and system capabilities.
>> I.e., Each dev has their own sandbox or each dev shares a common dev
>> env - then changes are implemented to test env (and by who - dev or
>> dba - and how - scripts) etc... then scripted to deploy on prod systems
>> etc... also we image/ghost systems or use VMs and also we use Visual
>> SourceSafe to...
>> Trying to come up with a solid game plan here.
>> Thanks for any input.
>> Jerry
> At most companies where I've worked in the past, we had development
> servers that were used strictly for development. They generally contained
> stripped down data from the production databases with any customer
> sensitive data masked. Lead developers generally had dbo rights and may
> even have admin rights depending on the size of the company. Version
> control software was used for all object changes. Initial application
> testing was done on the dev servers.
> QA/Test servers were not managed by development. They were usually owned
> by QA group. We would provide detailed scripts to update QA servers with
> the necessary changes. Users would test the applications on QA servers. QA
> servers have data that more closely mimics production in terms of data
> value distribution and quantity and may even be created from production
> backups. Sensitive data was not masked back then, as I recall, but it may
> have to be today. QA has the ability to reload the database in case the
> migration to QA fails. It's important to be able to always start from an
> exact copy of the production database schema.
> These days, you can use multiple SQL Server Instances to save hardware
> (assuming you have the necessary memory). VMs, while convenient, are
> probably not ideal for performance testing. But I'm not well informed
> about the capabilites of the server VM products.
> If everything tested ok, the updates were escalated to production.
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com|||Jerry Spivey wrote:
> Thanks David.
> Looking into using named instances with EE to help control costs. Will
> be looking into implementing Visual SourceSafe as well.
> I noticed you work for Quest. I have a few questions about the Quest
> Central if you're open to them. Please email me if so.
> Thanks
> Jerry
>
The best way for you to get information and help with the Quest product
line is to contact sales. Our offices and numbers are located here:
http://www.quest.com/company/us_offices.asp
--
David Gugick
Quest Software
www.imceda.com
www.quest.com|||Change management is the term.
http://www.innovartis.co.uk/pdf/Innovartis_An_Automated_Approach_To_Do_Change_Mgt.pdf
This is a white paper on the subject using Source Control (Visual Source
Safe) as the back bone of the approach. The application DB Ghost
(www.dbghost.com) was built using this methodology.
regards,
Mark Baekdal
http://www.dbghost.com
http://www.innovartis.co.uk
+44 (0)208 241 1762
Build, Comparison and Synchronization from Source Control = Database change
management for SQL Server
"Jerry Spivey" wrote:
> Hi,
> I've been given the task of creating a dev/test environment. Currently we
> have several production applications using databases on a common SQL Server.
> If changes are required, the developers are performing the changes on the
> production system - yea I know BAD,BAD,BAD - but I didn't set this up but
> instead inherited it. I'd like to configure a dev/test environment to move
> the devs off of the production system and to faciliate their development of
> future projects coming up soon.
>
> How is your dev/test environment configured? I'm looking for a few examples
> here that I can work with to implement our dev/test based on our budget and
> system capabilities.
> I.e., Each dev has their own sandbox or each dev shares a common dev env -
> then changes are implemented to test env (and by who - dev or dba - and
> how - scripts) etc... then scripted to deploy on prod systems etc... also
> we image/ghost systems or use VMs and also we use Visual SourceSafe to...
> Trying to come up with a solid game plan here.
> Thanks for any input.
> Jerry
>
>

Development - Test Environment Questions

Hi,
I've been given the task of creating a dev/test environment. Currently we
have several production applications using databases on a common SQL Server.
If changes are required, the developers are performing the changes on the
production system - yea I know BAD,BAD,BAD - but I didn't set this up but
instead inherited it. I'd like to configure a dev/test environment to move
the devs off of the production system and to faciliate their development of
future projects coming up soon.
How is your dev/test environment configured? I'm looking for a few examples
here that I can work with to implement our dev/test based on our budget and
system capabilities.
I.e., Each dev has their own sandbox or each dev shares a common dev env -
then changes are implemented to test env (and by who - dev or dba - and
how - scripts) etc... then scripted to deploy on prod systems etc... also
we image/ghost systems or use VMs and also we use Visual SourceSafe to...
Trying to come up with a solid game plan here.
Thanks for any input.
JerryJerry Spivey wrote:
> Hi,
> I've been given the task of creating a dev/test environment. Currently
> we have several production applications using databases on
> a common SQL Server. If changes are required, the developers are
> performing the changes on the production system - yea I know
> BAD,BAD,BAD - but I didn't set this up but instead inherited it. I'd
> like to configure a dev/test environment to move the devs off of the
> production system and to faciliate their development of future
> projects coming up soon.
> How is your dev/test environment configured? I'm looking for a few
> examples here that I can work with to implement our dev/test based on
> our budget and system capabilities.
> I.e., Each dev has their own sandbox or each dev shares a common dev
> env - then changes are implemented to test env (and by who - dev or
> dba - and how - scripts) etc... then scripted to deploy on prod
> systems etc... also we image/ghost systems or use VMs and also we use
> Visual
> SourceSafe to...
> Trying to come up with a solid game plan here.
> Thanks for any input.
> Jerry
At most companies where I've worked in the past, we had development
servers that were used strictly for development. They generally
contained stripped down data from the production databases with any
customer sensitive data masked. Lead developers generally had dbo rights
and may even have admin rights depending on the size of the company.
Version control software was used for all object changes. Initial
application testing was done on the dev servers.
QA/Test servers were not managed by development. They were usually owned
by QA group. We would provide detailed scripts to update QA servers with
the necessary changes. Users would test the applications on QA servers.
QA servers have data that more closely mimics production in terms of
data value distribution and quantity and may even be created from
production backups. Sensitive data was not masked back then, as I
recall, but it may have to be today. QA has the ability to reload the
database in case the migration to QA fails. It's important to be able to
always start from an exact copy of the production database schema.
These days, you can use multiple SQL Server Instances to save hardware
(assuming you have the necessary memory). VMs, while convenient, are
probably not ideal for performance testing. But I'm not well informed
about the capabilites of the server VM products.
If everything tested ok, the updates were escalated to production.
David Gugick
Quest Software
www.imceda.com
www.quest.com|||Thanks David.
Looking into using named instances with EE to help control costs. Will be
looking into implementing Visual SourceSafe as well.
I noticed you work for Quest. I have a few questions about the Quest
Central if you're open to them. Please email me if so.
Thanks
Jerry
"David Gugick" <david.gugick-nospam@.quest.com> wrote in message
news:%23YygmKIaFHA.1044@.TK2MSFTNGP10.phx.gbl...
> Jerry Spivey wrote:
> At most companies where I've worked in the past, we had development
> servers that were used strictly for development. They generally contained
> stripped down data from the production databases with any customer
> sensitive data masked. Lead developers generally had dbo rights and may
> even have admin rights depending on the size of the company. Version
> control software was used for all object changes. Initial application
> testing was done on the dev servers.
> QA/Test servers were not managed by development. They were usually owned
> by QA group. We would provide detailed scripts to update QA servers with
> the necessary changes. Users would test the applications on QA servers. QA
> servers have data that more closely mimics production in terms of data
> value distribution and quantity and may even be created from production
> backups. Sensitive data was not masked back then, as I recall, but it may
> have to be today. QA has the ability to reload the database in case the
> migration to QA fails. It's important to be able to always start from an
> exact copy of the production database schema.
> These days, you can use multiple SQL Server Instances to save hardware
> (assuming you have the necessary memory). VMs, while convenient, are
> probably not ideal for performance testing. But I'm not well informed
> about the capabilites of the server VM products.
> If everything tested ok, the updates were escalated to production.
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com|||Jerry Spivey wrote:
> Thanks David.
> Looking into using named instances with EE to help control costs. Will
> be looking into implementing Visual SourceSafe as well.
> I noticed you work for Quest. I have a few questions about the Quest
> Central if you're open to them. Please email me if so.
> Thanks
> Jerry
>
The best way for you to get information and help with the Quest product
line is to contact sales. Our offices and numbers are located here:
http://www.quest.com/company/us_offices.asp
David Gugick
Quest Software
www.imceda.com
www.quest.com|||Change management is the term.
hange_Mgt.
pdf" target="_blank">http://www.innovartis.co.uk/pdf/ In...Mgt.
pdf
This is a white paper on the subject using Source Control (Visual Source
Safe) as the back bone of the approach. The application DB Ghost
(www.dbghost.com) was built using this methodology.
regards,
Mark Baekdal
http://www.dbghost.com
http://www.innovartis.co.uk
+44 (0)208 241 1762
Build, Comparison and Synchronization from Source Control = Database change
management for SQL Server
"Jerry Spivey" wrote:

> Hi,
> I've been given the task of creating a dev/test environment. Currently we
> have several production applications using databases on a common SQL Serve
r.
> If changes are required, the developers are performing the changes on the
> production system - yea I know BAD,BAD,BAD - but I didn't set this up but
> instead inherited it. I'd like to configure a dev/test environment to mov
e
> the devs off of the production system and to faciliate their development o
f
> future projects coming up soon.
>
> How is your dev/test environment configured? I'm looking for a few exampl
es
> here that I can work with to implement our dev/test based on our budget an
d
> system capabilities.
> I.e., Each dev has their own sandbox or each dev shares a common dev env -
> then changes are implemented to test env (and by who - dev or dba - and
> how - scripts) etc... then scripted to deploy on prod systems etc... also
> we image/ghost systems or use VMs and also we use Visual SourceSafe to...
> Trying to come up with a solid game plan here.
> Thanks for any input.
> Jerry
>
>

Developing new Task in SSIS

Hi All:

For making a custom Task in SSIS, is it possible to reuse the existing code base? For e.g. If i need to append some functionalities to LookUp Transform. Can I inherit the lookUp transform class?

Thanks,

Vipul

Vipul123 wrote:

Hi All:

For making a custom Task in SSIS, is it possible to reuse the existing code base? For e.g. If i need to append some functionalities to LookUp Transform. Can I inherit the lookUp transform class?

Thanks,

Vipul

No. Unfortunately not.

-Jamie

developing new task

Hi

Can i inherit a existing task to a new custom class to add functionality to custom class.

for eg: Inherit lookup transfor which is already present in SSIS to add some funstionality into it.

Thanks

Vipul

https://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=796926&SiteID=1