Installing Exchange
-
@nadnerB said:
Well, you can have every user in their own database if you really wanted to. That would be horrid but you COULD do it.
i could only do that if I bought Enterprise edition - and that would be just crazy
-
The concept of splitting the database and logs is based on the antiquated thought that no one could possibly afford RAID 10 for the database and had to cut corners and get RAID 5. If you are not using RAID 5 on spinning disks, then your logs do not get split from the database. They perform better being on the same array, not two different ones.
-
@scottalanmiller said:
The concept of splitting the database and logs is based on the antiquated thought that no one could possibly afford RAID 10 for the database and had to cut corners and get RAID 5. If you are not using RAID 5 on spinning disks, then your logs do not get split from the database. They perform better being on the same array, not two different ones.
So in my case, they aren't suggesting RAID 5, because I don't have a storage need? LOL - yeah this tool really is just old! and nearly useless!
-
@Dashrender said:
@scottalanmiller said:
The concept of splitting the database and logs is based on the antiquated thought that no one could possibly afford RAID 10 for the database and had to cut corners and get RAID 5. If you are not using RAID 5 on spinning disks, then your logs do not get split from the database. They perform better being on the same array, not two different ones.
So in my case, they aren't suggesting RAID 5, because I don't have a storage need? LOL - yeah this tool really is just old! and nearly useless!
uhm..... I'd say drop the nearly on nearly useless.
-
@travisdh1 said:
@Dashrender said:
@scottalanmiller said:
The concept of splitting the database and logs is based on the antiquated thought that no one could possibly afford RAID 10 for the database and had to cut corners and get RAID 5. If you are not using RAID 5 on spinning disks, then your logs do not get split from the database. They perform better being on the same array, not two different ones.
So in my case, they aren't suggesting RAID 5, because I don't have a storage need? LOL - yeah this tool really is just old! and
nearlyuseless!uhm..... I'd say drop the nearly on
nearlyuseless.FTFY
-
@Dashrender said:
@scottalanmiller said:
The concept of splitting the database and logs is based on the antiquated thought that no one could possibly afford RAID 10 for the database and had to cut corners and get RAID 5. If you are not using RAID 5 on spinning disks, then your logs do not get split from the database. They perform better being on the same array, not two different ones.
So in my case, they aren't suggesting RAID 5, because I don't have a storage need? LOL - yeah this tool really is just old! and nearly useless!
Yeah, it's worse than useless, it is actively misleading. Pretty much for most Exchange current installs you can make due just fine with RAID 1 and done.
-
That's going to be my new phrase...
RAID 1 and Done.
-
@scottalanmiller said:
That's going to be my new phrase...
RAID 1 and Done.
Sounds like a new SMBITJournal article in the making, ha ha ha.
-
@scottalanmiller said:
@Dashrender said:
To me it feels like the author is still approaching it from an old school disk performance perspective. One that perhaps wasn't ever really valid (but maybe it was).
I wouldn't call it old school. This was always a silly practice. It's more of just not understanding why things were done and applying them at the wrong time. He is, I think, confusing 1990's array tuning with partition log growth protection.
What, you mean to tell me putting my database on the inside tracks of my disk is no longer valid? What about when I use my SSDs, surely they will appreciate the lower access time of being closer to the controller!
-
@PSX_Defector said:
@scottalanmiller said:
@Dashrender said:
To me it feels like the author is still approaching it from an old school disk performance perspective. One that perhaps wasn't ever really valid (but maybe it was).
I wouldn't call it old school. This was always a silly practice. It's more of just not understanding why things were done and applying them at the wrong time. He is, I think, confusing 1990's array tuning with partition log growth protection.
What, you mean to tell me putting my database on the inside tracks of my disk is no longer valid? What about when I use my SSDs, surely they will appreciate the lower access time of being closer to the controller!
OMG short stroking.... it's been forever since I heard people talking about that.
-
I always buy extra short cables to improve latency.
-
-
-
@scottalanmiller said:
@PSX_Defector said:
@scottalanmiller said:
@Dashrender said:
To me it feels like the author is still approaching it from an old school disk performance perspective. One that perhaps wasn't ever really valid (but maybe it was).
I wouldn't call it old school. This was always a silly practice. It's more of just not understanding why things were done and applying them at the wrong time. He is, I think, confusing 1990's array tuning with partition log growth protection.
What, you mean to tell me putting my database on the inside tracks of my disk is no longer valid? What about when I use my SSDs, surely they will appreciate the lower access time of being closer to the controller!
OMG short stroking.... it's been forever since I heard people talking about that.
Last time someone mentioned it to me was back in 2011. Had to correct the fool about the fact he was running on a huge HP 585 using 15K RPM SAS drives. Even if we could lay out the sectors that way, it was no longer applicable because the controller was the bottleneck at that point.
These old ass ways of thinking still permeate various circles. Especially in old school mainframe guys, the ones who don't giggle when you mention you once had a Wang.
-
@Jason said:
@scottalanmiller said:
I always buy extra short cables to improve latency.
OMG - who is that guy clowning on?
-
@PSX_Defector said:
@scottalanmiller said:
@PSX_Defector said:
@scottalanmiller said:
@Dashrender said:
To me it feels like the author is still approaching it from an old school disk performance perspective. One that perhaps wasn't ever really valid (but maybe it was).
I wouldn't call it old school. This was always a silly practice. It's more of just not understanding why things were done and applying them at the wrong time. He is, I think, confusing 1990's array tuning with partition log growth protection.
What, you mean to tell me putting my database on the inside tracks of my disk is no longer valid? What about when I use my SSDs, surely they will appreciate the lower access time of being closer to the controller!
OMG short stroking.... it's been forever since I heard people talking about that.
Last time someone mentioned it to me was back in 2011. Had to correct the fool about the fact he was running on a huge HP 585 using 15K RPM SAS drives. Even if we could lay out the sectors that way, it was no longer applicable because the controller was the bottleneck at that point.
These old ass ways of thinking still permeate various circles. Especially in old school mainframe guys, the ones who don't giggle when you mention you once had a Wang.
LOL - I've actually never heard someone talk about doing this... not surprised... but damn!
-
Back on topic, I found the msexchange.org guides to be very thorough. I used the 2007 to 2013 one over the weekend and 2007 to 2010 in the past.
I will admit, that I did ignore all the info on sizing and running the MS tools and shit.
-
@JaredBusch said:
Back on topic, I found the msexchange.org guides to be very thorough. I used the 2007 to 2013 one over the weekend and 2007 to 2010 in the past.
I will admit, that I did ignore all the info on sizing and running the MS tools and shit.
Agreed - the sizing/drive layout seem to be where they are completely crazy.. the rest seems fine, even if occasionally a little light on documentation.
