Showing posts with label production. Show all posts
Showing posts with label production. Show all posts

Sunday, March 11, 2012

Data connection error - Please help

Thanks in advance to anyone that can help me with this.

We have software in a production environment that uses a DSN-Less connection to access an Access Database. The software was written in VB6 and uses MDAC 2.8

99% of customers have no issues with the software connecting the the database however once in while we encounter a customer that get's the following error:

[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified

Except for the DB path the rest of the connection string is hardcoded in the app so there is no difference in the name of the driver used on 99% of the working installations and the 1% that fail. The debug log returned by the customer shows that the following connection string is being used:

Driver={Microsoft Access Driver (*.mdb)};Uid=xxxx;Pwd=xxx;Dbq=C:\Windows\SomeSubDir\ourAccessDB;

We have verfied the following:

1. Our Access DB must be placed under a subdirectory of the main Windows directory. There is special reason for this but it would take too long to explain. However, I have confirmed that the database can be accessed and the user has full permissions on these folders. The can create new files in the same directory, etc.

2. Customer is running Windows XP SP2. Has MDAC 2.8 installed as well as the MS Jet SP8

3. Customer confirms that the entry "Microsoft Access Drive (*.mdb)" shows up in the driver tab of the ODBC panel.

4. I have discovered that I can only reproduce that error on our development systems if I change the connection string to use a driver that doesn't exist (e.g. Driver={Mosoft Access Driver (*.mdb)}

5. Latest users states that this is a "clean" system that is fairly new.

Any ideas would be greatly appreciated.

Take a look at this support article

http://support.microsoft.com/default.aspx/kb/271908

Hope this helps

Wednesday, March 7, 2012

Data Archiving

Production data is accumulating, I would like to archive old data.
I want the archive database has the whole and complete data for READ ONLY
(historical reporting, audit checking, etc).
Then production database becomes lightweight and able to perform update
efficiently.
Without replication, what do you suggest? Thanks for any help
I suggest a DTS task that runs over night and copies all-day new rows to the
backup database, so you can query and update the production database
efficiently. Also I suggest another server to host the backup database.
Hope this help.
"Need Help" <DONTSPAM@.DONTSPAM.com> wrote in message
news:%23rz8ERWTGHA.5656@.TK2MSFTNGP11.phx.gbl...
> Production data is accumulating, I would like to archive old data.
> I want the archive database has the whole and complete data for READ ONLY
> (historical reporting, audit checking, etc).
> Then production database becomes lightweight and able to perform update
> efficiently.
> Without replication, what do you suggest? Thanks for any help
>
|||Thanks for suggestion, but could DTS determine those existing rows that is
modified?
"Rodrigo Daz" <rdiazconcha@.hotmail.com.anti-spam.com> glsD:umoLiKXTGHA.1492@.TK2MSFTNGP10.phx.g bl...
I suggest a DTS task that runs over night and copies all-day new rows to the
backup database, so you can query and update the production database
efficiently. Also I suggest another server to host the backup database.
Hope this help.
"Need Help" <DONTSPAM@.DONTSPAM.com> wrote in message
news:%23rz8ERWTGHA.5656@.TK2MSFTNGP11.phx.gbl...
> Production data is accumulating, I would like to archive old data.
> I want the archive database has the whole and complete data for READ ONLY
> (historical reporting, audit checking, etc).
> Then production database becomes lightweight and able to perform update
> efficiently.
> Without replication, what do you suggest? Thanks for any help
>
|||No it could not, you need to flag these updated rows maybe with a column
with datetime datatype. Another solution that comes to my mind is using an
update/insert trigger to insert those rows to the backup database... in
this case you won't need DTS.
"Need Help" <DONTSPAM@.DONTSPAM.com> wrote in message
news:%231GaKwXTGHA.4616@.TK2MSFTNGP10.phx.gbl...
> Thanks for suggestion, but could DTS determine those existing rows that is
> modified?
>
>
> "Rodrigo Daz" <rdiazconcha@.hotmail.com.anti-spam.com>
> glsD:umoLiKXTGHA.1492@.TK2MSFTNGP10.phx.g bl...
> I suggest a DTS task that runs over night and copies all-day new rows to
> the
> backup database, so you can query and update the production database
> efficiently. Also I suggest another server to host the backup database.
> Hope this help.
> "Need Help" <DONTSPAM@.DONTSPAM.com> wrote in message
> news:%23rz8ERWTGHA.5656@.TK2MSFTNGP11.phx.gbl...
>

Data Archiving

Production data is accumulating, I would like to archive old data.
I want the archive database has the whole and complete data for READ ONLY
(historical reporting, audit checking, etc).
Then production database becomes lightweight and able to perform update
efficiently.
Without replication, what do you suggest? Thanks for any helpI suggest a DTS task that runs over night and copies all-day new rows to the
backup database, so you can query and update the production database
efficiently. Also I suggest another server to host the backup database.
Hope this help.
"Need Help" <DONTSPAM@.DONTSPAM.com> wrote in message
news:%23rz8ERWTGHA.5656@.TK2MSFTNGP11.phx.gbl...
> Production data is accumulating, I would like to archive old data.
> I want the archive database has the whole and complete data for READ ONLY
> (historical reporting, audit checking, etc).
> Then production database becomes lightweight and able to perform update
> efficiently.
> Without replication, what do you suggest? Thanks for any help
>|||Thanks for suggestion, but could DTS determine those existing rows that is
modified?
"Rodrigo Díaz" <rdiazconcha@.hotmail.com.anti-spam.com> ¼¶¼g©ó¶l¥ó·s»D:umoLiKXTGHA.1492@.TK2MSFTNGP10.phx.gbl...
I suggest a DTS task that runs over night and copies all-day new rows to the
backup database, so you can query and update the production database
efficiently. Also I suggest another server to host the backup database.
Hope this help.
"Need Help" <DONTSPAM@.DONTSPAM.com> wrote in message
news:%23rz8ERWTGHA.5656@.TK2MSFTNGP11.phx.gbl...
> Production data is accumulating, I would like to archive old data.
> I want the archive database has the whole and complete data for READ ONLY
> (historical reporting, audit checking, etc).
> Then production database becomes lightweight and able to perform update
> efficiently.
> Without replication, what do you suggest? Thanks for any help
>|||No it could not, you need to flag these updated rows maybe with a column
with datetime datatype. Another solution that comes to my mind is using an
update/insert trigger to insert those rows to the backup database... in
this case you won't need DTS.
"Need Help" <DONTSPAM@.DONTSPAM.com> wrote in message
news:%231GaKwXTGHA.4616@.TK2MSFTNGP10.phx.gbl...
> Thanks for suggestion, but could DTS determine those existing rows that is
> modified?
>
>
> "Rodrigo Díaz" <rdiazconcha@.hotmail.com.anti-spam.com>
> ¼¶¼g©ó¶l¥ó·s»D:umoLiKXTGHA.1492@.TK2MSFTNGP10.phx.gbl...
> I suggest a DTS task that runs over night and copies all-day new rows to
> the
> backup database, so you can query and update the production database
> efficiently. Also I suggest another server to host the backup database.
> Hope this help.
> "Need Help" <DONTSPAM@.DONTSPAM.com> wrote in message
> news:%23rz8ERWTGHA.5656@.TK2MSFTNGP11.phx.gbl...
>> Production data is accumulating, I would like to archive old data.
>> I want the archive database has the whole and complete data for READ ONLY
>> (historical reporting, audit checking, etc).
>> Then production database becomes lightweight and able to perform update
>> efficiently.
>> Without replication, what do you suggest? Thanks for any help
>

Data Archiving

Hi ,

I need to archive my production database to a new Server....

Is it possible to move data using INSERT INTO ServerName.DBName.dbo.TableName from the current Database Server!!!

Do I need to create a linked server to do this...or shoud I go for DTS..

Thanks
Cheriyan.You have too many options :
1.- Backup and restore in the new server.
2.- Create a linked server and generate a script to the all the insert..into your other tables.
3.- Use DTS.

If this is a one-time move, because a hardware upgrade, not a task that should be somewhat performed periodically, then take option 1.

Reagrds,

Data Archiving

Production data is accumulating, I would like to archive old data.
I want the archive database has the whole and complete data for READ ONLY
(historical reporting, audit checking, etc).
Then production database becomes lightweight and able to perform update
efficiently.
Without replication, what do you suggest? Thanks for any helpI suggest a DTS task that runs over night and copies all-day new rows to the
backup database, so you can query and update the production database
efficiently. Also I suggest another server to host the backup database.
Hope this help.
"Need Help" <DONTSPAM@.DONTSPAM.com> wrote in message
news:%23rz8ERWTGHA.5656@.TK2MSFTNGP11.phx.gbl...
> Production data is accumulating, I would like to archive old data.
> I want the archive database has the whole and complete data for READ ONLY
> (historical reporting, audit checking, etc).
> Then production database becomes lightweight and able to perform update
> efficiently.
> Without replication, what do you suggest? Thanks for any help
>|||Thanks for suggestion, but could DTS determine those existing rows that is
modified?
"Rodrigo Daz" <rdiazconcha@.hotmail.com.anti-spam.com> glsD:umoLiK
XTGHA.1492@.TK2MSFTNGP10.phx.gbl...
I suggest a DTS task that runs over night and copies all-day new rows to the
backup database, so you can query and update the production database
efficiently. Also I suggest another server to host the backup database.
Hope this help.
"Need Help" <DONTSPAM@.DONTSPAM.com> wrote in message
news:%23rz8ERWTGHA.5656@.TK2MSFTNGP11.phx.gbl...
> Production data is accumulating, I would like to archive old data.
> I want the archive database has the whole and complete data for READ ONLY
> (historical reporting, audit checking, etc).
> Then production database becomes lightweight and able to perform update
> efficiently.
> Without replication, what do you suggest? Thanks for any help
>|||No it could not, you need to flag these updated rows maybe with a column
with datetime datatype. Another solution that comes to my mind is using an
update/insert trigger to insert those rows to the backup database... in
this case you won't need DTS.
"Need Help" <DONTSPAM@.DONTSPAM.com> wrote in message
news:%231GaKwXTGHA.4616@.TK2MSFTNGP10.phx.gbl...
> Thanks for suggestion, but could DTS determine those existing rows that is
> modified?
>
>
> "Rodrigo Daz" <rdiazconcha@.hotmail.com.anti-spam.com>
> glsD:umoLiKXTGHA.1492@.TK2MSFTNGP10.phx.gbl...
> I suggest a DTS task that runs over night and copies all-day new rows to
> the
> backup database, so you can query and update the production database
> efficiently. Also I suggest another server to host the backup database.
> Hope this help.
> "Need Help" <DONTSPAM@.DONTSPAM.com> wrote in message
> news:%23rz8ERWTGHA.5656@.TK2MSFTNGP11.phx.gbl...
>

Saturday, February 25, 2012

Data and log files on separate disks

The production database of one of our clients is set up with both the data
and log files on the same disk. We suggested that they should separate them
out to eliminate disk contention and to eliminate I/O problems. The DBA at
the client site came back saying that he does not believe this is necessary.
Are we wrong in suggesting that the data and log files should be on separate
disks?
The client database is about 20 GB.
Thanks in advance.
"Frank1213" <Frank1213@.discussions.microsoft.com> wrote in message
news:80F4426D-0326-40D5-9EF4-B42853066EE6@.microsoft.com...
> The production database of one of our clients is set up with both the data
> and log files on the same disk. We suggested that they should separate
> them
> out to eliminate disk contention and to eliminate I/O problems. The DBA at
> the client site came back saying that he does not believe this is
> necessary.
> Are we wrong in suggesting that the data and log files should be on
> separate
> disks?
No, you're not.
However, whether it actually helps their performance is a good question.
If it's small enough and low volume enough, it won't help there.
If say the machine can only support 2 disks in a RAID 1 config, this
solution is "ok" given the machine.
If the machine can support more RAIDs (say 4 disks) then they're probably
better off separating them just because then if two disks fail, they're less
likely to actually suffer data loss.

> The client database is about 20 GB.
> Thanks in advance.
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html
|||Thanks for the reply. As I mentioned the database is about 20GB and there is
plenty of activity during office hours and during other scheduled task runs.
Do you still believe separating the data and log files will improve some of
the bottlenecks.
Thanks
"Greg D. Moore (Strider)" wrote:

> "Frank1213" <Frank1213@.discussions.microsoft.com> wrote in message
> news:80F4426D-0326-40D5-9EF4-B42853066EE6@.microsoft.com...
> No, you're not.
> However, whether it actually helps their performance is a good question.
> If it's small enough and low volume enough, it won't help there.
> If say the machine can only support 2 disks in a RAID 1 config, this
> solution is "ok" given the machine.
> If the machine can support more RAIDs (say 4 disks) then they're probably
> better off separating them just because then if two disks fail, they're less
> likely to actually suffer data loss.
>
>
> --
> Greg Moore
> SQL Server DBA Consulting Remote and Onsite available!
> Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html
>
>
|||"Frank1213" <Frank1213@.discussions.microsoft.com> wrote in message
news:9ABCC48E-C789-482F-8F42-D02AB663E307@.microsoft.com...
> Thanks for the reply. As I mentioned the database is about 20GB and there
> is
> plenty of activity during office hours and during other scheduled task
> runs.
> Do you still believe separating the data and log files will improve some
> of
> the bottlenecks.
Is it experiencing disk I/O bottlenecks?
If so, it would probably help. But again. 20GB and 'plenty of activity'
doesn't really tell enough to say for sure.
[vbcol=seagreen]
> Thanks
>
> "Greg D. Moore (Strider)" wrote:
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html
|||Frank1213 wrote:
> Thanks for the reply. As I mentioned the database is about 20GB and there is
> plenty of activity during office hours and during other scheduled task runs.
> Do you still believe separating the data and log files will improve some of
> the bottlenecks.
> Thanks
>
Hi,
Maybe you should ask is the disk is in their SAN. It's true that in most
cases it's good practice to have your database and logfiles on seperate
disk - both for performance reasons but also for disaster recovery
reasons. There are a few cases where this doesn't really make any
difference though. If they e.g. are using a HP EVA SAN there isn't any
performance reason to have the files on different disks because in the
end these disk will share the same physical spindles. The EVA SAN simply
puts all the disks in one big diskgroup and then on top of that you can
create your virtual disks. This means that if you create 2 virtual disks
and present to a server, the server will see it as 2 disks. In the end
it's not any different than just creating 1 virtual disk and put
everything on that single virtual disk - it's still the same physical
spindles it puts the data on.
If this is the case with your customer that could be the reason for why
the DBA answers like he do.
Regards
Steen Schlter Persson
Database Administrator / System Administrator
|||Thanks to both of you for your answers.
""Steen Schlüter Persson (DK)"" wrote:

> Frank1213 wrote:
> Hi,
> Maybe you should ask is the disk is in their SAN. It's true that in most
> cases it's good practice to have your database and logfiles on seperate
> disk - both for performance reasons but also for disaster recovery
> reasons. There are a few cases where this doesn't really make any
> difference though. If they e.g. are using a HP EVA SAN there isn't any
> performance reason to have the files on different disks because in the
> end these disk will share the same physical spindles. The EVA SAN simply
> puts all the disks in one big diskgroup and then on top of that you can
> create your virtual disks. This means that if you create 2 virtual disks
> and present to a server, the server will see it as 2 disks. In the end
> it's not any different than just creating 1 virtual disk and put
> everything on that single virtual disk - it's still the same physical
> spindles it puts the data on.
> If this is the case with your customer that could be the reason for why
> the DBA answers like he do.
> --
> Regards
> Steen Schlüter Persson
> Database Administrator / System Administrator
>

Data and log files on separate disks

The production database of one of our clients is set up with both the data
and log files on the same disk. We suggested that they should separate them
out to eliminate disk contention and to eliminate I/O problems. The DBA at
the client site came back saying that he does not believe this is necessary.
Are we wrong in suggesting that the data and log files should be on separate
disks?
The client database is about 20 GB.
Thanks in advance."Frank1213" <Frank1213@.discussions.microsoft.com> wrote in message
news:80F4426D-0326-40D5-9EF4-B42853066EE6@.microsoft.com...
> The production database of one of our clients is set up with both the data
> and log files on the same disk. We suggested that they should separate
> them
> out to eliminate disk contention and to eliminate I/O problems. The DBA at
> the client site came back saying that he does not believe this is
> necessary.
> Are we wrong in suggesting that the data and log files should be on
> separate
> disks?
No, you're not.
However, whether it actually helps their performance is a good question.
If it's small enough and low volume enough, it won't help there.
If say the machine can only support 2 disks in a RAID 1 config, this
solution is "ok" given the machine.
If the machine can support more RAIDs (say 4 disks) then they're probably
better off separating them just because then if two disks fail, they're less
likely to actually suffer data loss.
> The client database is about 20 GB.
> Thanks in advance.
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||Thanks for the reply. As I mentioned the database is about 20GB and there is
plenty of activity during office hours and during other scheduled task runs.
Do you still believe separating the data and log files will improve some of
the bottlenecks.
Thanks
"Greg D. Moore (Strider)" wrote:
> "Frank1213" <Frank1213@.discussions.microsoft.com> wrote in message
> news:80F4426D-0326-40D5-9EF4-B42853066EE6@.microsoft.com...
> > The production database of one of our clients is set up with both the data
> > and log files on the same disk. We suggested that they should separate
> > them
> > out to eliminate disk contention and to eliminate I/O problems. The DBA at
> > the client site came back saying that he does not believe this is
> > necessary.
> > Are we wrong in suggesting that the data and log files should be on
> > separate
> > disks?
> No, you're not.
> However, whether it actually helps their performance is a good question.
> If it's small enough and low volume enough, it won't help there.
> If say the machine can only support 2 disks in a RAID 1 config, this
> solution is "ok" given the machine.
> If the machine can support more RAIDs (say 4 disks) then they're probably
> better off separating them just because then if two disks fail, they're less
> likely to actually suffer data loss.
>
> > The client database is about 20 GB.
> > Thanks in advance.
>
> --
> Greg Moore
> SQL Server DBA Consulting Remote and Onsite available!
> Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html
>
>|||"Frank1213" <Frank1213@.discussions.microsoft.com> wrote in message
news:9ABCC48E-C789-482F-8F42-D02AB663E307@.microsoft.com...
> Thanks for the reply. As I mentioned the database is about 20GB and there
> is
> plenty of activity during office hours and during other scheduled task
> runs.
> Do you still believe separating the data and log files will improve some
> of
> the bottlenecks.
Is it experiencing disk I/O bottlenecks?
If so, it would probably help. But again. 20GB and 'plenty of activity'
doesn't really tell enough to say for sure.
> Thanks
>
> "Greg D. Moore (Strider)" wrote:
>> "Frank1213" <Frank1213@.discussions.microsoft.com> wrote in message
>> news:80F4426D-0326-40D5-9EF4-B42853066EE6@.microsoft.com...
>> > The production database of one of our clients is set up with both the
>> > data
>> > and log files on the same disk. We suggested that they should separate
>> > them
>> > out to eliminate disk contention and to eliminate I/O problems. The DBA
>> > at
>> > the client site came back saying that he does not believe this is
>> > necessary.
>> > Are we wrong in suggesting that the data and log files should be on
>> > separate
>> > disks?
>> No, you're not.
>> However, whether it actually helps their performance is a good question.
>> If it's small enough and low volume enough, it won't help there.
>> If say the machine can only support 2 disks in a RAID 1 config, this
>> solution is "ok" given the machine.
>> If the machine can support more RAIDs (say 4 disks) then they're probably
>> better off separating them just because then if two disks fail, they're
>> less
>> likely to actually suffer data loss.
>>
>> > The client database is about 20 GB.
>> > Thanks in advance.
>>
>> --
>> Greg Moore
>> SQL Server DBA Consulting Remote and Onsite available!
>> Email: sql (at) greenms.com
>> http://www.greenms.com/sqlserver.html
>>
--
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||Frank1213 wrote:
> Thanks for the reply. As I mentioned the database is about 20GB and there is
> plenty of activity during office hours and during other scheduled task runs.
> Do you still believe separating the data and log files will improve some of
> the bottlenecks.
> Thanks
>
Hi,
Maybe you should ask is the disk is in their SAN. It's true that in most
cases it's good practice to have your database and logfiles on seperate
disk - both for performance reasons but also for disaster recovery
reasons. There are a few cases where this doesn't really make any
difference though. If they e.g. are using a HP EVA SAN there isn't any
performance reason to have the files on different disks because in the
end these disk will share the same physical spindles. The EVA SAN simply
puts all the disks in one big diskgroup and then on top of that you can
create your virtual disks. This means that if you create 2 virtual disks
and present to a server, the server will see it as 2 disks. In the end
it's not any different than just creating 1 virtual disk and put
everything on that single virtual disk - it's still the same physical
spindles it puts the data on.
If this is the case with your customer that could be the reason for why
the DBA answers like he do.
--
Regards
Steen Schlüter Persson
Database Administrator / System Administrator|||Thanks to both of you for your answers.
""Steen Schlüter Persson (DK)"" wrote:
> Frank1213 wrote:
> > Thanks for the reply. As I mentioned the database is about 20GB and there is
> > plenty of activity during office hours and during other scheduled task runs.
> > Do you still believe separating the data and log files will improve some of
> > the bottlenecks.
> > Thanks
> >
> >
> Hi,
> Maybe you should ask is the disk is in their SAN. It's true that in most
> cases it's good practice to have your database and logfiles on seperate
> disk - both for performance reasons but also for disaster recovery
> reasons. There are a few cases where this doesn't really make any
> difference though. If they e.g. are using a HP EVA SAN there isn't any
> performance reason to have the files on different disks because in the
> end these disk will share the same physical spindles. The EVA SAN simply
> puts all the disks in one big diskgroup and then on top of that you can
> create your virtual disks. This means that if you create 2 virtual disks
> and present to a server, the server will see it as 2 disks. In the end
> it's not any different than just creating 1 virtual disk and put
> everything on that single virtual disk - it's still the same physical
> spindles it puts the data on.
> If this is the case with your customer that could be the reason for why
> the DBA answers like he do.
> --
> Regards
> Steen Schlüter Persson
> Database Administrator / System Administrator
>

Data and log files on separate disks

The production database of one of our clients is set up with both the data
and log files on the same disk. We suggested that they should separate them
out to eliminate disk contention and to eliminate I/O problems. The DBA at
the client site came back saying that he does not believe this is necessary.
Are we wrong in suggesting that the data and log files should be on separate
disks?
The client database is about 20 GB.
Thanks in advance."Frank1213" <Frank1213@.discussions.microsoft.com> wrote in message
news:80F4426D-0326-40D5-9EF4-B42853066EE6@.microsoft.com...
> The production database of one of our clients is set up with both the data
> and log files on the same disk. We suggested that they should separate
> them
> out to eliminate disk contention and to eliminate I/O problems. The DBA at
> the client site came back saying that he does not believe this is
> necessary.
> Are we wrong in suggesting that the data and log files should be on
> separate
> disks?
No, you're not.
However, whether it actually helps their performance is a good question.
If it's small enough and low volume enough, it won't help there.
If say the machine can only support 2 disks in a RAID 1 config, this
solution is "ok" given the machine.
If the machine can support more RAIDs (say 4 disks) then they're probably
better off separating them just because then if two disks fail, they're less
likely to actually suffer data loss.

> The client database is about 20 GB.
> Thanks in advance.
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||Thanks for the reply. As I mentioned the database is about 20GB and there is
plenty of activity during office hours and during other scheduled task runs.
Do you still believe separating the data and log files will improve some of
the bottlenecks.
Thanks
"Greg D. Moore (Strider)" wrote:

> "Frank1213" <Frank1213@.discussions.microsoft.com> wrote in message
> news:80F4426D-0326-40D5-9EF4-B42853066EE6@.microsoft.com...
> No, you're not.
> However, whether it actually helps their performance is a good question.
> If it's small enough and low volume enough, it won't help there.
> If say the machine can only support 2 disks in a RAID 1 config, this
> solution is "ok" given the machine.
> If the machine can support more RAIDs (say 4 disks) then they're probably
> better off separating them just because then if two disks fail, they're le
ss
> likely to actually suffer data loss.
>
>
> --
> Greg Moore
> SQL Server DBA Consulting Remote and Onsite available!
> Email: sql (at) greenms.com [url]http://www.greenms.com/sqlserver.html[/ur
l]
>
>|||"Frank1213" <Frank1213@.discussions.microsoft.com> wrote in message
news:9ABCC48E-C789-482F-8F42-D02AB663E307@.microsoft.com...
> Thanks for the reply. As I mentioned the database is about 20GB and there
> is
> plenty of activity during office hours and during other scheduled task
> runs.
> Do you still believe separating the data and log files will improve some
> of
> the bottlenecks.
Is it experiencing disk I/O bottlenecks?
If so, it would probably help. But again. 20GB and 'plenty of activity'
doesn't really tell enough to say for sure.
[vbcol=seagreen]
> Thanks
>
> "Greg D. Moore (Strider)" wrote:
>
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||Frank1213 wrote:
> Thanks for the reply. As I mentioned the database is about 20GB and there
is
> plenty of activity during office hours and during other scheduled task run
s.
> Do you still believe separating the data and log files will improve some o
f
> the bottlenecks.
> Thanks
>
Hi,
Maybe you should ask is the disk is in their SAN. It's true that in most
cases it's good practice to have your database and logfiles on seperate
disk - both for performance reasons but also for disaster recovery
reasons. There are a few cases where this doesn't really make any
difference though. If they e.g. are using a HP EVA SAN there isn't any
performance reason to have the files on different disks because in the
end these disk will share the same physical spindles. The EVA SAN simply
puts all the disks in one big diskgroup and then on top of that you can
create your virtual disks. This means that if you create 2 virtual disks
and present to a server, the server will see it as 2 disks. In the end
it's not any different than just creating 1 virtual disk and put
everything on that single virtual disk - it's still the same physical
spindles it puts the data on.
If this is the case with your customer that could be the reason for why
the DBA answers like he do.
Regards
Steen Schlter Persson
Database Administrator / System Administrator|||Thanks to both of you for your answers.
""Steen Schlüter Persson (DK)"" wrote:

> Frank1213 wrote:
> Hi,
> Maybe you should ask is the disk is in their SAN. It's true that in most
> cases it's good practice to have your database and logfiles on seperate
> disk - both for performance reasons but also for disaster recovery
> reasons. There are a few cases where this doesn't really make any
> difference though. If they e.g. are using a HP EVA SAN there isn't any
> performance reason to have the files on different disks because in the
> end these disk will share the same physical spindles. The EVA SAN simply
> puts all the disks in one big diskgroup and then on top of that you can
> create your virtual disks. This means that if you create 2 virtual disks
> and present to a server, the server will see it as 2 disks. In the end
> it's not any different than just creating 1 virtual disk and put
> everything on that single virtual disk - it's still the same physical
> spindles it puts the data on.
> If this is the case with your customer that could be the reason for why
> the DBA answers like he do.
> --
> Regards
> Steen Schlüter Persson
> Database Administrator / System Administrator
>

Data and log files and Raid

I have a development SQL 2000 server system running on Windows 2000 Pro.
I keep this system updated with all production data so I can test
everything.
This question might not be answerable without knowing what kind of data
I have, but I'll ask anyway.
I was thinking about adding a couple of SATA disks to the system. Here
are some possibilities:
1) Leave the log file on its current IDE disk, and set the new SATA
disks up as Raid 0, and put the data file there,
2) Move the log to one of the new SATA disks and the data to the other
SATA disk,
3) Set up the new SATA disks as Raid 0 and put the log and the data both
on the new RAID logical drive that results;
4) Some other arrangement?
It's a 45 GB database that's mostly used for reading (Select queries)
except when I update the database with new transactions and customer
account records daily.
One question...When writing data to a database, is the log file as
active as the data file? Isn't everything written to the log file and
then to the data file?
Thanks for any insight with this very general question.
David WalkerDWalker wrote:
> I have a development SQL 2000 server system running on Windows 2000 Pro.
> I keep this system updated with all production data so I can test
> everything.
> This question might not be answerable without knowing what kind of data
> I have, but I'll ask anyway.
> I was thinking about adding a couple of SATA disks to the system. Here
> are some possibilities:
> 1) Leave the log file on its current IDE disk, and set the new SATA
> disks up as Raid 0, and put the data file there,
> 2) Move the log to one of the new SATA disks and the data to the other
> SATA disk,
> 3) Set up the new SATA disks as Raid 0 and put the log and the data both
> on the new RAID logical drive that results;
> 4) Some other arrangement?
> It's a 45 GB database that's mostly used for reading (Select queries)
> except when I update the database with new transactions and customer
> account records daily.
> One question...When writing data to a database, is the log file as
> active as the data file? Isn't everything written to the log file and
> then to the data file?
> Thanks for any insight with this very general question.
> David Walker
>
Hi David,
All changes are written to the Log first and then to the Data files when
a Checkpoint occours. You could use (3) and leave the System tables on
the IDE disks. This would ensure speed and minimal security (if you
lose the RAID then the system tables are safe on the IDE, if you lose
the IDE then you have most likely lost the OS as well;)
James|||James Wilson <JamesWilson@.bryggemail.dk> wrote in
news:umGxjbwLGHA.3496@.TK2MSFTNGP14.phx.gbl:

> Hi David,
> All changes are written to the Log first and then to the Data files
> when a Checkpoint occours. You could use (3) and leave the System
> tables on the IDE disks. This would ensure speed and minimal security
> (if you lose the RAID then the system tables are safe on the IDE, if
> you lose the IDE then you have most likely lost the OS as well;)
> James
>
OK, thanks for the advice.
David

Data and log files and Raid

I have a development SQL 2000 server system running on Windows 2000 Pro.
I keep this system updated with all production data so I can test
everything.
This question might not be answerable without knowing what kind of data
I have, but I'll ask anyway.
I was thinking about adding a couple of SATA disks to the system. Here
are some possibilities:
1) Leave the log file on its current IDE disk, and set the new SATA
disks up as Raid 0, and put the data file there,
2) Move the log to one of the new SATA disks and the data to the other
SATA disk,
3) Set up the new SATA disks as Raid 0 and put the log and the data both
on the new RAID logical drive that results;
4) Some other arrangement?
It's a 45 GB database that's mostly used for reading (Select queries)
except when I update the database with new transactions and customer
account records daily.
One question...When writing data to a database, is the log file as
active as the data file? Isn't everything written to the log file and
then to the data file?
Thanks for any insight with this very general question.
David Walker
DWalker wrote:
> I have a development SQL 2000 server system running on Windows 2000 Pro.
> I keep this system updated with all production data so I can test
> everything.
> This question might not be answerable without knowing what kind of data
> I have, but I'll ask anyway.
> I was thinking about adding a couple of SATA disks to the system. Here
> are some possibilities:
> 1) Leave the log file on its current IDE disk, and set the new SATA
> disks up as Raid 0, and put the data file there,
> 2) Move the log to one of the new SATA disks and the data to the other
> SATA disk,
> 3) Set up the new SATA disks as Raid 0 and put the log and the data both
> on the new RAID logical drive that results;
> 4) Some other arrangement?
> It's a 45 GB database that's mostly used for reading (Select queries)
> except when I update the database with new transactions and customer
> account records daily.
> One question...When writing data to a database, is the log file as
> active as the data file? Isn't everything written to the log file and
> then to the data file?
> Thanks for any insight with this very general question.
> David Walker
>
Hi David,
All changes are written to the Log first and then to the Data files when
a Checkpoint occours. You could use (3) and leave the System tables on
the IDE disks. This would ensure speed and minimal security (if you
lose the RAID then the system tables are safe on the IDE, if you lose
the IDE then you have most likely lost the OS as well;)
James
|||James Wilson <JamesWilson@.bryggemail.dk> wrote in
news:umGxjbwLGHA.3496@.TK2MSFTNGP14.phx.gbl:

> Hi David,
> All changes are written to the Log first and then to the Data files
> when a Checkpoint occours. You could use (3) and leave the System
> tables on the IDE disks. This would ensure speed and minimal security
> (if you lose the RAID then the system tables are safe on the IDE, if
> you lose the IDE then you have most likely lost the OS as well;)
> James
>
OK, thanks for the advice.
David

Data and log files and Raid

I have a development SQL 2000 server system running on Windows 2000 Pro.
I keep this system updated with all production data so I can test
everything.
This question might not be answerable without knowing what kind of data
I have, but I'll ask anyway.
I was thinking about adding a couple of SATA disks to the system. Here
are some possibilities:
1) Leave the log file on its current IDE disk, and set the new SATA
disks up as Raid 0, and put the data file there,
2) Move the log to one of the new SATA disks and the data to the other
SATA disk,
3) Set up the new SATA disks as Raid 0 and put the log and the data both
on the new RAID logical drive that results;
4) Some other arrangement?
It's a 45 GB database that's mostly used for reading (Select queries)
except when I update the database with new transactions and customer
account records daily.
One question...When writing data to a database, is the log file as
active as the data file? Isn't everything written to the log file and
then to the data file?
Thanks for any insight with this very general question.
David WalkerDWalker wrote:
> I have a development SQL 2000 server system running on Windows 2000 Pro.
> I keep this system updated with all production data so I can test
> everything.
> This question might not be answerable without knowing what kind of data
> I have, but I'll ask anyway.
> I was thinking about adding a couple of SATA disks to the system. Here
> are some possibilities:
> 1) Leave the log file on its current IDE disk, and set the new SATA
> disks up as Raid 0, and put the data file there,
> 2) Move the log to one of the new SATA disks and the data to the other
> SATA disk,
> 3) Set up the new SATA disks as Raid 0 and put the log and the data both
> on the new RAID logical drive that results;
> 4) Some other arrangement?
> It's a 45 GB database that's mostly used for reading (Select queries)
> except when I update the database with new transactions and customer
> account records daily.
> One question...When writing data to a database, is the log file as
> active as the data file? Isn't everything written to the log file and
> then to the data file?
> Thanks for any insight with this very general question.
> David Walker
>
Hi David,
All changes are written to the Log first and then to the Data files when
a Checkpoint occours. You could use (3) and leave the System tables on
the IDE disks. This would ensure speed and minimal security (if you
lose the RAID then the system tables are safe on the IDE, if you lose
the IDE then you have most likely lost the OS as well;)
James|||James Wilson <JamesWilson@.bryggemail.dk> wrote in
news:umGxjbwLGHA.3496@.TK2MSFTNGP14.phx.gbl:
> Hi David,
> All changes are written to the Log first and then to the Data files
> when a Checkpoint occours. You could use (3) and leave the System
> tables on the IDE disks. This would ensure speed and minimal security
> (if you lose the RAID then the system tables are safe on the IDE, if
> you lose the IDE then you have most likely lost the OS as well;)
> James
>
OK, thanks for the advice.
David

Sunday, February 19, 2012

daily refresh of data

Hi
I have around 7 tables that get new data or updates in the production envt
and I would like to insert/update these tables on a daily basis in the
testing environment. Can you suggest a script to do this.
Thanks
Bob
=?Utf-8?B?Qm9i?= <Bob@.discussions.microsoft.com> wrote in
news:08545F94-6089-4A25-B925-51F321E0D4B2@.microsoft.com:

> I have around 7 tables that get new data or updates in the production
> envt and I would like to insert/update these tables on a daily basis
> in the testing environment. Can you suggest a script to do this.
To me, this looks like a task for SSIS, eh.. sorry, it's called DTS in the
"old" SQL Server 2000
Ole Kristian Bangs
MCT, MCDBA, MCDST, MCSE:Security, MCSE:Messaging
|||Bob
--New data
INSERT INTO TableA (<column lists>) SELECT <column lists> FROM TableB WHERE
NOT EXISTS (SELECT * FROM TableA WHERE TableA.PK=TableB.PK)
--Updated data
UPDATE TableA SET col=(SELECT col FROM TableB WHERE TableA.PK=TableB.PK AND
TableA.col<>Table.B.col) WHERE EXISTS (SELECT * FROM TableB WHERE
TableA.PK=TableB.PK AND TableA.col<>Table.B.col)
"Bob" <Bob@.discussions.microsoft.com> wrote in message
news:08545F94-6089-4A25-B925-51F321E0D4B2@.microsoft.com...
> Hi
> I have around 7 tables that get new data or updates in the production envt
> and I would like to insert/update these tables on a daily basis in the
> testing environment. Can you suggest a script to do this.
> Thanks
> Bob
|||Thank you for the reply, but the problem with the inserts and updates is that
each attribute in my table has referential integrity constraints and there
are 7-8 such constraints on the table. What strategy should I use to solve
this problem.
"Ole Kristian Bang?s" wrote:

> =?Utf-8?B?Qm9i?= <Bob@.discussions.microsoft.com> wrote in
> news:08545F94-6089-4A25-B925-51F321E0D4B2@.microsoft.com:
>
> To me, this looks like a task for SSIS, eh.. sorry, it's called DTS in the
> "old" SQL Server 2000
> --
> Ole Kristian Bang?s
> MCT, MCDBA, MCDST, MCSE:Security, MCSE:Messaging
>

daily refresh of data

Hi
I have around 7 tables that get new data or updates in the production envt
and I would like to insert/update these tables on a daily basis in the
testing environment. Can you suggest a script to do this.
Thanks
Bob=?Utf-8?B?Qm9i?= <Bob@.discussions.microsoft.com> wrote in
news:08545F94-6089-4A25-B925-51F321E0D4B2@.microsoft.com:
> I have around 7 tables that get new data or updates in the production
> envt and I would like to insert/update these tables on a daily basis
> in the testing environment. Can you suggest a script to do this.
To me, this looks like a task for SSIS, eh.. sorry, it's called DTS in the
"old" SQL Server 2000 :)
--
Ole Kristian Bangås
MCT, MCDBA, MCDST, MCSE:Security, MCSE:Messaging|||Bob
--New data
INSERT INTO TableA (<column lists>) SELECT <column lists> FROM TableB WHERE
NOT EXISTS (SELECT * FROM TableA WHERE TableA.PK=TableB.PK)
--Updated data
UPDATE TableA SET col=(SELECT col FROM TableB WHERE TableA.PK=TableB.PK AND
TableA.col<>Table.B.col) WHERE EXISTS (SELECT * FROM TableB WHERE
TableA.PK=TableB.PK AND TableA.col<>Table.B.col)
"Bob" <Bob@.discussions.microsoft.com> wrote in message
news:08545F94-6089-4A25-B925-51F321E0D4B2@.microsoft.com...
> Hi
> I have around 7 tables that get new data or updates in the production envt
> and I would like to insert/update these tables on a daily basis in the
> testing environment. Can you suggest a script to do this.
> Thanks
> Bob|||Thank you for the reply, but the problem with the inserts and updates is that
each attribute in my table has referential integrity constraints and there
are 7-8 such constraints on the table. What strategy should I use to solve
this problem.
"Ole Kristian Bangås" wrote:
> =?Utf-8?B?Qm9i?= <Bob@.discussions.microsoft.com> wrote in
> news:08545F94-6089-4A25-B925-51F321E0D4B2@.microsoft.com:
> > I have around 7 tables that get new data or updates in the production
> > envt and I would like to insert/update these tables on a daily basis
> > in the testing environment. Can you suggest a script to do this.
> To me, this looks like a task for SSIS, eh.. sorry, it's called DTS in the
> "old" SQL Server 2000 :)
> --
> Ole Kristian Bangås
> MCT, MCDBA, MCDST, MCSE:Security, MCSE:Messaging
>

daily refresh of data

Hi
I have around 7 tables that get new data or updates in the production envt
and I would like to insert/update these tables on a daily basis in the
testing environment. Can you suggest a script to do this.
Thanks
Bobexamnotes <Bob@.discussions.microsoft.com> wrote in
news:08545F94-6089-4A25-B925-51F321E0D4B2@.microsoft.com:

> I have around 7 tables that get new data or updates in the production
> envt and I would like to insert/update these tables on a daily basis
> in the testing environment. Can you suggest a script to do this.
To me, this looks like a task for SSIS, eh.. sorry, it's called DTS in the
"old" SQL Server 2000
Ole Kristian Bangs
MCT, MCDBA, MCDST, MCSE:Security, MCSE:Messaging|||Bob
--New data
INSERT INTO TableA (<column lists> ) SELECT <column lists> FROM TableB WHERE
NOT EXISTS (SELECT * FROM TableA WHERE TableA.PK=TableB.PK)
--Updated data
UPDATE TableA SET col=(SELECT col FROM TableB WHERE TableA.PK=TableB.PK AND
TableA.col<>Table.B.col) WHERE EXISTS (SELECT * FROM TableB WHERE
TableA.PK=TableB.PK AND TableA.col<>Table.B.col)
"Bob" <Bob@.discussions.microsoft.com> wrote in message
news:08545F94-6089-4A25-B925-51F321E0D4B2@.microsoft.com...
> Hi
> I have around 7 tables that get new data or updates in the production envt
> and I would like to insert/update these tables on a daily basis in the
> testing environment. Can you suggest a script to do this.
> Thanks
> Bob|||Thank you for the reply, but the problem with the inserts and updates is tha
t
each attribute in my table has referential integrity constraints and there
are 7-8 such constraints on the table. What strategy should I use to solve
this problem.
"Ole Kristian Bang?s" wrote:

> examnotes <Bob@.discussions.microsoft.com> wrote in
> news:08545F94-6089-4A25-B925-51F321E0D4B2@.microsoft.com:
>
> To me, this looks like a task for SSIS, eh.. sorry, it's called DTS in the
> "old" SQL Server 2000
> --
> Ole Kristian Bang?s
> MCT, MCDBA, MCDST, MCSE:Security, MCSE:Messaging
>