Hot answers tagged


There is a clear answer in the manual: During an UPDATE operation, values of unchanged fields are normally preserved as-is; so an UPDATE of a row with out-of-line values incurs no TOAST costs if none of the out-of-line values change. That's one of the main benefits of an UPDATE over DELETE + INSERT (while either writes a new row version).


You should read this article SQL varchar data type deep dive, and specifically the Storage and performance considerations using SQL varchar section: Because of the fixed field lengths, data is pulled straight from the column without doing any data manipulation and index lookups against varchar are slower than that of char fields. CHAR is better than VARCHAR ...


But a single row can contain more than 1000 criteria No, you are predicating your data design on a flawed relational model. Putting the cart before the horse. The tail is wagging the dog. I think you mean that a single entity can have 1000 attributes. In such a scenario, and particularly when most are null, the best solution is usually an Entity-Attribute-...


As Dan mentioned, columnstore indexing is one relevant feature of SQL Server that might be helpful to your situation. Additionally, SQL Server offers data compression in other ways such as across the row or down the entire page of data when it's stored in a rowstore as well, which also may be helpful in your case depending on your data.


You can do it, it doesn't mean you should. There is many things to take into account, like performances and reliability. Putting the files on the network will probably cause you some performance problems as data needs to be moved across the network for every read, insert, update, delete. If you have historic data, then maybe you could consider putting those ...


Is this a concern and going against the above recommendation? That depends on your workload, number and size of IO operations with data files and TempDB, and SAN configuration (number of LUNs/RAID groups, and how logical drives are tied to these) If you see any signs of performance degradation: messages in the Event log "SQL Server has encountered ...


Got an answer back from AWS support. It appears the problem came from not having enough space left for inodes. We cannot control allocated space for inodes on RDS so the only solution here is to get a bigger instance. The OOM Killer allowed to get our instance running again.


I have considered changing this to 5, however 7 days just seems simpler as we hardly have any activity running over the weekend. I think you may be misunderstanding what that means. Oracle will keep every file it needs to be able to Recover your database back to a point in time five days ago. You can take backups as often as you like during those five days ...


The impact should be minimal, if not non-existent. I've had several databases of varying sizes (both in storage and cluster) and types (MySQL, Postgres, Cassandra, to name a few) migrated between different storage environments with little impact to the end user. The VM always stays online and is usable just as it was prior to the vMotion. If it's a: ...

Only top voted, non community-wiki answers of a minimum length are eligible