Showing posts with label website. Show all posts
Showing posts with label website. Show all posts

Wednesday, March 28, 2012

RAID 5 Issues

Someone posted a link a while back to a website that discussed potential
problems with RAID 5. I think it dealt mainly with spare sectors on IDE
drives, but I can't seem to find the link.
Does anyone have anything about why you should not use RAID 5 with a
database?
Thanks,
Rick Sawtell
RAID 5 is slower for write intensive operations. If your database requires
a lot of updates/inserts/deletes (maybe more than 15% write operations), I
would look into RAID 1 or RAID 1+0. Also, Transaction Logs shouldn't be put
on RAID 5 since they are write intensive by definition.
"Rick Sawtell" <r_sawtell@.hotmail.com> wrote in message
news:uL922T5XFHA.712@.TK2MSFTNGP14.phx.gbl...
> Someone posted a link a while back to a website that discussed potential
> problems with RAID 5. I think it dealt mainly with spare sectors on IDE
> drives, but I can't seem to find the link.
> Does anyone have anything about why you should not use RAID 5 with a
> database?
>
> Thanks,
>
> Rick Sawtell
>
|||"Michael C#" <howsa@.boutdat.com> wrote in message
news:OC5asj5XFHA.2124@.TK2MSFTNGP14.phx.gbl...
> RAID 5 is slower for write intensive operations. If your database
requires
> a lot of updates/inserts/deletes (maybe more than 15% write operations), I
> would look into RAID 1 or RAID 1+0. Also, Transaction Logs shouldn't be
put
> on RAID 5 since they are write intensive by definition.
>
All good points Michael, but I am still looking for the link.
There is a "movement" to get rid of RAID 5 for database usage. The article
is a bit inflammatory, however it was good food for thought.
Rick
|||Rick Sawtell wrote:
> "Michael C#" <howsa@.boutdat.com> wrote in message
> news:OC5asj5XFHA.2124@.TK2MSFTNGP14.phx.gbl...
> All good points Michael, but I am still looking for the link.
> There is a "movement" to get rid of RAID 5 for database usage. The
> article is a bit inflammatory, however it was good food for thought.
>
> Rick
No sure any of these are what you wanted. I remember an article from a
few months ago (can't find the link). The drive away from RAID 5 has a
lot to do with reduced performance if a drive fails and also drive
prices falling in recent years. It's not the right choice for log files
or tempdb, but for many databases is can be adequate if you can deal
with the possible performance issues during a drive rebuild.
http://www.talkaboutdatabases.com/gr...es/179342.html
http://www.dba-oracle.com/oracle_tips_raid5_bad.htm
David Gugick
Imceda Software
www.imceda.com
|||Xref: TK2MSFTNGP08.phx.gbl microsoft.public.sqlserver.server:392623
In article <OD9OuX6XFHA.2796@.TK2MSFTNGP09.phx.gbl>, davidg-
nospam@.imceda.com says...
> Rick Sawtell wrote:
> No sure any of these are what you wanted. I remember an article from a
> few months ago (can't find the link). The drive away from RAID 5 has a
> lot to do with reduced performance if a drive fails and also drive
> prices falling in recent years. It's not the right choice for log files
> or tempdb, but for many databases is can be adequate if you can deal
> with the possible performance issues during a drive rebuild.
> http://www.talkaboutdatabases.com/gr...es/179342.html
> http://www.dba-oracle.com/oracle_tips_raid5_bad.htm
I think, from my experience, the time when you see the most impact is
when the array consists of less than 5 drives. I've seen simple 3 x
drive R5 arrays kill a systems performance when on drive fails, but on 8
drive systems, when a drive fails, it's hardly noticed.
In these days when designers are less technical/experienced, we see a
lot of crappy solutions using something that someone has got from a
friend and failed to properly research.
I've seen soooooo many 3 x drive R5 solutions in the last 2 years that
I'm starting to wonder if I should put a question about R5 performance
on our employment test to weed out those that know from those that think
they know.
--
spam999free@.rrohio.com
remove 999 in order to email me
|||> > > "Michael C#" <howsa@.boutdat.com> wrote in message[vbcol=seagreen]
http://www.talkaboutdatabases.com/gr...es/179342.html[vbcol=seagreen]
Thanks Michael, it was on a link from a link of yours.
http://www.baarf.com/
This is what I was looking for.
Rick
|||Holy Cow...."AMEN"
We have been feverishly interviewing Sr. DBA Candidates to fill multiple
positions here.
We are getting some very impressive looking resumes.
However, I am blown away by the fact that whenever I ask even the most
simple quesiton about RAID nearly every single Candidate just stairs at me
with an open mouth.....
(Remember we're interviewing for "Senior" positions)...
The same thing is happening when we ask questions about Clustered Indexes,
PerfMon, Locking, etc.
Safe to say (At least in our market), you'll weed out a large percentage of
your candidates almost immediately by discussing RAID.
Greg Jackson
PDX, Oregon
|||Hi, Greg
> We have been feverishly interviewing Sr. DBA Candidates to fill multiple
> positions here.
I'm glad to see that American economy is recovering. Does your company
support H1B ?:-)
"pdxJaxon" <GregoryAJackson@.Hotmail.com> wrote in message
news:%23PYvRy6XFHA.3840@.tk2msftngp13.phx.gbl...
> Holy Cow...."AMEN"
>
> We have been feverishly interviewing Sr. DBA Candidates to fill multiple
> positions here.
> We are getting some very impressive looking resumes.
> However, I am blown away by the fact that whenever I ask even the most
> simple quesiton about RAID nearly every single Candidate just stairs at me
> with an open mouth.....
> (Remember we're interviewing for "Senior" positions)...
> The same thing is happening when we ask questions about Clustered Indexes,
> PerfMon, Locking, etc.
> Safe to say (At least in our market), you'll weed out a large percentage
of
> your candidates almost immediately by discussing RAID.
>
> Greg Jackson
> PDX, Oregon
>
|||In article <#PYvRy6XFHA.3840@.tk2msftngp13.phx.gbl>,
GregoryAJackson@.Hotmail.com says...
> Holy Cow...."AMEN"
>
> We have been feverishly interviewing Sr. DBA Candidates to fill multiple
> positions here.
> We are getting some very impressive looking resumes.
> However, I am blown away by the fact that whenever I ask even the most
> simple quesiton about RAID nearly every single Candidate just stairs at me
> with an open mouth.....
> (Remember we're interviewing for "Senior" positions)...
> The same thing is happening when we ask questions about Clustered Indexes,
> PerfMon, Locking, etc.
> Safe to say (At least in our market), you'll weed out a large percentage of
> your candidates almost immediately by discussing RAID.
Yea, I always ask about clustered indexes, locking, query plans, and
perfmon, then I give them a couple diagrams and see if they understand.
I had one that I always ask people about. The customer that you built an
application for about 1 year ago calls and tells you that all of their
queries from the web server fails for reports, but it works fine for
other queries, they say that some times the smaller ones fail too. Now,
you ask them run run the query in the QA and it works fine, but it takes
forever - what's the problem? If they don't mention reindexing the
database and maintenance I discount them and show them the door...
It's funny how senior production DBA's don't know about rebuilding
indexes to return query performance, or how the number of spindles in an
array makes a difference.
--
spam999free@.rrohio.com
remove 999 in order to email me
|||Last company I worked at Had the EXACT problem in production.
It took me 3 months (LITERALLY) to convice the Executives to over ride the
production DBAs recommendation and that we rebuild indexes.
Turns out we did not have a SINGLE clustered index in production (only a
handful of nonclustered), and there was NO index maintenance.
The Prod DBAs response was that "Index Maintenance is too expensive in a
24x7 operation so we just have to live with it"
After losing our largest customer, the execs Finally agreed to try Ol'
Jacksons trick and BAM no more problems...
GAJ
sql

RAID 5 Issues

Someone posted a link a while back to a website that discussed potential
problems with RAID 5. I think it dealt mainly with spare sectors on IDE
drives, but I can't seem to find the link.
Does anyone have anything about why you should not use RAID 5 with a
database?
Thanks,
Rick SawtellRAID 5 is slower for write intensive operations. If your database requires
a lot of updates/inserts/deletes (maybe more than 15% write operations), I
would look into RAID 1 or RAID 1+0. Also, Transaction Logs shouldn't be put
on RAID 5 since they are write intensive by definition.
"Rick Sawtell" <r_sawtell@.hotmail.com> wrote in message
news:uL922T5XFHA.712@.TK2MSFTNGP14.phx.gbl...
> Someone posted a link a while back to a website that discussed potential
> problems with RAID 5. I think it dealt mainly with spare sectors on IDE
> drives, but I can't seem to find the link.
> Does anyone have anything about why you should not use RAID 5 with a
> database?
>
> Thanks,
>
> Rick Sawtell
>|||"Michael C#" <howsa@.boutdat.com> wrote in message
news:OC5asj5XFHA.2124@.TK2MSFTNGP14.phx.gbl...
> RAID 5 is slower for write intensive operations. If your database
requires
> a lot of updates/inserts/deletes (maybe more than 15% write operations), I
> would look into RAID 1 or RAID 1+0. Also, Transaction Logs shouldn't be
put
> on RAID 5 since they are write intensive by definition.
>
All good points Michael, but I am still looking for the link.
There is a "movement" to get rid of RAID 5 for database usage. The article
is a bit inflammatory, however it was good food for thought.
Rick|||Rick Sawtell wrote:
> "Michael C#" <howsa@.boutdat.com> wrote in message
> news:OC5asj5XFHA.2124@.TK2MSFTNGP14.phx.gbl...
> All good points Michael, but I am still looking for the link.
> There is a "movement" to get rid of RAID 5 for database usage. The
> article is a bit inflammatory, however it was good food for thought.
>
> Rick
No sure any of these are what you wanted. I remember an article from a
few months ago (can't find the link). The drive away from RAID 5 has a
lot to do with reduced performance if a drive fails and also drive
prices falling in recent years. It's not the right choice for log files
or tempdb, but for many databases is can be adequate if you can deal
with the possible performance issues during a drive rebuild.
ml" target="_blank">http://www.talkaboutdatabases.com/g...42.ht
ml
http://www.dba-oracle.com/oracle_tips_raid5_bad.htm
David Gugick
Imceda Software
www.imceda.com|||Xref: TK2MSFTNGP08.phx.gbl microsoft.public.sqlserver.server:392623
In article <OD9OuX6XFHA.2796@.TK2MSFTNGP09.phx.gbl>, davidg-
nospam@.imceda.com says...
> Rick Sawtell wrote:
> No sure any of these are what you wanted. I remember an article from a
> few months ago (can't find the link). The drive away from RAID 5 has a
> lot to do with reduced performance if a drive fails and also drive
> prices falling in recent years. It's not the right choice for log files
> or tempdb, but for many databases is can be adequate if you can deal
> with the possible performance issues during a drive rebuild.
> html" target="_blank">http://www.talkaboutdatabases.com/g...42.
html
> http://www.dba-oracle.com/oracle_tips_raid5_bad.htm
I think, from my experience, the time when you see the most impact is
when the array consists of less than 5 drives. I've seen simple 3 x
drive R5 arrays kill a systems performance when on drive fails, but on 8
drive systems, when a drive fails, it's hardly noticed.
In these days when designers are less technical/experienced, we see a
lot of crappy solutions using something that someone has got from a
friend and failed to properly research.
I've seen soooooo many 3 x drive R5 solutions in the last 2 years that
I'm starting to wonder if I should put a question about R5 performance
on our employment test to weed out those that know from those that think
they know.
--
spam999free@.rrohio.com
remove 999 in order to email me|||> > > "Michael C#" <howsa@.boutdat.com> wrote in message[vbcol=seagreen]
http://www.talkaboutdatabases.com/g...ges/179342.html[vbcol=s
eagreen]
Thanks Michael, it was on a link from a link of yours.
http://www.baarf.com/
This is what I was looking for.
Rick|||Holy Cow...."AMEN"
We have been feverishly interviewing Sr. DBA Candidates to fill multiple
positions here.
We are getting some very impressive looking resumes.
However, I am blown away by the fact that whenever I ask even the most
simple quesiton about RAID nearly every single Candidate just stairs at me
with an open mouth.....
(Remember we're interviewing for "Senior" positions)...
The same thing is happening when we ask questions about Clustered Indexes,
PerfMon, Locking, etc.
Safe to say (At least in our market), you'll weed out a large percentage of
your candidates almost immediately by discussing RAID.
Greg Jackson
PDX, Oregon|||Hi, Greg
> We have been feverishly interviewing Sr. DBA Candidates to fill multiple
> positions here.
I'm glad to see that American economy is recovering. Does your company
support H1B ?:-)
"pdxJaxon" <GregoryAJackson@.Hotmail.com> wrote in message
news:%23PYvRy6XFHA.3840@.tk2msftngp13.phx.gbl...
> Holy Cow...."AMEN"
>
> We have been feverishly interviewing Sr. DBA Candidates to fill multiple
> positions here.
> We are getting some very impressive looking resumes.
> However, I am blown away by the fact that whenever I ask even the most
> simple quesiton about RAID nearly every single Candidate just stairs at me
> with an open mouth.....
> (Remember we're interviewing for "Senior" positions)...
> The same thing is happening when we ask questions about Clustered Indexes,
> PerfMon, Locking, etc.
> Safe to say (At least in our market), you'll weed out a large percentage
of
> your candidates almost immediately by discussing RAID.
>
> Greg Jackson
> PDX, Oregon
>|||In article <#PYvRy6XFHA.3840@.tk2msftngp13.phx.gbl>,
GregoryAJackson@.Hotmail.com says...
> Holy Cow...."AMEN"
>
> We have been feverishly interviewing Sr. DBA Candidates to fill multiple
> positions here.
> We are getting some very impressive looking resumes.
> However, I am blown away by the fact that whenever I ask even the most
> simple quesiton about RAID nearly every single Candidate just stairs at me
> with an open mouth.....
> (Remember we're interviewing for "Senior" positions)...
> The same thing is happening when we ask questions about Clustered Indexes,
> PerfMon, Locking, etc.
> Safe to say (At least in our market), you'll weed out a large percentage o
f
> your candidates almost immediately by discussing RAID.
Yea, I always ask about clustered indexes, locking, query plans, and
perfmon, then I give them a couple diagrams and see if they understand.
I had one that I always ask people about. The customer that you built an
application for about 1 year ago calls and tells you that all of their
queries from the web server fails for reports, but it works fine for
other queries, they say that some times the smaller ones fail too. Now,
you ask them run run the query in the QA and it works fine, but it takes
forever - what's the problem? If they don't mention reindexing the
database and maintenance I discount them and show them the door...
It's funny how senior production DBA's don't know about rebuilding
indexes to return query performance, or how the number of spindles in an
array makes a difference.
--
spam999free@.rrohio.com
remove 999 in order to email me|||Last company I worked at Had the EXACT problem in production.
It took me 3 months (LITERALLY) to convice the Executives to over ride the
production DBAs recommendation and that we rebuild indexes.
Turns out we did not have a SINGLE clustered index in production (only a
handful of nonclustered), and there was NO index maintenance.
The Prod DBAs response was that "Index Maintenance is too expensive in a
24x7 operation so we just have to live with it"
After losing our largest customer, the execs Finally agreed to try Ol'
Jacksons trick and BAM no more problems...
GAJ

RAID 5 Issues

Someone posted a link a while back to a website that discussed potential
problems with RAID 5. I think it dealt mainly with spare sectors on IDE
drives, but I can't seem to find the link.
Does anyone have anything about why you should not use RAID 5 with a
database?
Thanks,
Rick SawtellRAID 5 is slower for write intensive operations. If your database requires
a lot of updates/inserts/deletes (maybe more than 15% write operations), I
would look into RAID 1 or RAID 1+0. Also, Transaction Logs shouldn't be put
on RAID 5 since they are write intensive by definition.
"Rick Sawtell" <r_sawtell@.hotmail.com> wrote in message
news:uL922T5XFHA.712@.TK2MSFTNGP14.phx.gbl...
> Someone posted a link a while back to a website that discussed potential
> problems with RAID 5. I think it dealt mainly with spare sectors on IDE
> drives, but I can't seem to find the link.
> Does anyone have anything about why you should not use RAID 5 with a
> database?
>
> Thanks,
>
> Rick Sawtell
>|||"Michael C#" <howsa@.boutdat.com> wrote in message
news:OC5asj5XFHA.2124@.TK2MSFTNGP14.phx.gbl...
> RAID 5 is slower for write intensive operations. If your database
requires
> a lot of updates/inserts/deletes (maybe more than 15% write operations), I
> would look into RAID 1 or RAID 1+0. Also, Transaction Logs shouldn't be
put
> on RAID 5 since they are write intensive by definition.
>
All good points Michael, but I am still looking for the link.
There is a "movement" to get rid of RAID 5 for database usage. The article
is a bit inflammatory, however it was good food for thought.
Rick|||Rick Sawtell wrote:
> "Michael C#" <howsa@.boutdat.com> wrote in message
> news:OC5asj5XFHA.2124@.TK2MSFTNGP14.phx.gbl...
>> RAID 5 is slower for write intensive operations. If your database
>> requires a lot of updates/inserts/deletes (maybe more than 15% write
>> operations), I would look into RAID 1 or RAID 1+0. Also,
>> Transaction Logs shouldn't be put on RAID 5 since they are write
>> intensive by definition.
>>
> All good points Michael, but I am still looking for the link.
> There is a "movement" to get rid of RAID 5 for database usage. The
> article is a bit inflammatory, however it was good food for thought.
>
> Rick
No sure any of these are what you wanted. I remember an article from a
few months ago (can't find the link). The drive away from RAID 5 has a
lot to do with reduced performance if a drive fails and also drive
prices falling in recent years. It's not the right choice for log files
or tempdb, but for many databases is can be adequate if you can deal
with the possible performance issues during a drive rebuild.
http://www.talkaboutdatabases.com/group/comp.databases.informix/messages/179342.html
http://www.dba-oracle.com/oracle_tips_raid5_bad.htm
David Gugick
Imceda Software
www.imceda.com|||In article <OD9OuX6XFHA.2796@.TK2MSFTNGP09.phx.gbl>, davidg-
nospam@.imceda.com says...
> Rick Sawtell wrote:
> > "Michael C#" <howsa@.boutdat.com> wrote in message
> > news:OC5asj5XFHA.2124@.TK2MSFTNGP14.phx.gbl...
> >> RAID 5 is slower for write intensive operations. If your database
> >> requires a lot of updates/inserts/deletes (maybe more than 15% write
> >> operations), I would look into RAID 1 or RAID 1+0. Also,
> >> Transaction Logs shouldn't be put on RAID 5 since they are write
> >> intensive by definition.
> >>
> >>
> >
> > All good points Michael, but I am still looking for the link.
> >
> > There is a "movement" to get rid of RAID 5 for database usage. The
> > article is a bit inflammatory, however it was good food for thought.
> >
> >
> > Rick
> No sure any of these are what you wanted. I remember an article from a
> few months ago (can't find the link). The drive away from RAID 5 has a
> lot to do with reduced performance if a drive fails and also drive
> prices falling in recent years. It's not the right choice for log files
> or tempdb, but for many databases is can be adequate if you can deal
> with the possible performance issues during a drive rebuild.
> http://www.talkaboutdatabases.com/group/comp.databases.informix/messages/179342.html
> http://www.dba-oracle.com/oracle_tips_raid5_bad.htm
I think, from my experience, the time when you see the most impact is
when the array consists of less than 5 drives. I've seen simple 3 x
drive R5 arrays kill a systems performance when on drive fails, but on 8
drive systems, when a drive fails, it's hardly noticed.
In these days when designers are less technical/experienced, we see a
lot of crappy solutions using something that someone has got from a
friend and failed to properly research.
I've seen soooooo many 3 x drive R5 solutions in the last 2 years that
I'm starting to wonder if I should put a question about R5 performance
on our employment test to weed out those that know from those that think
they know.
--
spam999free@.rrohio.com
remove 999 in order to email me|||> > > "Michael C#" <howsa@.boutdat.com> wrote in message
> > > news:OC5asj5XFHA.2124@.TK2MSFTNGP14.phx.gbl...
> > >> RAID 5 is slower for write intensive operations. If your database
> > >> requires a lot of updates/inserts/deletes (maybe more than 15% write
> > >> operations), I would look into RAID 1 or RAID 1+0. Also,
> > >> Transaction Logs shouldn't be put on RAID 5 since they are write
> > >> intensive by definition.
> >
> >
http://www.talkaboutdatabases.com/group/comp.databases.informix/messages/179342.html
> > http://www.dba-oracle.com/oracle_tips_raid5_bad.htm
Thanks Michael, it was on a link from a link of yours.
http://www.baarf.com/
This is what I was looking for.
Rick|||Holy Cow...."AMEN"
We have been feverishly interviewing Sr. DBA Candidates to fill multiple
positions here.
We are getting some very impressive looking resumes.
However, I am blown away by the fact that whenever I ask even the most
simple quesiton about RAID nearly every single Candidate just stairs at me
with an open mouth.....
(Remember we're interviewing for "Senior" positions)...
The same thing is happening when we ask questions about Clustered Indexes,
PerfMon, Locking, etc.
Safe to say (At least in our market), you'll weed out a large percentage of
your candidates almost immediately by discussing RAID.
Greg Jackson
PDX, Oregon|||Hi, Greg
> We have been feverishly interviewing Sr. DBA Candidates to fill multiple
> positions here.
I'm glad to see that American economy is recovering. Does your company
support H1B ?:-)
"pdxJaxon" <GregoryAJackson@.Hotmail.com> wrote in message
news:%23PYvRy6XFHA.3840@.tk2msftngp13.phx.gbl...
> Holy Cow...."AMEN"
>
> We have been feverishly interviewing Sr. DBA Candidates to fill multiple
> positions here.
> We are getting some very impressive looking resumes.
> However, I am blown away by the fact that whenever I ask even the most
> simple quesiton about RAID nearly every single Candidate just stairs at me
> with an open mouth.....
> (Remember we're interviewing for "Senior" positions)...
> The same thing is happening when we ask questions about Clustered Indexes,
> PerfMon, Locking, etc.
> Safe to say (At least in our market), you'll weed out a large percentage
of
> your candidates almost immediately by discussing RAID.
>
> Greg Jackson
> PDX, Oregon
>|||In article <#PYvRy6XFHA.3840@.tk2msftngp13.phx.gbl>,
GregoryAJackson@.Hotmail.com says...
> Holy Cow...."AMEN"
>
> We have been feverishly interviewing Sr. DBA Candidates to fill multiple
> positions here.
> We are getting some very impressive looking resumes.
> However, I am blown away by the fact that whenever I ask even the most
> simple quesiton about RAID nearly every single Candidate just stairs at me
> with an open mouth.....
> (Remember we're interviewing for "Senior" positions)...
> The same thing is happening when we ask questions about Clustered Indexes,
> PerfMon, Locking, etc.
> Safe to say (At least in our market), you'll weed out a large percentage of
> your candidates almost immediately by discussing RAID.
Yea, I always ask about clustered indexes, locking, query plans, and
perfmon, then I give them a couple diagrams and see if they understand.
I had one that I always ask people about. The customer that you built an
application for about 1 year ago calls and tells you that all of their
queries from the web server fails for reports, but it works fine for
other queries, they say that some times the smaller ones fail too. Now,
you ask them run run the query in the QA and it works fine, but it takes
forever - what's the problem? If they don't mention reindexing the
database and maintenance I discount them and show them the door...
It's funny how senior production DBA's don't know about rebuilding
indexes to return query performance, or how the number of spindles in an
array makes a difference.
--
--
spam999free@.rrohio.com
remove 999 in order to email me|||Last company I worked at Had the EXACT problem in production.
It took me 3 months (LITERALLY) to convice the Executives to over ride the
production DBAs recommendation and that we rebuild indexes.
Turns out we did not have a SINGLE clustered index in production (only a
handful of nonclustered), and there was NO index maintenance.
The Prod DBAs response was that "Index Maintenance is too expensive in a
24x7 operation so we just have to live with it"
After losing our largest customer, the execs Finally agreed to try Ol'
Jacksons trick and BAM no more problems...
GAJ|||In article <#UqCE58XFHA.2520@.TK2MSFTNGP09.phx.gbl>,
GregoryAJackson@.Hotmail.com says...
> Last company I worked at Had the EXACT problem in production.
> It took me 3 months (LITERALLY) to convice the Executives to over ride the
> production DBAs recommendation and that we rebuild indexes.
> Turns out we did not have a SINGLE clustered index in production (only a
> handful of nonclustered), and there was NO index maintenance.
> The Prod DBAs response was that "Index Maintenance is too expensive in a
> 24x7 operation so we just have to live with it"
> After losing our largest customer, the execs Finally agreed to try Ol'
> Jacksons trick and BAM no more problems...
We get calls all the time from government groups with SQL problems, it's
almost always a case of a DBA that was really a programmer that could
spell DBA that got moved into the role as a production DBA. In every
case, there is no maintenance plan, other than backups, on the
databases.
I've even interviewed MCSD and MCDBA's that didn't have a clue about
reindexing as part of a maintenance plan, and they didn't understand
that the number of spindles impacts performance too :)
--
--
spam999free@.rrohio.com
remove 999 in order to email me|||Glad to help, but David posted those links :)
"Rick Sawtell" <r_sawtell@.hotmail.com> wrote in message
news:OYaUOi6XFHA.3488@.tk2msftngp13.phx.gbl...
>> > > "Michael C#" <howsa@.boutdat.com> wrote in message
>> > > news:OC5asj5XFHA.2124@.TK2MSFTNGP14.phx.gbl...
>> > >> RAID 5 is slower for write intensive operations. If your database
>> > >> requires a lot of updates/inserts/deletes (maybe more than 15% write
>> > >> operations), I would look into RAID 1 or RAID 1+0. Also,
>> > >> Transaction Logs shouldn't be put on RAID 5 since they are write
>> > >> intensive by definition.
>> >
>> >
> http://www.talkaboutdatabases.com/group/comp.databases.informix/messages/179342.html
>> > http://www.dba-oracle.com/oracle_tips_raid5_bad.htm
>
> Thanks Michael, it was on a link from a link of yours.
> http://www.baarf.com/
> This is what I was looking for.
>
> Rick
>|||"Uri Dimant" <urid@.iscar.co.il> wrote in message
news:u1d5%2346XFHA.2540@.tk2msftngp13.phx.gbl...
> Hi, Greg
>> We have been feverishly interviewing Sr. DBA Candidates to fill multiple
>> positions here.
> I'm glad to see that American economy is recovering. Does your company
> support H1B ?:-)
They all do, directly or indirectly.|||Hi, Mike
> They all do, directly or indirectly.
How do you know? :-)
I'm on my way to buy one way ticket :-)
"Michael C#" <howsa@.boutdat.com> wrote in message
news:uPOTdpGYFHA.3040@.TK2MSFTNGP14.phx.gbl...
> "Uri Dimant" <urid@.iscar.co.il> wrote in message
> news:u1d5%2346XFHA.2540@.tk2msftngp13.phx.gbl...
> > Hi, Greg
> >> We have been feverishly interviewing Sr. DBA Candidates to fill
multiple
> >> positions here.
> >
> > I'm glad to see that American economy is recovering. Does your company
> > support H1B ?:-)
> They all do, directly or indirectly.
>|||"Uri Dimant" <urid@.iscar.co.il> wrote in message
news:O4Yfy5GYFHA.3164@.TK2MSFTNGP09.phx.gbl...
> Hi, Mike
>> They all do, directly or indirectly.
> How do you know? :-)
> I'm on my way to buy one way ticket :-)
H1B's are approved each year by Congress. We all pay taxes :)|||Uri,
I believe we have employees working here that are H1B.
Dont quote me on that as I generally mind my own business and I'm not an
H.R. Representative.
Greg Jackson
PDX, Oregon

Tuesday, March 20, 2012

Quotation Marks in SQL Server

I have an ASP.Net page that allows people to type in strings and store them into a SQL Server DB; which in turn gets displayed on a website.

The project has an admin side that can add/delete/edit announcements, which get displayed on an intranet site. These announcements can be clicked on to display further detail. When announcements are clicked on a javascript popup window is generated that displays the strings. All data is stored in a SQL Server DB.

What I need to know is: how do I check to see if a string has a quotation mark or apostrophe in it so that I can replace it with the appropriate HTML code? (Though it seems I can't display an apostrophe, even when using the HTML code ''')

If I store the string as was entered by the administrator (with quotation marks instead of '"'), the popup window will not display.

Try the links below for all the info you need including how to enable QUOTED_IDENTIFIER option in your create database statement and the restrictions. Hope this helps.

http://msdn2.microsoft.com/en-US/library/ms174393.aspx

http://msdn2.microsoft.com/en-US/library/ms176027.aspx

|||

Search the forums for:

A) Parameterized SQL Query (What you should do)

B) SQL String concatenation (What you are probably doing)

C) SQL Injection attack (The security problems of doing B instead of A)

|||

Motley:

Search the forums for:

A) Parameterized SQL Query (What you should do)

B) SQL String concatenation (What you are probably doing)

C) SQL Injection attack (The security problems of doing B instead of A)

Not worried about SQL Injection attacks. This is an intranet app.|||

Caddre:

Try the links below for all the info you need including how to enable QUOTED_IDENTIFIER option in your create database statement and the restrictions. Hope this helps.

http://msdn2.microsoft.com/en-US/library/ms174393.aspx

http://msdn2.microsoft.com/en-US/library/ms176027.aspx

Can you enable the Quoted_Identifier only when you create a new table?|||You can do it in your create database statement or create table, the how for table is covered in the second link. Hope this helps.|||After reading the replies and links that were posted, I feel that I need to reiterate my question.

There is a page that displays records from a SQL Server DB. These records are "announcements" on an internal bulletin board. An admin has a special page that gives the admin the ability to edit, add or delete any of these records.

For instance, an admin can add an announcement (using a textbox) that says, 'This sentence has "Quotation Marks" in it'. I want to be able to search that specific phrase for the quotation marks and replace them with the appropriate code so that they may be displayed on the bulletin board. I don't want the admin to have to type double quotes or double apostrophes in order for them to show up.

The page needs to be user friendly with any concates or alterations to occur server side.

So if anyone can tell me the proper way of say

if str.chars(x) = "<quotation>" then ...

that would be much appreciated.

This is the javascript that generates the pop-up window:
Alert Descrip

<script language="javascript">
//popup function which recieves the email group description and name as parameters
function popitup3(description, name)
{
newwindow2=window.open('','name','height=400,width=600,scrollbars=yes');
var tmp = newwindow2.document;
tmp.write('<html><head><title>Alert Description</title>');
tmp.write('</head><body><font face="verdana, tahoma, sans-serif" size="2"');
tmp.write('b><br><p align="justify">');
tmp.write(description);
tmp.write('</p><p><a href="javascript:self.close()">close</a> this window.</p>');
tmp.write('</body></html>');
tmp.close();
}
</script>
Variable description is where the text with the quotes would most likely be.|||

I am sorry I did not understand your original post you are looking for ANSI SQL LIKE and Pattern search. Try the link below for sample code. Hope this helps.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_la-lz_115x.asp