Showing posts with label Database. Show all posts
Showing posts with label Database. Show all posts

Wednesday, January 7, 2015

Upgrade MongoDB MMS monitoring agent

PROBLEM:
How to upgrade MongoDB MMS monitoring agent?

SOLUTION:
The MongoDB Monitoring Service (MMS) is a cloud-based monitoring service, designed by MongoDB, to monitor the health of MongoDB deployments. MMS provides an agent that runs on MongoDB servers, and this agent reports information such as opcounters, memory information, number of connections, network I/O, database storage size, and more. All of this information is available in customizable charts that are displayed in your web browser.

To install the monitoring agent register here and follow the wizard instructions.

To upgrade:

  • Open MMS dashboard
  • Choose "Administration" -> "Agents"
  • Click one of the links in the "Monitoring" section
  • A window with header "Install or Update the Monitoring Agent.." will open
  • In the header section, choose "UPDATE"
  • Continue with the instructions in the page (example below..)


Example (for RHEL/CentOS (5.X, 6.X), SUSE, and Amazon Linux - RPM):


1. Download the 32-bit or 64-bit rpm.

curl -OL https://mms.mongodb.com/download/agent/monitoring/mongodb-mms-monitoring-agent-2.8.0.143-1.x86_64.rpm

2. Install the package

sudo rpm -U mongodb-mms-monitoring-agent-2.8.0.143-1.x86_64.rpm

If you find this useful, you are welcome to press one of the ads in this page.. Thanks!


Friday, December 5, 2014

ORMs Suck?

As systems become more complex, software developers must rely upon more abstractions. Each abstraction tries to hide complexity, letting a developer write software that "handles" the many variations of modern computing.
However, the "leaky abstraction" law claims that developers of reliable software must learn the abstraction's underlying details anyway.

Example:
The SQL language abstracts away the procedural steps for querying a database, allowing one to merely define what one wants. But certain SQL queries are thousands of times slower than other logically equivalent queries. On an even higher level of abstraction, ORM systems, which isolate object-oriented code from the implementation of object persistence using a relational database, still force the programmer to think in terms of databases, tables, and native SQL queries as soon as performance of ORM-generated queries becomes a concern.

If you find this useful, you are welcome to press one of the ads in this page.. Thanks!

Tuesday, December 2, 2014

Will NoSQL kill the DBA position?

I’m afraid it’s unlikely. You see, every new or old technology has its advantages and drawbacks. The reality is that NoSQL stands for “Not Just SQL” rather than “No SQL” so the relational database isn't going away anytime soon. Organizations still need transaction atomicity for their mission critical business transactions. When a customer makes a credit card payment or a trader executes a trade, those business transactions need to be committed in real-time to disk. The state of the transaction and its data needs to be consistent wherever that data is updated and accessed from. The reason why NoSQL solutions are so fast, elastic, scalable, and available is because they are basically in-memory distributed data stores that run across multiple nodes and physical servers–meaning that if one node fails, there are plenty others to take over. Therefore when a transaction writes to one node, it’s incredibly fast–but that data has to then be replicated across all nodes in the NoSQL grid for the data to be truly consistent.

Read/Write consistency is still something that NoSQL based solutions have yet to conquer; they sacrifice ACID for read/write performance, elasticity, and high availability.  So while NoSQL enables applications to scale with high transaction concurrency and data volumes, they need to work in parallel with relational databases to ensure data consistency.

If you find this useful, you are welcome to press one of the ads in this page.. Thanks!

Monday, October 20, 2014

Network problems between MongoDB nodes

PROBLEM:
MongoDB replica sets provide high availability through replication and automated failover. We have a cluster comprising three nodes: replicas "mentos-a" and "mentos-b", plus an arbiter. The problem is that every X seconds, the PRIMARY steps down and the cluster failover to the other node.

SOLUTION:
The way we detect a downed node is by a loss of heartbeats and heartbeat responses. Heartbeat responses time out after 10 seconds and then if we have not received a heartbeat from them in the past two seconds (they are sent every two seconds), we mark them as down. So it is common for the election process to take 10 seconds before it starts.

We can change the number of seconds that the replica set members wait for a successful heartbeat from each other. If a member does not respond in time, other members mark the delinquent member as inaccessible.
In the following example we will change the default 2 seconds heartbeat to 30 seconds

rs0:PRIMARY> cfg = rs.conf();
{
 "_id" : "rs0",
 "version" : 2,
 "members" : [
  {
   "_id" : 0,
   "host" : "mentos-a:27017"
  },
  {
   "_id" : 1,
   "host" : "mentos-b:27017"
  },
  {
   "_id" : 2,
   "host" : "mentos-c:27017",
   "arbiterOnly" : true
  }
 ]
}
rs0:PRIMARY> cfg["settings"] = { heartbeatTimeoutSecs : 30 }
{ "heartbeatTimeoutSecs" : 30 }
rs0:PRIMARY> rs.reconfig(cfg);
{ "down" : [ "mentos-a:27017" ], "ok" : 1 }
rs0:PRIMARY> rs.conf()
{
 "_id" : "rs0",
 "version" : 3,
 "members" : [
  {
   "_id" : 0,
   "host" : "mentos-a:27017"
  },
  {
   "_id" : 1,
   "host" : "mentos-b:27017"
  },
  {
   "_id" : 2,
   "host" : "mentos-c:27017",
   "arbiterOnly" : true
  }
 ],
 "settings" : {
  "heartbeatTimeoutSecs" : 30
 }
}

If you find this useful, you are welcome to press one of the ads in this page.. Thanks!

Sunday, February 9, 2014

Find TOP 20 problems in your SQL Server

PROBLEM:
You need to investigate problems with your SQL Server database and to gather some useful information about performance

SOLUTION:
First, do not lock anything, and do not get held up by any locks
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

Show the version of SQL Server
SELECT @@VERSION 

Get property info about server instance. IsIntegratedSecurityOnly: 1 = windows only. ProductLevel - contains RTM or SP level. Is SP the correct one?!
SELECT 
    SERVERPROPERTY('ServerName') AS [ServerName]
    ,SERVERPROPERTY('InstanceName') AS [InstanceName]
    ,SERVERPROPERTY('MachineName') AS [MachineName]
    ,SERVERPROPERTY('Edition') AS [Edition]
    ,SERVERPROPERTY('ProductVersion') AS [ProductVersion]
    ,SERVERPROPERTY('ProductLevel') AS [ProductLevel]
    ,SERVERPROPERTY('IsIntegratedSecurityOnly') AS [IsIntegratedSecurityOnly]
    ,SERVERPROPERTY('IsClustered') AS [IsClustered]

Get OS information. CPU/Memory/last reboot time useful
SELECT cpu_count AS [Logical CPUs]
, cpu_count / hyperthread_ratio AS [Physical CPUs]
, CAST(physical_memory_in_bytes / 1024.0 / 1024.0 /1024.0 AS DECIMAL(28,2)) AS [Memory (GB)]
, DATEADD(ss, -(ms_ticks / 1000), GetDate()) AS [Start DateTime]
--  , sqlserver_start_time AS [Start DateTime]  -- In 2008+
FROM sys.dm_os_sys_info

Show SQL Server database info. Check compatibility level. is_read_committed_snapshot_on (1 is good for concurrency). recovery_model (want simple on non-prod boxes. Bulk_logged for prod). page_verify - want CHECKSUM
SELECT name, compatibility_level, recovery_model_desc, page_verify_option_desc, is_read_committed_snapshot_on
FROM sys.databases ORDER BY name

Show SQL Server configuration info. Priority boost - should be off (0). Cost threshold for parallelism (evaluate with MAXDOP). Max degree of parallelism (1 or 8?). Max server memory (MB) - evaluate in context of server memory. CLR enabled - generally disable, unless needed. Optimize for ad hoc workloads - often recommended to have on
SELECT name, description, value_in_use 
FROM sys.configurations 
WHERE NAME IN(
  'clr enabled'
, 'max degree of parallelism'   
, 'cost threshold for parallelism'  
, 'max server memory (MB)'          -- Set appropriately
, 'optimize for ad hoc workloads'   -- should be 1.
, 'priority boost'                  -- should be 0
)
ORDER BY name

Identify what is causing waits
WITH Waits AS
(SELECT wait_type, wait_time_ms / 1000. AS wait_time_s,
100. * wait_time_ms / SUM(wait_time_ms) OVER() AS pct,
ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS rn
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN ('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK'
,'SLEEP_SYSTEMTASK','SQLTRACE_BUFFER_FLUSH','WAITFOR', 'LOGMGR_QUEUE','CHECKPOINT_QUEUE'
,'REQUEST_FOR_DEADLOCK_SEARCH','XE_TIMER_EVENT','BROKER_TO_FLUSH','BROKER_TASK_STOP','CLR_MANUAL_EVENT'
,'CLR_AUTO_EVENT','DISPATCHER_QUEUE_SEMAPHORE', 'FT_IFTS_SCHEDULER_IDLE_WAIT'
,'XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN', 'SQLTRACE_INCREMENTAL_FLUSH_SLEEP','ONDEMAND_TASK_QUEUE'))

SELECT W1.wait_type, 
CAST(W1.wait_time_s AS DECIMAL(12, 2)) AS wait_time_s,
CAST(W1.pct AS DECIMAL(12, 2)) AS pct,
CAST(SUM(W2.pct) AS DECIMAL(12, 2)) AS running_pct
FROM Waits AS W1
INNER JOIN Waits AS W2
ON W2.rn <= W1.rn
GROUP BY W1.rn, W1.wait_type, W1.wait_time_s, W1.pct
HAVING SUM(W2.pct) - W1.pct < 99; -- percentage threshold

How much time is spent swapping threads - above 20% is bad
SELECT CAST(100.0 * SUM(signal_wait_time_ms) / SUM (wait_time_ms) AS NUMERIC(20,2)) AS [%signal (cpu) waits],
CAST(100.0 * SUM(wait_time_ms - signal_wait_time_ms) / SUM (wait_time_ms) AS NUMERIC(20,2)) AS [%resource waits]
FROM sys.dm_os_wait_stats WITH (NOLOCK) OPTION (RECOMPILE);

CPU utilization usage per object database. Is a single DB hogging CPU? Maybe needs a separate server
--USE [YourDatabaseName]
WITH DB_CPU_Stats
AS
(SELECT DatabaseID, DB_Name(DatabaseID) AS [DatabaseName], 
 SUM(total_worker_time) AS [CPU_Time_Ms]
 FROM sys.dm_exec_query_stats AS qs
 CROSS APPLY (SELECT CONVERT(int, value) AS [DatabaseID] 
              FROM sys.dm_exec_plan_attributes(qs.plan_handle)
              WHERE attribute = N'dbid') AS F_DB
 GROUP BY DatabaseID)
SELECT ROW_NUMBER() OVER(ORDER BY [CPU_Time_Ms] DESC) AS [row_num],
       DatabaseName, [CPU_Time_Ms], 
       CAST([CPU_Time_Ms] * 1.0 / SUM([CPU_Time_Ms]) 
       OVER() * 100.0 AS DECIMAL(5, 2)) AS [CPUPercent]
FROM DB_CPU_Stats
WHERE DatabaseID > 4 -- system databases
AND DatabaseID <> 32767 -- ResourceDB
ORDER BY [CPUPercent] DESC OPTION (RECOMPILE);

Memory usage per database. Is a single DB hogging memory? Maybe needs a separate server
--USE [YourDatabaseName]
SELECT 
    ISNULL(DB_NAME(database_id), 'ResourceDb') AS DatabaseName
    , CAST(COUNT(row_count) * 8.0 / (1024.0) AS DECIMAL(28,2))  AS [Size (MB)] 
    , CAST(COUNT(row_count) * 8.0 / (1024.0) / 1024.0 AS DECIMAL(28,2)) AS [Size (GB)] 
FROM sys.dm_os_buffer_descriptors
GROUP BY database_id
ORDER BY [Size (MB)] DESC

Find what are the physical disk metric values. Under 20ms is ok, above this need investigating
--USE [YourDatabaseName]
SELECT DB_NAME(database_id) AS DatabaseName
 , file_id
 , io_stall_read_ms / num_of_reads AS 'Average read time'
 , io_stall_write_ms / num_of_writes AS 'Average write time'
FROM sys.dm_io_virtual_file_stats(NULL, NULL)
WHERE num_of_reads > 0 
AND num_of_writes > 0
ORDER BY DatabaseName

Check reads per write, by database. Separate out a DB or for OLAP/OLTP? OLAP often needs more indexes.. NULL DatabaseName means this query was run adhoc or prepared
--USE [YourDatabaseName]
SELECT TOP 10 
        DB_NAME(qt.dbid) AS DatabaseName
        , SUM(total_logical_reads) AS [Total Reads]
        , SUM(total_logical_writes) AS [Total Writes]
        , SUM(total_logical_reads) / CASE WHEN SUM(total_logical_writes) = 0 THEN 1 ELSE SUM(total_logical_writes) END AS [Reads Per Write]
        , SUM(qs.execution_count) AS [Execution count]
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt
GROUP BY DB_NAME(qt.dbid)
ORDER BY [Reads Per Write] DESC;

Check space used. What is DB size, and how much is unused?
--USE [YourDatabaseName]
EXEC sp_SpaceUsed
-- Database statistics settings
-- is_auto_create_stats_on should be on (1)
-- is_auto_update_stats_on should be on (1)
-- is_auto_update_stats_async_on should be off (0)
SELECT name
, is_auto_create_stats_on AS [AutoCreateStatistics]
, is_auto_update_stats_on AS [AutoUpdateStatistics]
, is_auto_update_stats_async_on AS [AutoUpdateStatisticsAsync]
FROM master.sys.databases
ORDER BY name

Check the state of your statistics. When last updated?! Maybe needs intelligent stats utility?
--USE [YourDatabaseName]
SELECT 
 ss.name AS SchemaName
 , st.name AS TableName
 , s.name AS IndexName 
 , STATS_DATE(s.id,s.indid) AS 'Statistics Last Updated'
 , s.rowcnt AS 'Row Count'    
 , s.rowmodctr AS 'Number Of Changes' 
 , CAST((CAST(s.rowmodctr AS DECIMAL(28,8))/CAST(s.rowcnt AS DECIMAL(28,2)) * 100.0)
     AS DECIMAL(28,2)) AS '% Rows Changed'
FROM sys.sysindexes s 
INNER JOIN sys.tables st ON st.[object_id] = s.[id]
INNER JOIN sys.schemas ss ON ss.[schema_id] = st.[schema_id]
WHERE s.id > 100 -- user table/index
AND s.indid > 0  -- Clustered and non-clustered indexes
AND s.rowcnt >= 500 -- want at least 500 rows
ORDER BY 'Statistics Last Updated' DESC 

Missing indexes can be indicative of other bad practices in a given DB
--USE [YourDatabaseName]
SELECT 
 DB_NAME(database_id) AS DatabaseName
 , COUNT(*) AS [Missing Index Count]
FROM sys.dm_db_missing_index_details
GROUP BY DB_NAME(database_id)
ORDER BY [Missing Index Count] DESC

What are the most costly missing indexes?
--USE [YourDatabaseName]
SELECT TOP 40 -- Too many INCLUDE cols in top entries...  
 ROUND(avg_total_user_cost * avg_user_impact   
  * (user_seeks + user_scans),0) AS [Total Cost]  
 , [statement] AS [Table Name]
 , equality_columns
 , inequality_columns
 , included_columns
FROM  sys.dm_db_missing_index_groups g 
INNER JOIN sys.dm_db_missing_index_group_stats s 
ON s.group_handle = g.index_group_handle 
INNER JOIN sys.dm_db_missing_index_details d 
ON d.index_handle = g.index_handle
ORDER BY [Total Cost] DESC

Identify missing PKs. Most tables should have PK (for RI, FK), unless good reason
--USE [YourDatabaseName]
SELECT DB_NAME(DB_ID()) AS DatabaseName, SCHEMA_NAME(schema_id) AS SchemaName,name AS TableName
FROM sys.tables
WHERE OBJECTPROPERTY(OBJECT_ID,'TableHasPrimaryKey') = 0
ORDER BY SchemaName, TableName;

Identify heaps that have non-clustered indexes. Often Heaps with Non-clustered Indexes better as Cluster based on NC
--USE [YourDatabaseName]
SELECT 
 DB_NAME(DB_ID()) AS DatabaseName
 , ss.name AS SchemaName
 , st.NAME AS TableName
 , i.NAME AS IndexName
 , i.type_desc
 , si.rowcnt
INTO #HeapWithIndexes2
FROM sys.indexes I 
LEFT JOIN sys.sysindexes SI ON SI.indid = I.index_Id AND i.object_id = si.id
INNER JOIN sys.tables st ON st.[object_id] = si.[id]
INNER JOIN sys.schemas ss ON ss.[schema_id] = st.[schema_id]
WHERE 1=2

Check tables names that have a heap...
--USE [YourDatabaseName]
SELECT DISTINCT ss.name AS schemaName, st.name
INTO #Heaps
FROM sys.indexes I 
LEFT JOIN sys.sysindexes SI ON SI.indid = I.index_Id 
       AND i.object_id = si.id
INNER JOIN sys.tables st ON st.[object_id] = si.[id]
INNER JOIN sys.schemas ss ON ss.[schema_id] = st.[schema_id]
WHERE si.id > 100 
AND i.type_desc = 'HEAP'
INTERSECT
SELECT DISTINCT ss.name AS schemaName, st.name
FROM sys.indexes I 
LEFT JOIN sys.sysindexes SI ON SI.indid = I.index_Id 
       AND i.object_id = si.id
INNER JOIN sys.tables st ON st.[object_id] = si.[id]
INNER JOIN sys.schemas ss ON ss.[schema_id] = st.[schema_id]
WHERE si.id > 100 
AND i.type_desc != 'HEAP'

ALL tables and their indexes...
--USE [YourDatabaseName]
INSERT INTO #HeapWithIndexes2 
SELECT
 DB_NAME(DB_ID()) AS DatabaseName
 , ss.name AS SchemaName
 , st.NAME AS TableName
 , i.NAME AS IndexName
 , i.type_desc
 , si.rowcnt
FROM sys.indexes I 
LEFT JOIN sys.sysindexes SI ON SI.indid = I.index_Id AND i.object_id = si.id
INNER JOIN sys.tables st ON st.[object_id] = si.[id]
INNER JOIN sys.schemas ss ON ss.[schema_id] = st.[schema_id]
INNER JOIN #Heaps h ON st.name = h.name AND ss.name = h.schemaName
WHERE si.id > 100 
 
SELECT * FROM #HeapWithIndexes2 ORDER BY DatabaseName, SchemaName, TableName, IndexName
 
DROP TABLE #Heaps
DROP TABLE #HeapWithIndexes2

Allows targeted improvements, based on query duration. Query plan may offer hints for improvements
SELECT TOP 20 
 CAST(total_elapsed_time / 1000000.0 AS DECIMAL(28, 2)) AS [Total Duration (s)]
 , CAST(total_worker_time * 100.0 / total_elapsed_time AS DECIMAL(28, 2)) AS [% CPU]
 , CAST((total_elapsed_time - total_worker_time)* 100.0 / total_elapsed_time AS DECIMAL(28, 2)) AS [% Waiting] 
 , execution_count
 , CAST(total_elapsed_time / 1000000.0 / execution_count AS DECIMAL(28, 2)) AS [Average Duration (s)]
 , SUBSTRING (qt.text,(qs.statement_start_offset/2) + 1, 
    ((CASE WHEN qs.statement_end_offset = -1 
    THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2 
    ELSE qs.statement_end_offset
    END - qs.statement_start_offset)/2) + 1) AS [Individual Query] 
 , SUBSTRING(qt.text,1,100) AS [Parent Query]
 , DB_NAME(qt.dbid) AS DatabaseName 
 , qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
INNER JOIN sys.dm_exec_cached_plans as cp 
      ON qs.plan_handle=cp.plan_handle
WHERE total_elapsed_time > 0
ORDER BY total_elapsed_time DESC

If you find this useful, you are welcome to press one of the ads in this page.. Thanks!

Show execution plan for all sessions in SQL Server

PROBLEM:
How to show execution plan for all sessions?

SOLUTION:
Run this before starting
DBCC FREEPROCCACHE

Show execution plan for all sessions
SELECT TOP 1000 qs.execution_count, 
      StoredProcedure = Db_name(qp.dbid) + '..' + Object_name(qp.objectid, qp.dbid), 
      StatementDefinition = Substring (st.text,
       ( qs.statement_start_offset / 2 ) + 1, 
         ( 
           ( CASE qs.statement_end_offset 
             WHEN -1 THEN Datalength(st.text) 
             ELSE qs.statement_end_offset 
             END - qs.statement_start_offset
           ) / 2
         ) + 1
      ), 
      query_plan, 
      st.text, 
      total_elapsed_time 
FROM
   sys.dm_exec_query_stats AS qs 
   CROSS apply sys.Dm_exec_sql_text(qs.sql_handle) AS st 
   CROSS apply sys.Dm_exec_query_plan (qs.plan_handle) qp 
WHERE
   st.encrypted = 0 
ORDER BY
   total_elapsed_time / QS.execution_count DESC, 
   qs.execution_count, 
   3 

If you find this useful, you are welcome to press one of the ads in this page.. Thanks!

Sunday, January 5, 2014

In Memory MongoDB

PROBLEM:
You want to use MongoDB as an in-memory RAM-only store

SOLUTION:
You can use MongoDB and all its features as an in-memory RAM-only store! Its performance should be pretty impressive: achieving 20k writes per second, and it should scale linearly over the number of cores.
See the following great link: How to use MongoDB as a pure in-memory DB

If you find this useful, you are welcome to press one of the ads in this page.. Thanks!

Tuesday, August 13, 2013

Use MongoDB in Windows Azure

PROBLEM:
You want to use MongoDB in Windows Azure

SOLUTION:
See the following links:

  1. MongoDB Installer for Windows on Azure
  2. Securing MongoDB on Windows Azure

If you find this useful, you are welcome to press one of the ads in this page.. Thanks!


Tuesday, August 6, 2013

Performance best practices for very large tables

PROBLEM:
What are the performance best practices for very large tables?

SOLUTION:
Here is a summary of best practices for querying, monitoring, and performance tuning for your very large tables:
  • Pay attention to both the results of a query and the execution plan designed to return those results. Make it a routine exercise to scan query plans to become more familiar with how SQL Server resolves queries.
  • De-normalize your schema where possible to reduce the need to join very large tables.
  • Use table partitioning for your largest tables, and be sure when querying that the optimizer uses partition elimination whenever possible.
  • Align secondary indexes with the same table partition function to reduce partitioned table maintenance.
  • Consider using a heap instead of a clustered index, especially with a table that partially mimics a clustered index via its partition function.
  • Design indexes to be covering for larger recurring queries whenever possible, especially when creating a filtered (i.e., partial) index.
  • Use an indexed view as an alternative to a denormalized table or to materialize an aggregated dataset. The more static the underlying data, the less overhead will be required to maintain the indexed views.
  • Use summary tables with automatic (scheduled) updates as an alternative to indexed views, especially when there is less significance in the currency of the data.
  • For query monitoring, focus on the quantitative measures of Disk I/O, CPU Time, and Query Duration.
  • Use the features of the Management Data Warehouse for overall server monitoring, and use the SQL Trace data collection set for query monitoring.
  • Focus your tuning efforts on SQL code that is repeatedly run, either as a stored procedure or a SQL script, and that consumes the most server resources. Data warehouse applications tend to place the greatest pressure on Disk I/O.
  • For tuning and management of large queries, consider saving historical copies of XML execution plans to disk for later reference.


If you find this useful, you are welcome to press one of the ads in this page.. Thanks!

Tuesday, June 11, 2013

MongoDB Hardware Tips

PROBLEM:
You need some hardware tips for your MongoDB installation:
  • Buy $1k 1000 servers or $10k 100 servers?
  • Fast CPU vs. more CPU cores?
  • More RAM is good?
  • Virtualization is ok?
  • SSD is good?
  • Disable NUMA (Non-Uniform Access Memory) in BIOS?
  • File system settings?
SOLUTION:
See this: https://www.youtube.com/watch?v=19VZJ9H3LmQ

If you find this useful, you are welcome to press one of the ads in this page.. Thanks!

Sunday, June 9, 2013

Step by step guide for MongoDB sharding

PROBLEM:
What is a MongoDB sharded cluster?

SOLUTION:
While sharding is a powerful and compelling feature, it comes with significant infrastructure requirements and some limited complexity costs. As a result, use sharding only as necessary and when indicated by actual operational requirements.

Here is a step by step guide for MongoDB sharding:

Introduction to Sharding

Sharding Setup Demo

The config database

Setup Part 2 Adding the Initial Shards

Enabling sharding for a collection

Working with a sharded collection

Choosing shard keys

Process and Machine Layout

Bulk inserts and pre-splitting

Further tips and best practices

If you find this useful, you are welcome to press one of the ads in this page.. Thanks!


Tuesday, May 28, 2013

MongoDB performance tuning, indexes, explain plan, hints and profiler

PROBLEM:
What you need to know for MongoDB performance tuning?

SOLUTION:
The following links will cover performance tuning, obviously a key aspect of database administration. You can find there how to optimize the performance of operations against a MongoDB database, including both queries and write operations. Indexes of course play a key component in many cases; thus you can find also a talk about MongoDB indexes in detail. You can find there also other performance related features including the explain plan and hint commands and the profiler.

Indexes in MongoDB
https://www.youtube.com/watch?v=a7TrHP1C6qQ

Indexes types
https://www.youtube.com/watch?v=pyoOGhGDoj8

Covered Indexes
https://www.youtube.com/watch?v=boAkBnMUBnw

Hints
https://www.youtube.com/watch?v=oaTm0Kftit8

Read vs. Writes
https://www.youtube.com/watch?v=USDbDotmums

Current Operations and Kill Operations
https://www.youtube.com/watch?v=i7XEKAtRS_M

Profiler
https://www.youtube.com/watch?v=MzLmI8FNB94

Mongostat & Mongotop
https://www.youtube.com/watch?v=fEgl1DT_lDA


If you find this solution useful, you are welcome to press one of the ads in this page.. Thanks!

Wednesday, April 10, 2013

Optimizing MongoDB

PROBLEM:
How to optimize your MongoDB?

SOLUTION:
Here are some tips and tricks for optimizing your MongoDB deployment:

Design an efficient schema
1. When you’re designing your schema for MongoDB, think about the ways that you are going to access your data and the common access patterns. You want to take advantage of MongoDB’s flexible schema and design rich documents
2. A key question when designing a MongoDB schema is when to embed and when to link. Embedding is the nesting of objects and arrays inside a BSON document. Links are references between documents. Embedding is a bit like "prejoined" data. Operations within a document are easy for the server to handle. Links in contrast must be processed client-side by the application; the application does this by issuing a follow-up query.
Generally, for "contains" relationships between entities, embedding should be be chosen. Embedding documents when it should actually be linked would result in duplication of data.

Optimize your queries
Have slow database queries? Get more information on the performance of your queries using the explain feature. Using the mongo shell, invoke the explain() method on a cursor:

> db.collection.find(query).explain()

The result will be a document that contains the explain output:

{
   "cursor" : "BasicCursor",
   "indexBounds" : [ ],
   "nscanned" : 57594,
   "nscannedObjects" : 57594,
   "nYields" : 2 ,
   "n" : 3 ,
   "millis" : 108, 
   "indexOnly" : false,
   "isMultiKey" : false,
   "nChunkSkips" : 0 
}

Know your working set size
Retrieving data in RAM is orders of magnitude faster than disk. Think about the total database size in relation to the set of data that is active at any given point in time. If you want your queries to be fast, make sure that you have enough memory to hold your active working set in RAM.
Don’t forget your indexes. They take up memory too!

More Information

If you find this solution useful, you are welcome to press one of the ads in this page.. Thanks!

Thursday, March 21, 2013

MongoDB Deployment Strategies

PROBLEM:
Ready to deploy MongoDB? Here's what you need to know

SOLUTION:

Use Replication
Replication is the best way to ensure the safety of your data. It is recommended that you use replica sets, a form of asynchronous master/slave replication that adds automatic failover and automatic recovery of member nodes.
More information on replication:
Replica Sets
Best practices for replica sets on EC2

Sharding is there when you need it
If your data exceeds the resources of a single database server, MongoDB can convert to a sharded cluster for horizontal scaling across multiple nodes. With MongoDB sharding, the failover and balancing of nodes is handled automatically, with few or no changes to the original application code.

Deploying in the cloud
MongoDB was designed to run on commodity and virtualized environments. Because it does not depend on high end compute, network or storage resources, your deployment is not limited by the biggest server resources you can get in cloud environments like Amazon EC2 or Rackspace Cloud. You can add additional storage, memory and transaction capacity by adding more virtual servers to your deployment.
Docs: Amazon EC2
Docs: VMware Cloud Foundry
Docs: Red Hat OpenShift
Docs: Windows Azure
Docs: Hosting Center

Monitoring your deployment
MongoDB includes many diagnostic commands and tools, like mongostat, the query profiler, and more. In addition the open source community has built plugins from monitoring tools like Ganglia, munin, and cacti.
In addition, 10gen offers a cloud-based monitoring and alerting solution for MongoDB deployments called MongoDB Monitoring Service (MMS). MMS is a publicly available software-as-a-service solution available at mms.10gen.com.


If you find this solution useful, you are welcome to press one of the ads in this page.. Thanks!





Wednesday, March 13, 2013

Managing UNDO data in Oracle

PROBLEM:
What are the basics of Oracle undo data?

SOLUTION:

1. A.C.I.D Standard
  • Atomicity
  • Consistency
  • Isolation
  • Durability
2. DML & DDL - Behind the scenes
  • Executing a Rollback
  • Executing a Commit
  • DDL and Transaction Control
  • The So-Called “Auto-Commit”
  • Executing SQL statements
  • Executing an Update Statement
  • Executing Insert and Delete Statements
3. Consistency TYPES
4. Managing UNDO Data
  • Undo Parameters
  • Undo Retention Guarantee (10g) 
  • Sizing your undo tablespace
5. Flashback query
6. Oracle Isolation Levels

--------------------------------------------------------------------------
-- ACID (aka ACID test)
--------------------------------------------------------------------------

-- In computer science, ACID (atomicity, consistency, isolation, durability) is a set of properties that guarantee database transactions are processed reliably.

-- Atomicity
-- The principle of atomicity states that all parts of a transaction must complete, or none of them.
-- For example, if your business analysts have said that every time you change an employee’s salary you must also change his grade, then the “atomic” transaction will consist of two updates. The database must guarantee that both go through, or neither.

-- Consistency
-- The principle of consistency states that the results of a query must be consistent with the state of the database at the time the query started.
-- For uncommited data - as long as user-A changing data in Table-X without applying Commit, all other users will see the "old values".
-- For commited data -  Imagine a simple query that averages the value of a column of a table. If the table is large, it will take many minutes to pass through the table.
-- If other users are updating the column and commit while the query is in progress, should the query include the new or the old values? Should it include rows that were inserted or deleted after the query started?

-- Isolation
-- The principle of isolation states that an incomplete (that is, uncommitted) transaction must be invisible to the rest of the world.

-- Durability
-- The principle of durability states that once a transaction completes with a COMMIT, it must be impossible for the database to lose it.

--------------------------------------------------------------------------
-- DML & DDL - Behind the scenes
--------------------------------------------------------------------------

-- Executing a Rollback
-- If the session that initiated the transaction fails (perhaps the PC running the user process reboots, or the network link goes down), then the PMON will detect that there is a problem, and roll back the transaction.
-- If the server crashes, then on startup SMON will detect the problem and initiate a rollback. A manual rollback requires the user to issue the ROLLBACK command. But however the rollback is initiated, the mechanism is identical.
-- Oracle’s implementation of the ROLLBACK command is to use undo data to construct and execute another statement that will reverse the effect of the first statement.

-------------------------
-- Executing a Commit
-------------------------

-- When you say COMMIT, all that happens physically is that LGWR flushes the log buffer to disk. DBWn does absolutely nothing. This is one of the most important performance features of the Oracle database.

--------------------------------
-- DDL and Transaction Control
--------------------------------

-- The COMMIT and ROLLBACK statements apply only to DML. You cannot roll back a DDL statement: once executed, it is immediately durable

--------------------------------
-- The So-Called “Auto-Commit”
--------------------------------
-- Quite simply, there is no such thing as an automatic commit.
-- When you execute a DDL statement for instance, a perfectly normal COMMIT is included in the source code that implements the DDL command.
-- When you exit from your user process - If you are using SQL*Plus on a Windows terminal (never  mind what operating system the database server is running) and you issue a DML statement followed by an “exit,” your transaction will be committed.
-- This is because a COMMIT statement is built into the SQL*Plus “exit” command. When you click in the top-right corner of the SQL*Plus window? The window will close, and if you log in again, you will see that the transaction has been rolled back.
-- This is because the programmers who wrote SQL*Plus for Microsoft Windows included a ROLLBACK statement in the code that is executed when you close the window.

-----------------------------
-- Executing SQL statements
-----------------------------

-- Executing a SELECT Statement
-- 1. The server process executing the statement will first check whether the blocks containing the data required are already in memory, in the database buffer cache.
-- 2. If they are, then execution can proceed immediately. If they are not, the server must locate them on disk and copy them into the database buffer cache.
-- 3. Once the data blocks required for the query are in the database buffer cache, any further processing (such as sorting or aggregation) is carried out in the PGA of the session.
-- 4. When the execution is complete, the result set is returned to the user process.

----------------------------------
-- Executing an Update Statement
----------------------------------

-- 1. The first step in executing DML is the same as executing SELECT: the required blocks must be found in memory or copied into memory from disk. The only change is that an empty block of an undo segment is needed too
-- 2. Locks must be placed on any rows that will be affected by the operation
-- 3. Then the redo is generated: the server process writes to the log buffer the changes that are going to be applied to the data blocks.
-- 4. Having generated the redo, the update is carried out in the database buffer cache:
--    A. The block of table data is updated with the new version of the changed column,
--    B. The old version of the changed column is written to the block of an undo segment.
-- 5. From this point until the update is committed, all queries from other sessions addressing the changed row will be redirected to the undo data. Only the session that is doing the update will see the actual current version of the row in the table block.

-------------------------------------------
-- Executing Insert and Delete Statements
-------------------------------------------

-- Conceptually, INSERT and DELETE are managed in the same fashion as an UPDATE.
-- Redo generation is exactly the same: all changes to be made to data are first written out to the log buffer.
-- The difference is in the amount of undo generated.
-- INSERT - When a row is inserted, the only undo generated consists of writing out the new rowid to the undo block. This is because to roll back an INSERT, the only information Oracle requires is the rowid,
-- DELETE - the whole row is written to the undo block, so that the deletion can be rolled back if need be by inserting the complete row back into the table.

--------------------------------------------------------------------------
-- Managing UNDO Data
--------------------------------------------------------------------------

-- Undo Parameters
SHOW PARAMETER undo

-- UNDO_MANAGEMENT
-- Manual - meaning that Oracle will not use undo segments at all. This is for backward compatibility, and if you use this, you will have to do a vast amount of work creating and tuning rollback segments. Don’t do it.
-- Auto - to enable automatic undo management through the use of undo segments. In this case, DBAs relinquish undo segment management to Oracle. This parameter is static.The other parameters are dynamic.

-- UNDO RETENTION
-- UNDO_RETENTION parameter specifies the amount of time in seconds that Oracle *attempts* to keep undo data available.
-- If, for example, your longest running query is thirty minutes, you would set this parameter to 1800. Oracle will then attempt to keep all undo data for at least 1800 seconds, and your query should therefore never fail with ORA-1555.
-- If, however, you do not set this parameter, or if you set it to zero, Oracle will still keep data for as long as it can anyway.
-- The algorithm controlling which expired undo data is overwritten first will always choose to overwrite the oldest bit of data; Therefore, UNDO_RETENTION is always at the maximum allowed by the size of the tablespace

-- UNDO_TABLESPACE
UNDO_TABLESPACE This parameter nominates a tablespace, which must have been created as an undo tablespace, as the active undo tablespace.

-- See Undo tablespaces:
SELECT tablespace_name, contents, retention
FROM dba_tablespaces;

-- Change retention
ALTER SYSTEM SET undo_retention = 800 ;

-- Undo Retention Guarantee (10g)
-- With the 10g release, there is an option to guarantee undo retention. This means that undo data will never be overwritten until the time specified by the UNDO_RETENTION parameters has passed.
-- Retention guarantee is enabled at the tablespace level via the Retention Guarantee clause. This attribute can be specified at undo tablespace creation time, or an undo tablespace can be altered later to enable it.
-- Once you activate an undo tablespace for which a retention guarantee has been specified, all queries will complete successfully, provided they finish within the undo retention time. You -- -- will never have “snapshot too old” errors again. The downside is that transactions may fail for lack of undo space because Oracle cannot overwrite committed undo data until the retention time has passed.

SELECT tablespace_name, contents, retention
FROM dba_tablespaces;

ALTER TABLESPACE UNDOTBS1 RETENTION GUARANTEE;

SELECT tablespace_name, contents, retention
FROM dba_tablespaces;

-- Via OEM:
-- Server => (Database Configuration) => Automatic Undo Management
-- Server => (Database Configuration) => Initialization Parameters

-------------------------------------
-- Sizing your undo tablespace
-------------------------------------

SELECT (UR * (UPS * DBS)) + (DBS * 24) AS "Bytes"
FROM (SELECT value AS UR FROM v$parameter WHERE name = 'undo_retention'),
(SELECT (SUM(undoblks)/SUM(((end_time - begin_time)*86400))) AS UPS FROM v$undostat),
(select block_size as DBS from dba_tablespaces where tablespace_name=
(select value from v$parameter where name = 'undo_tablespace'));

-- or via OEM ...

-------------------------------------
-- Undo segment management
-------------------------------------

-- active segments in the Undo tablespace

set lines 200
col program for a15
col username for a10
col osuser for a15
col sid for 999
col sr# for 999
col segment_name for a25
col tablespace_name for a15
col status for a15

SELECT segment_id, segment_name, B.status, xacts, tablespace_name
FROM DBA_ROLLBACK_SEGS, V$ROLLSTAT B
WHERE segment_id=usn;

-- for every new transaction a new undo segment will be available

update hr.employees set salary = salary + 1 ;

update hr.departments set department_name = department_name || 'xxx';

update hr.regions set region_name = region_name || 'zzz' ;

rollback

--------------------------------------------------------------------
-- Useful queries for UNDO usage
--------------------------------------------------------------------

-- Identify transaction and session:

-- In one session:
Conn hr/hr
UPDATE employees SET salary=salary;

-- In another session:
conn / as sysdba

-- See all active Undo segments:

SET LINES 120 PAGES 120
col program for a15
col username for a10
col osuser for a15
col sid for 999
col sr# for 999
col segment_name for a25
col tablespace_name for a15
col status for a15

SELECT segment_id, segment_name, tablespace_name, B.status, xacts "Active Transactions"
FROM DBA_ROLLBACK_SEGS, V$ROLLSTAT B
WHERE segment_id=usn and xacts > 0;

-- Which sessions use a specific undo segment:
SELECT username, program, osuser, sid, serial#
FROM v$session S, v$transaction T
WHERE S.taddr = T.addr ;

-- Which sessions use active undo segments:
-- If needed can kill the problematic session:
ALTER SYSTEM KILL SESSION 'sid, sr#';

--------------------------------------------------------------------------
-- DEMO - Flashback query
--------------------------------------------------------------------------

SELECT last_name, salary
FROM hr.employees;

-- Update and commit (User forgot to put a where condition, and also commited his changes...)
UPDATE hr.employees
SET salary = 1;

commit;

-- Data is changed and cannot be rolled back...
SELECT last_name, salary
FROM hr.employees;

-- Flashback Query - Select from the table as it was at a specific point in the past:
-- In this example - go back one hour:

SELECT last_name, salary
FROM hr.employees AS OF TIMESTAMP sysdate - 1/24;

-- Fix the table with a correlated Update:
UPDATE hr.employees e
SET salary = (SELECT salary from hr.employees AS OF TIMESTAMP sysdate - 1/24
              WHERE employee_id = e.employee_id);

------------------------------------------------------
-- Oracle Isolation Levels
------------------------------------------------------
-- Read committed - This is the default transaction isolation level. Each query executed by a transaction sees only data that was committed before the query (not the transaction) began. An Oracle query never reads dirty (uncommitted) data.
-- Serializable - Serializable transactions see only those changes that were committed at the time the transaction began, plus those changes made by the transaction itself through INSERT, UPDATE, and DELETE statements.
-- Read-only - Read-only transactions see only those changes that were committed at the time the transaction began and do not allow INSERT, UPDATE, and DELETE statements

-- Serializable Example:

-- User A
----------

-- Default behaviour for each new transaction
 ALTER SESSION SET ISOLATION_LEVEL=SERIALIZABLE; 

-- or
-- Specific behaviour for the next new transaction
 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;   

 conn hr/hr

 SELECT last_name , salary
 FROM employees
 WHERE rownum < 11 ;

-- User B
----------

 conn hr/hr

 SELECT last_name , salary
 FROM employees
 WHERE rownum < 11 ;

 UPDATE employees SET salary = 1 ;

 COMMIT ;

-- USER A
----------

 SELECT last_name , salary
 FROM employees
 WHERE rownum < 11 ;

-- Fix the table
 UPDATE hr.employees e
 SET salary = (SELECT salary from hr.employees AS OF TIMESTAMP sysdate - 10/1440
              WHERE employee_id = e.employee_id);

----------------------------------

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

SET TRANSACTION READ ONLY;

ALTER SESSION SET ISOLATION_LEVEL=SERIALIZABLE;

ALTER SESSION SET ISOLATION_LEVEL=READ COMMITTED;

If you find this solution useful, you are welcome to press one of the ads in this page.. Thanks!

Wednesday, February 27, 2013

Your first MongoDB application

PROBLEM:
What you need to know to build your first MongoDB application?

SOLUTION:
MongoDB Terminology
As you build your first application with MongoDB, you should start by knowing some basic terminology. Here are a few key terms and the equivalent concepts in a relational database:

RDBMSMongoDB
Rows, ViewsDocuments
TablesCollections
IndexIndex
JoinEmbedded Documents
PartitionShard

Data as Documents
One of the major benefits of MongoDB is schema flexibility. In MongoDB, there are no predefined fields, collections can have heterogenous structure across documents, and the fields and their value datatypes can vary. For example, here is how you might model a blog post in MongoDB:

{author: "meghan",
date: new Date(),
text: "MongoDB is great!",
tags: ["mongodb", "intro"]}

As you can see with the tags field in the example above, we have stored an array of strings within our document. And if we want to add another field to our document, we can do so easily. This facility enables you to develop applications iteratively with MongoDB.

Querying
Even though MongoDB is a NoSQL database, you can still access your data with dynamic queries. You'll find that many SQL queries translate easily to MongoDB's document-based query language.
For example, suppose we're using the MongoDB shell and want to return every document in the users collection. Our query would look like this:

db.users.find({})

In this case, our selector is an empty document, which matches every document in the collection. Here's a more selective example:

db.users.find({'last_name': 'Smith'})

Here our selector will match every document where the last_name attribute is 'Smith.'
MongoDB supports a wide array of possible document selectors. For more examples:


For more information
Interested in learning more about building applications with MongoDB? Here are a few resources to get you started:


If you find this solution useful, you are welcome to press one of the ads in this page.. Thanks!

Union vs. Union All

PROBLEM:
What happens when you combine the same retrieval commands UNION (performs distinct query) and UNION ALL ?

SOLUTION:
Lets create test data:
CREATE TABLE #T (N INT);
GO
INSERT INTO #T
SELECT 1;
INSERT INTO #T
SELECT 2;
INSERT INTO #T
SELECT 2;
INSERT INTO #T
SELECT 3;
INSERT INTO #T
SELECT 3;
INSERT INTO #T
SELECT 3;
GO
SELECT *
FROM #T;


Now, lets query it:
SELECT * FROM #T
UNION ALL
SELECT * FROM #T
UNION
SELECT * FROM #T

SELECT * FROM #T
UNION
SELECT * FROM #T
UNION ALL
SELECT * FROM #T;



In the first case, the UNION makes distinct query and contracted three output lines, and in the second case the UNION ALL received three lines added all six.

If you find this solution useful, you are welcome to press one of the ads in this page.. Thanks!

Sunday, December 16, 2012

Managing Oracle database instance - the basics

PROBLEM:
What is the basics of managing Oracle database instance?

SOLUTION:
-- Data Files
SELECT name FROM v$datafile;

-- Control Files
SELECT name FROM v$controlfile;

-- Redo Log Files
SELECT member FROM v$logfile;

--------------------------
-- View a parameter value
--------------------------

show parameter undo

show parameter retention

show parameter mttr

desc v$parameter

SELECT name, value
FROM v$parameter
WHERE name LIKE '%mttr%';

show parameter SEC_MAX_FAILED_LOGIN_ATTEMPTS

---------------- 
-- Change values
----------------

ALTER SYSTEM SET fast_start_mttr_target=300;

SELECT name, value
FROM v$parameter
WHERE name LIKE '%mttr%';

show parameter mttr

ALTER SYSTEM SET SEC_MAX_FAILED_LOGIN_ATTEMPTS = 10 ;

ALTER SYSTEM SET SEC_MAX_FAILED_LOGIN_ATTEMPTS = 10 SCOPE = SPFILE;

SELECT  name, ISSYS_MODIFIABLE
FROM v$parameter
WHERE NAME IN ('fast_start_mttr_target', 'sec_max_failed_login_attempts')

--------------------------------------------------- 
-- Difference between V$parameter and v$spparameter
---------------------------------------------------

-- * V$PARAMETER
--   It displays the information about initialization parameters that
--   are currently in effect for the session.
-- * V$SPPARAMETER
--   It displays the information about contents of the server parameter file.
--   If a server parameter file was not used to start the instance,
--   then ISSPECIFIED column contains FALSE value.

SELECT name, value FROM v$spparameter
WHERE name LIKE '%mttr%';

SELECT name, value FROM v$parameter
WHERE name LIKE '%mttr%';

alter system set fast_start_mttr_target = 100 scope = spfile ;

SELECT name, value FROM v$spparameter
WHERE name LIKE '%mttr%';

SELECT name, value FROM v$parameter
WHERE name LIKE '%mttr%';

-- View only used parameters from the spfile :

select count(*)
from v$spparameter
where ISSPECIFIED <> 'FALSE'

--------------------------- 
-- CREATE PFILE FROM SPFILE
---------------------------

-- Default value : ARC%S_%R.%T

show parameter log_archive_format

ALTER SYSTEM SET log_archive_format = 'RAM%K' ;

ALTER SYSTEM SET log_archive_format = 'RAM%K' SCOPE = SPFILE ;

SHUTDOWN IMMEDIATE

STARTUP

CREATE PFILE FROM SPFILE ;

-- change parameter value in the pfile

CREATE SPFILE FROM PFILE ;

STARTUP

show parameter log_archive_format


If you find this solution useful, you are welcome to press one of the ads in this page.. Thanks!

Wednesday, November 7, 2012

Find and drop duplicate indexes

PROBLEM:
You want to find and drop duplicate indexes

SOLUTION:
Find duplicate indexes with same key columns in the same order, and the same included columns but in any order
WITH IX AS
  ( SELECT OBJECT_ID AS ID,
           INDEX_ID AS INDID,
           NAME,

     (SELECT CASE KEYNO WHEN 0 THEN NULL ELSE COLID END AS [data()]
      FROM SYS.SYSINDEXKEYS AS K
      WHERE K.ID = I.OBJECT_ID
        AND K.INDID = I.INDEX_ID
      ORDER BY KEYNO,
               COLID
      FOR XML PATH('')) AS COLS,

     (SELECT CASE KEYNO WHEN 0 THEN COLID ELSE NULL END AS [data()]
      FROM SYS.SYSINDEXKEYS AS K
      WHERE K.ID = I.OBJECT_ID
        AND K.INDID = I.INDEX_ID
      ORDER BY COLID
      FOR XML PATH('')) AS INC
   FROM SYS.INDEXES AS I)
SELECT OBJECT_SCHEMA_NAME(C1.ID) + '.' + OBJECT_NAME(C1.ID) AS TABLE_NAME,
       C1.NAME AS INDEX_NAME,
       C2.NAME AS DUPLICATE_INDEX,
       'DROP INDEX [' + C2.NAME + '] ON [' + OBJECT_SCHEMA_NAME(C1.ID) + '].[' + OBJECT_NAME(C1.ID) + ']' AS DROP_STATEMENT
FROM IX AS C1
JOIN IX AS C2 ON C1.ID = C2.ID
AND C1.INDID < C2.INDID
AND C1.COLS = C2.COLS
AND C1.INC = C2.INC;

If you find this solution useful, you are welcome to press one of the ads in this page.. Thanks!

Wednesday, October 24, 2012

How to set Oracle SQL*PLUS character set

PROBLEM:
When opening your SQL*PLUS you see unrecognized characters, something like this:

SOLUTION:
To change SQL*PLUS language to english:
1. Close SQL*PLUS
2. Search "NLS_LANG" in the registry
3. Change the value to AMERICAN_AMERICA.WE8MSWIN1252
4. Open again SQL*PLUS to see changes

If you find this solution useful, you are welcome to press one of the ads in this page.. Thanks!