Go away. Your last thread on the same topic was boring enough

I think someone needs to perform maint on his own database

2 threads?! Sad thing is I don't have any popcorn and the topic is kinda boring too.

IzakiBrotheSs wrote: »

2 threads?! Sad thing is I don't have any popcorn and the topic is kinda boring too.

Popcorn?

bruuuuuh i manage like 30,000 databases and we do maintenance on them nearly daily... running optimizations jobs is an every 3-day thing... A database that receives as many calls and updates as a game's database would definitely need to be taken offline to run optimizations...

gotta remember, bruuuuuh, if you're doing defrags and you've got 1000x requests to lock tables, rows, columns, or even pages, that defrag is going to fail and all of your TSQLs are going to fall apart.

If this wasn't happening, would you be here complaining about the horrendous lag in game?

you could maybe design a redundant system that moves mirrors into principal to do defrags but then how do you reconcile without restoring the whole database, ie causing tremendous lag and risking tons of blocks and possible deadlocks and possible data corruption?

dafug out of here.

alphaturu wrote: »

I'm wondering why the hell they are closing the *** servers on WEEKENDS. This IS so not [SNIP] cool

@alphaturu stop crying. With a minimal effort on your part you can see why the game was brought down this weekend. Life is full of disappointments. Somehow you'll go on.

This game has over 100,000 concurrent players, all making SELECT and UPDATE requests several times per minute. Sure, you can likely develop a cache-system to interact with the database only every once in a while but then you've got some serious risk as far as integrity goes, and I don't doubt that they cache at the application level, within reason.

The longer you wait to run your defrags, the longer they take to complete. Please, show me your t-sql that allows for live-defrag while thousands of transactions are in play. I manage some 30,000 databases and we only defrag during very low-use times... in many cases, we have methods of creating temporary databases, to only call what is necessary for operation while the maintenance jobs are running... This is only practical if your temporary database consists of less than a gig of data, and you have less than 100 open SPIDs at the time of execution, because the reconciliation takes literally 6 hours.

For ESO, you're talking probably 100,000 SPIDs open at all times. You're talking page-level locks being requested multiple times per second. You're talking about a database whose consistency is paramount. How do you propose maintaining this DB without downtime? I guess we could postpone and do this maintenance once a month, but then we've got more performance degradation as the database becomes more and more fragmented.... and then the maintenance job and especially backups will take forever...

You say you can do this better, I sincerely doubt it. I do this sort of thing for a living and if you had the magic you claim you have, I feel as though I would know who you are and would likely have read your blogs or your articles or your guides or implemented your code somewhere.... but I probably haven't...

TL;DR please link your github or GTFO