meta user
network profile
| bio | website | careers.stackoverflow.com/cv/… |
|---|---|---|
| location | Iasi, Romania | |
| age | 32 | |
| visits | member for | 2 years, 5 months |
| seen | 32 mins ago | |
| stats | profile views | 662 |
Development DBA for a medium sized project team. Part of a 3 DBAs team and working in close touch with about 30 developers.
I'm here to learn from the best and share my knowledge. Proud and happy to be a part of such a great community.
You can find me here:
|
9h |
reviewed | Approve suggested edit on Connecting to Oracle from SSIS using ODBC |
|
11h |
comment |
Recover data from accidental update Going from OP's comment "Transaction Logs are not enabled" I'd say the tail of the log becomes a huge t-log backup. Hopefully he has full backups to start on. |
|
Jun 15 |
comment |
High CPU usage on SQL server - Slow queries When you verify the queries with Profiler, do you also check the CPU column? Is it the same as when everything is silent? Do the queries have the same CPU/Reads/Writes values in both silent and high CPU times? Regarding the host, is there anything capping your virtual CPU during that time? Is there something else that's running on another VM on the same host AT the same time (maybe some intensive calculations)? |
|
Jun 15 |
comment |
High CPU usage on SQL server - Slow queries Please verify what power plan your VM (and the host) is using. Some older blog of Glen Berry mentioned big differences in performance with different power plans. |
|
Jun 14 |
comment |
High CPU usage on SQL server - Slow queries @LeviJohansen If DMV queries are hard to read, give a try to Confio's Ignite free edition. It might be easier to spot the guilty queries in their graphs. Forgot to say, don't install it on the same machine as the DB server, install it on a different server, so you avoid inserting new variables into the equation. |
|
Jun 14 |
comment |
High CPU usage on SQL server - Slow queries @StanleyJohns: yes, you're right, I misread it. Thanks! |
|
Jun 14 |
comment |
High CPU usage on SQL server - Slow queries So what? Data never grows? Data never changes? Are you in on a constant sized data set? |
|
Jun 14 |
comment |
High CPU usage on SQL server - Slow queries "Clear out the CPU cache" - that's a few MB at most. Why'd you want to clear that out? And yes, it's disabled because you only have one CPU. You can see details about affinity masks here. PS: don't fiddle with affinity masks. It will be removed in the future. |
|
Jun 14 |
comment |
Is backing a website by a SQL Server 2012 OLAP cube considered reasonable? I suspect the first option (with SSAS and cubes) may already be in place for the retail chain analysts. In retail they usually do the data mining stuff, but not deliver it to the end customers, yet. PS: You can read a short review about some working BI controls for web apps (in ASP.NET) in my SO answer. |
|
Jun 11 |
comment |
Severity 016 Backup virtual device fail Is there any external SAN backup/snapshot tool doing its work at the same time? |
|
Jun 8 |
comment |
Update a table from a join Why would you want to avoid deadlocks? I love them :-). |
|
Jun 8 |
comment |
Can I optimize this MERGE statement? You might benefit from reading the following blog post of Paul White: Optimizing T-SQL queries that change data. |
|
Jun 5 |
comment |
Reduce Clustered Index seek cost SQL Server 2008 R2 I saw, looks like you're limited by the disk, like Aaron or Oleg already pointed. Not sure you can do more about this, maybe update statistics (to help the optimizer choose a better plan) and rebuild all indexes, but it's more of a blind shot. |
|
Jun 4 |
comment |
Reduce Clustered Index seek cost SQL Server 2008 R2 Can you update the statistics of the tables involved (to remove the discrepancy between actual and estimated rows)? |
|
Jun 4 |
comment |
Reduce Clustered Index seek cost SQL Server 2008 R2 First observation: your stats seem stale, look at the data line coming from tbl_Survey_Details (actual no of rows = 250k, estimated = 1). Same for tbl_Location and others. That Nested Loop is bit of a killer there (both operators are big, NL is appropriate when one table is pretty small). The table scan for [@temp] shows it has 750K rows, while the first insert shows 3 rows. Which one is correct? If the first one, then you should replace the [@temp] with a #temp table (with index on the join columns). |
|
Jun 4 |
reviewed | Close How to Full Backup, Differential Backup & Transactional Backup Oracle in Linux OS |
|
Jun 4 |
reviewed | Leave Open Slow SSRS Report in production |
|
Jun 4 |
reviewed | Reviewed Create Oracle ASM Disks Without Installing Oracle |
|
Jun 4 |
reviewed | Reject suggested edit on Advantages and Disadvantages to using ENUM vs Integer types? |
|
Jun 2 |
comment |
Reduce Clustered Index seek cost SQL Server 2008 R2 the main problem I have with the pic (not with the real plan itself) is that I can't see the real numbers (estimated rows vs actual rows, no of executions for certain operations). Call it laziness, yes, maybe you're right. But I still prefer the real plan. |
