New answers tagged best-practices
0
You almost certainly have a very large number of virtual log files (VLFs) in the problematic log file of the database in question. Shutting down and restarting SQL Server causes the recovery process to run on all databases on the instance. For databases that have a very large number of VLFs this process can be agonizingly slow.
You can see the VLFs via ...
0
I'm putting this as an answer because it's too long as a comment. It makes a lot of assumptions, but this could be one method. It's definitely a bit hokey but should work fairly reliably without creating objects in your target database. I think a temp table or other staging area may be required depending on what's doing the bulk import for you, but here ...
-1
Certainly, it will work:
INSERT INTO myTable
(
ID,
Data
)
SELECT MAX(ID)+1, "My actual data" FROM myTable;
0
While AMM seems to work fine, as others have pointed out if you are using Linux, you will save a consiferable amount of memory if you use HugePages. This means that you can't use AMM. You can test what that value will be with AMM and no huge pages for a given SGA/PGA and you can test the same with HugePages and a similar SGA/PGA. If you are on Linux and your ...
1
What version of Oracle are you using? Are you actually setting values for the SGA components and/ or the PGA separately? If so, why? If you're using a recent version of Oracle, the starting point would normally be to set memory_target and let Oracle size the various memory components automatically. Unless, of course, you have some reason to need to set ...
0
it depends on the failure mechanism you prefer.
If, when a new column is added, it can always be safely ignored (eg: select firstname,lastname from customers where id=@x), then never use select * - the more columns you touch, the less chance that a helpful index can be found/created.
If when a new column is added, silent discarding of it would be bad (any ...
Top 50 recent answers are included
